Une veille n’est utile que si elle aide à décider quoi vérifier et dans quel ordre. Pour cette fin d’octobre, deux changements annoncés méritent de regarder vos scripts et vos politiques : le retrait d’anciennes API PIM et l’évolution de Strong Integrity sur Android.
Je publie ce point en complément du carnet habituel, parce que les échéances sont proches. Il s’agit d’une vérification documentaire et d’une revue du code AuditMS, pas du récit d’un incident constaté chez un client.
Les dates à garder en tête
| Date | Sujet | Vérification prioritaire |
|---|---|---|
| 28 octobre 2026 | Anciennes API PIM | Rechercher les appels à /beta/privilegedAccess dans les scripts et outils utilisés. |
| Au plus tard le 31 octobre 2026 | Strong Integrity sur Android 13 et supérieur | Identifier les politiques concernées et les appareils dont les correctifs sont anciens. |
28 octobre : vérifier les anciennes API PIM
Microsoft annonce que les API PIM de deuxième génération sous /beta/privilegedAccess cesseront de retourner des données le 28 octobre 2026. Cela concerne leurs segments /aadRoles et /azureResources. Source : documentation Microsoft des API PIM.
La priorité est de rechercher ces chemins dans les scripts planifiés, connecteurs et outils de reporting. Si un appel est présent, identifier son usage et le remplacement correspondant avant de le modifier.
Les API actuelles passent par Microsoft Graph pour les rôles Entra et les groupes, et par Azure Resource Manager pour les rôles des ressources Azure. Une migration ne se résume donc pas à remplacer /beta par /v1.0 dans une URL. Source : génération actuelle des API PIM.
Dans un audit, une réponse vide ne doit pas être interprétée automatiquement comme une absence de privilèges à risque. Je vérifierais d’abord que la collecte a réellement abouti.
31 octobre : regarder les politiques Strong Integrity
Microsoft prévoit d’appliquer au plus tard le 31 octobre 2026 la nouvelle définition de Strong Integrity pour Android 13 et supérieur. Des appareils sans mise à jour de sécurité au cours des douze derniers mois peuvent ne plus satisfaire cette exigence. Source : avis de changement Intune.
L’impact dépend des politiques de protection des applications, de conformité et d’accès conditionnel configurées. Cela ne signifie pas que tous les appareils Android 13 seront bloqués à cette date.
Les vérifications utiles sont :
- Repérer les politiques utilisant l’exigence d’intégrité forte et leurs populations ciblées.
- Examiner la date des correctifs de sécurité des appareils concernés.
- Préparer les mises à jour et l’accompagnement des utilisateurs avant d’ajuster les exigences.
Le niveau d’Android, à lui seul, ne permet pas de conclure sur l’intégrité matérielle, le suivi du constructeur ou le verdict d’attestation. Google détaille les signaux de Play Integrity.
Windows : l’édition compte autant que la version
Un autre point mérite de revoir les seuils de vos inventaires. Au 26 octobre 2026, les repères de support standard sont les suivants :
| Version et édition | Fin des mises à jour |
|---|---|
| Windows 11 24H2 Home / Pro | 13 octobre 2026 : échéance passée |
| Windows 11 24H2 Enterprise / Education | 12 octobre 2027 |
| Windows 11 23H2 Enterprise / Education | 10 novembre 2026 : échéance à préparer |
Source : versions Windows prises en charge par Microsoft.
Un seuil unique « Windows 11 24H2 minimum » peut donc produire deux erreurs : accepter une édition Pro hors support et écarter une édition Enterprise encore couverte. Il faut aussi distinguer les canaux LTSC et les éventuels droits ESU.
Ce tableau est un repère daté. Il ne prouve ni l’installation des derniers correctifs ni l’éligibilité d’un poste à une nouvelle version de Windows.
Ce que j’ai vérifié dans AuditMS
La revue du code n’a trouvé aucun appel aux anciennes routes PIM /privilegedAccess ou /privilegedRoles. Ce retrait ne nécessite donc pas de migration des appels actuels d’AuditMS. Cela ne vaut pas vérification des scripts propres à votre environnement.
En revanche, le contrôle des versions OS a été corrigé : il distingue désormais les éditions Windows et leurs calendriers, au lieu d’appliquer un seuil de version unique.
La lecture de l’édition utilise les propriétés skuFamily et skuNumber de l’API Intune bêta. Une édition inconnue, une lecture refusée ou une pagination incomplète donnent un résultat non évalué, sans conclusion favorable par défaut. Documentation des propriétés de managedDevice.
Sur Android, AuditMS ne déduit plus la maintenance d’un seuil arbitraire de version. Ce contrôle ne vérifie pas Strong Integrity, les correctifs ou le support constructeur ; la conformité renvoyée par Intune est analysée séparément.
Ces changements ont été vérifiés par des tests automatisés. Ils ne constituent pas une validation sur un tenant réel.
Par quoi commencer ?
Je commencerais par l’inventaire des appels PIM, dont l’échéance arrive la première. Puis je regarderais les politiques Android réellement appliquées. Le contrôle des versions Windows viendrait compléter cette revue, notamment pour préparer les postes 23H2 Enterprise concernés en novembre.
L’objectif est de cibler les vérifications nécessaires, puis de tester les corrections sur un périmètre maîtrisé. Une annonce Microsoft ne justifie pas, à elle seule, une modification générale du tenant.
Informations et liens vérifiés le 26 octobre 2026. Les échéances sont celles annoncées dans les sources officielles ; les notifications propres à votre tenant n’ont pas été consultées pour cet article.