Catégorie : Microsoft Entra ID

Dans un peu plus de deux semaines, le 9 novembre 2026, Entra ID cesse d’accepter les numéros de téléphone ou adresses mail issus de l’annuaire pour la réinitialisation de mot de passe en libre-service (SSPR), s’ils n’ont jamais été explicitement enregistrés par l’utilisateur. Si tu comptes sur mobilePhone, businessPhone ou otherMails synchronisés depuis l’AD on-premises pour couvrir ce cas, une partie de tes utilisateurs risque de se retrouver bloqués au prochain mot de passe oublié.

Ce qui change concrètement

Aujourd’hui, SSPR peut vérifier l’identité d’un utilisateur de deux façons : avec une méthode d’authentification que l’utilisateur a lui-même enregistrée (téléphone confirmé par SMS, email vérifié…), ou avec des données déjà présentes dans l’annuaire — typiquement un numéro synchronisé depuis Active Directory via Entra Connect, jamais confirmé par l’utilisateur. C’est cette deuxième voie que Microsoft ferme, dans le cadre de la Secure Future Initiative : une donnée de contact qui n’a jamais été validée par son propriétaire est une porte d’entrée pour du social engineering (numéro obsolète récupéré par un tiers, boîte mail partagée mal configurée…).

Chiffre cité par Microsoft : environ 86 % des vérifications SSPR passent déjà par une méthode enregistrée. Le changement touche donc une minorité de cas, mais potentiellement toute une tranche d’utilisateurs si ton organisation s’est reposée sur la synchronisation automatique plutôt que sur l’enregistrement actif.

Un calendrier qui ne raconte pas tout à fait la même histoire selon la source

C’est le genre de détail qui mérite d’être signalé plutôt que lissé. La documentation Microsoft Learn sur la préremplissage des données SSPR indique, au 24 octobre 2026 :

• « Starting Nov 9, 2026 » : si ta politique SSPR exige l’enregistrement et qu’un utilisateur n’a pas assez de méthodes, une campagne d’enregistrement le sollicitera avant l’application de la restriction.
• « Starting Oct 5, 2026 » : SSPR n’accepte plus que les méthodes explicitement enregistrées — les propriétés issues de l’annuaire cessent de fonctionner.

Pris au pied de la lettre, ça voudrait dire que l’enregistrement forcé des utilisateurs restants démarre après que la restriction soit déjà en vigueur, ce qui n’a pas de sens dans l’ordre des opérations. Le message du Centre des messages Microsoft 365 associé (MC1325414), lui, décrit une chronologie inverse et cohérente : campagne de sollicitation à partir du 5 octobre 2026, date limite d’action au 6 novembre, puis entrée en vigueur de la restriction le 9 novembre (le message a été révisé plusieurs fois, une version antérieure mentionnait le 7 novembre). C’est cette seconde chronologie qui correspond à la logique du changement — prévenir avant de couper. Si tu veux trancher pour ton tenant, le plus fiable reste de relire le message MC1325414 directement dans ton Centre des messages Microsoft 365 : le calendrier peut aussi varier entre cloud public et GCC/GCC High.

Comment vérifier ta couverture avant le 9 novembre

Le Centre d’administration Entra (Entra ID > Authentication methods > User registration details) donne une vue utilisateur par utilisateur, mais pour un tenant de plusieurs centaines de comptes, un export via Microsoft Graph PowerShell va plus vite :

Connect-MgGraph -Scopes "Reports.Read.All"

# Liste les utilisateurs qui ne sont PAS enregistrés pour SSPR
Get-MgReportAuthenticationMethodUserRegistrationDetail -Filter "isSsprRegistered eq false" |
    Select-Object UserPrincipalName, UserDisplayName, IsSsprCapable, IsSsprEnabled, MethodsRegistered |
    Export-Csv -Path "sspr-non-enregistres.csv" -NoTypeInformation

Le filtre isSsprRegistered eq false remonte directement la liste à traiter. Croise avec IsSsprEnabled pour écarter les comptes pour qui SSPR n’est de toute façon pas activé — pas la peine de les relancer.

Pour accélérer l’enregistrement du reste, la campagne d’enregistrement native (Entra ID > Authentication methods > Registration campaign) sollicite les utilisateurs à chaque MFA réussie, avec une limite de trois reports possibles avant enregistrement obligatoire. Elle cible nativement Authenticator ou les passkeys, pas directement SSPR — mais un utilisateur qui enregistre Authenticator via cette campagne couvre de fait son SSPR dans la plupart des configurations de politique.

Les comptes à risque réel

Trois profils à vérifier en priorité, dans cet ordre : les comptes de service ou boîtes partagées avec SSPR activé par erreur (ils n’ont souvent aucune méthode enregistrée, personne n’y pense) ; les utilisateurs distants ou peu actifs qui ne se connectent pas assez souvent pour avoir été sollicités par une campagne MFA ; et les administrateurs eux-mêmes — ils sont soumis à une politique SSPR à deux méthodes par défaut, donc plus exposés si une seule de leurs méthodes dépendait de l’annuaire.

FAQ

Qu’est-ce qui arrive à un utilisateur sans méthode enregistrée après le 9 novembre ?

Il ne pourra plus réinitialiser son mot de passe seul. Il devra s’enregistrer via myprofile.microsoft.com (My Security Info) s’il peut encore se connecter, ou passer par un administrateur dans le cas contraire.

Ça concerne aussi les tenants GCC et GCC High ?

Oui, mais avec une fenêtre de déploiement distincte (début novembre à mi-novembre 2026 pour ces clouds, contre un calendrier resserré pour le cloud public) — vérifie le message MC1325414 propre à ton tenant plutôt que de supposer une date unique.

Les questions de sécurité restent-elles valables pour SSPR ?

Pour l’instant oui, mais elles sont en cours de dépréciation séparément : leur retrait pour SSPR est annoncé pour mars 2027. Ce n’est pas lié au changement du 9 novembre, mais ça vaut le coup de traiter les deux dans la même revue de politique SSPR si tu t’y mets maintenant.

Puis-je encore préremplir les contacts via Entra Connect après le 9 novembre ?

Techniquement la synchronisation continue de fonctionner, mais ces valeurs ne suffiront plus à elles seules pour SSPR : l’utilisateur devra les confirmer une première fois à l’enregistrement pour qu’elles comptent comme méthode enregistrée.

Pour la suite

Lance l’export PowerShell cette semaine plutôt que la semaine du 9 novembre — ça laisse une marge pour relancer les comptes isolés avant que la restriction morde. Si ce genre d’échéance Entra ID te semble familier, ce n’est pas un hasard : l’opérateur memberOf dans les Conditional Access part aussi à la retraite début novembre (détails ici), et la bascule d’Entra Connect Sync fin septembre a laissé quelques tenants sur le carreau faute d’anticipation (retour d’expérience à lire). Un seul calendrier des échéances Entra ID à jour, partagé avec le reste de l’équipe infra, évite de courir après chacune au dernier moment.

Un admin IT installe une extension Chrome qui ajoute un bandeau d’avertissement sur la page de connexion de son organisation, histoire de rappeler aux utilisateurs de vérifier l’URL avant de taper leur mot de passe. Bonne intention, mauvais moment : à partir de la mi-octobre 2026, ce genre d’extension va simplement arrêter de fonctionner sur login.microsoftonline.com, sans message d’erreur visible pour l’utilisateur final. La page de connexion, elle, continuera de marcher normalement.

C’est l’effet de la nouvelle Content Security Policy (CSP) que Microsoft déploie sur l’expérience de connexion Entra ID. Le changement a été annoncé au Message Center en décembre 2025 (référence MC1191924) et son application globale démarre mi-à-fin octobre 2026, selon la documentation officielle Microsoft Learn. Si tu gères des tenants Entra ID, voici ce qui change concrètement et ce qu’il faut vérifier avant que ça tombe.

Ce durcissement s’inscrit dans une série de resserrements de la sécurité d’authentification Entra ID en 2026, après le passage des passkeys en méthode d’authentification par défaut cet été. Même logique de fond : réduire la surface d’attaque côté navigateur sans attendre que l’utilisateur agisse.

Le problème que Microsoft referme

La cible, c’est l’injection de scripts externes sur la page de connexion : attaque XSS classique, extension de navigateur malveillante, ou simplement un outil tiers qui modifie le DOM de la page pour y ajouter du contenu. Dans les trois cas, du code qui n’a pas été écrit par Microsoft s’exécute dans le contexte de la page où l’utilisateur tape son mot de passe. Les conséquences possibles sont connues : vol de identifiants ou de tokens, prise de contrôle de session, ou simplement perte de confiance si la page de connexion se comporte de façon inattendue.

Microsoft précise dans sa documentation que les mécanismes existants (filtrage côté navigateur, protections natives d’Entra ID) restent la première ligne de défense. La CSP s’ajoute en profondeur, pour les cas où un script arrive malgré tout à s’injecter — via une extension installée localement ou une faille zero-day. Le principe d’une CSP, détaillé par l’OWASP Cheat Sheet dédiée, est simple : une liste blanche de domaines et de scripts autorisés, tout le reste est bloqué par défaut, sans exception.

La presse spécialisée en sécurité a repris l’annonce quelques jours avant son entrée en vigueur — BleepingComputer note que la majorité des violations observées par Microsoft en amont provenaient d’extensions de navigateur tierces, pas d’attaques ciblées.

Ce qui change exactement

Concrètement, Microsoft Entra ID impose un en-tête CSP qui n’autorise à s’exécuter que les scripts provenant de domaines Microsoft de confiance. Trois précisions importantes, directement issues de la documentation officielle :

• L’application ne concerne que les connexions via navigateur, sur login.microsoftonline.com précisément. Les autres domaines ne sont pas touchés par ce changement.
• Les flux basés sur MSAL (Microsoft Authentication Library) qui interrogent directement les API du service de jetons de sécurité (STS) d’Entra ID ne sont pas affectés, puisque l’application se limite à l’URL de connexion navigateur.
• Les clients Microsoft Entra External ID utilisant un domaine personnalisé ou un domaine CIAM ne sont pas impactés non plus.

Si ton organisation n’utilise aucun outil ni extension qui injecte du code dans la page de connexion, l’expérience ne change strictement rien pour tes utilisateurs — Microsoft le dit explicitement, et c’est le cas de la grande majorité des tenants. Le changement vise les 10-15% de cas où un outil tiers s’appuie sur cette pratique, d’après l’analyse de Microsoft sur l’origine des violations qu’elle observe actuellement en amont du rollout.

Qui risque d’être concerné

D’après les retours déjà documentés, les cas les plus fréquents de script injecté sur une page de connexion sont :

• des extensions de navigateur de sécurité ou de productivité (gestionnaires de mots de passe tiers, outils de monitoring, bloqueurs de contenu) qui modifient le DOM des pages visitées ;
• des outils de supervision ou de test (certains frameworks d’automatisation UI, des extensions de débogage) laissés actifs en dehors d’un contexte de développement ;
• des solutions de marque blanche ou de personnalisation visuelle qui injectent du JavaScript plutôt que de passer par les mécanismes de branding natifs d’Entra ID (logo, bandeau, texte personnalisé — ces options-là restent disponibles et ne sont pas concernées par la CSP).

Le point à retenir : ce n’est pas ta personnalisation de marque qui casse, c’est tout ce qui s’exécute en JavaScript injecté par-dessus la page plutôt que configuré nativement.

Comment tester ton tenant avant le rollout

Microsoft Learn détaille une méthode de test simple, à faire dès maintenant plutôt que d’attendre le jour J :

1. Ouvre la console développeur de ton navigateur (F12 sous Chrome ou Edge) avant de lancer un flux de connexion vers ton tenant.
2. Déroule un parcours de connexion complet en gardant la console ouverte.
3. Repère les violations CSP, qui s’affichent en rouge dans la console et identifient précisément le script bloqué et son origine.
4. Répète le test avec les différents profils et postes utilisés dans ton organisation (extensions installées, outils de support, postes partagés) — une violation causée par l’extension d’une seule équipe ne remontera que sur les parcours de connexion de cette équipe.

Si un outil tiers déclenche une violation, la recommandation officielle est de contacter l’éditeur pour obtenir une version compatible avec la CSP, plutôt que de chercher un contournement — il n’y a pas d’option tenant pour désactiver cette CSP, contrairement à ce qu’on peut faire sur un site Power Pages par exemple.

FAQ

Est-ce que ça bloque la connexion des utilisateurs ?

Non. Les utilisateurs peuvent continuer à se connecter normalement même si un script tiers est bloqué par la CSP. Ce qui casse, c’est le comportement ajouté par ce script précis (bandeau, overlay, tracking) — pas le flux d’authentification lui-même.

Faut-il activer quelque chose dans le tenant ?

Non, l’application est activée par défaut, sans configuration côté tenant. C’est justement l’absence de bouton pour la désactiver qui en fait une protection fiable à l’échelle de tous les tenants Entra ID — mais ça veut aussi dire qu’il faut tester en amont, pas réagir après coup.

Mes personnalisations de marque (logo, couleurs) vont-elles disparaître ?

Non, les mécanismes de branding natifs d’Entra ID (Company Branding) ne passent pas par de l’injection de script et ne sont pas concernés.

Et si on utilise MSAL pour une appli custom ?

Pas d’impact. L’application de la CSP se limite à la page de connexion navigateur sur login.microsoftonline.com ; les flux MSAL qui parlent directement aux API du STS Entra ID restent inchangés.

Ce qu’il faut faire cette semaine

Si tu n’as encore rien testé, le test console décrit plus haut prend cinq minutes et peut t’éviter un ticket de support en pleine mi-octobre. Fais-le sur un compte de test avec les extensions réellement utilisées par tes équipes support et sécurité — c’est là que se cachent la plupart des violations, pas dans la configuration Entra ID elle-même. Si ton organisation personnalise déjà la page de connexion via les Conditional Access ou le Company Branding plutôt que du script injecté, cette échéance ne te concerne tout simplement pas.

Et si tes politiques de Conditional Access couvrent déjà des identités non humaines (agents IA, comptes de service), ça vaut le coup de revérifier leur posture pendant que tu y es — on a détaillé comment sécuriser les identités d’agents IA dans Entra ID dans un article précédent.

Le 3 novembre 2026, l’opérateur memberOf cesse de fonctionner dans les groupes à appartenance dynamique de Microsoft Entra ID. Pas de suppression brutale, pas d’erreur qui saute aux yeux : les groupes concernés arrêtent simplement de se mettre à jour et restent figés dans leur dernier état connu. C’est précisément ce genre de panne silencieuse qui fait le plus de dégâts — personne ne la remarque avant que quelqu’un perde un accès qu’il devrait avoir, ou en garde un qu’il ne devrait plus avoir.

Microsoft a envoyé un rappel final le 5 octobre 2026 (MC1488834), trois mois après l’annonce initiale du 5 août. Si tu n’as pas suivi ce fil de la Message Center, voici ce qu’il faut vérifier avant la date butoir.

Ce qui casse exactement

memberOf est un opérateur en préversion qui permet à un groupe dynamique d’inclure les membres d’autres groupes — pratique pour agréger plusieurs groupes de sécurité existants sans tout reconstruire à la main. Trois types d’objets l’utilisent, et les trois sont concernés après le 3 novembre :

• Les groupes à appartenance dynamique dont la règle contient memberOf : ils arrêtent de traiter les changements d’appartenance.
• Les unités d’administration dynamiques basées sur cette même règle : leur périmètre d’administration se gèle aussi.
• Les politiques d’auto-attribution de l’entitlement management qui s’appuient sur memberOf : plus aucune nouvelle attribution de package d’accès ne sera traitée via cette règle.

Les effets en cascade sont le vrai problème : accès Teams et SharePoint qui ne reflètent plus la réalité, ciblage Conditional Access obsolète, licences attribuées par groupe qui ne suivent plus les arrivées et départs. Microsoft est explicite sur la cause : l’opérateur memberOf peut ralentir le traitement des appartenances dynamiques pour tout le tenant, pas seulement pour le groupe qui l’utilise — même un seul groupe mal configuré peut dégrader les temps de traitement de tous les autres. D’où la retraite plutôt qu’un simple correctif de performance.

Comment savoir si tu es concerné

La syntaxe à chercher ressemble à ceci :

user.memberof -any (group.objectId -in ['<id-du-groupe-source>'])

Pour la repérer sur tous tes groupes dynamiques via Microsoft Graph PowerShell :

Connect-MgGraph -Scopes "Group.Read.All"

Get-MgGroup -All -Filter "groupTypes/any(c:c eq 'DynamicMembership')" `
    -Property Id,DisplayName,MembershipRule |
    Where-Object { $_.MembershipRule -match '(?i)memberof' } |
    Select-Object Id, DisplayName, MembershipRule

Pour les unités d’administration et les politiques d’auto-attribution, il n’existe pas de filtre équivalent côté portail — passe aussi par Graph PowerShell (Get-MgDirectoryAdministrativeUnit et Get-MgEntitlementManagementAssignmentPolicy) et grep la propriété membershipRule ou les règles de la policy de la même façon.

Que mettre à la place

Deux chemins, selon ce que tu avais réellement besoin de faire :

• Remplacer par un opérateur supporté — si ton besoin se ramène à un attribut (département, pays, type d’appareil…), les opérateurs -eq, -in, -startsWith couvrent la grande majorité des cas, et sont documentés dans le guide des règles de groupe dynamique.
• Basculer en appartenance assignée — si le besoin réel était juste d’agréger quelques groupes de façon ponctuelle, un groupe assigné avec une synchro manuelle ou scriptée (un petit script planifié qui recopie les membres) est souvent plus simple à maintenir qu’une règle dynamique fragile, surtout vu les limites déjà en place sur memberOf (50 groupes membres max, pas de chaînage entre deux groupes memberOf, pas de combinaison avec un autre opérateur).

Dans les deux cas, valide l’appartenance résultante avant de considérer la migration terminée — un comptage avant/après suffit dans la plupart des cas, sur une politique d’auto-attribution, va vérifier aussi les attributions de packages d’accès.

Le piège si tu ne fais rien

Ce n’est pas un échec propre : le groupe continue d’exister, continue d’avoir des membres, et continue d’être utilisé par Conditional Access ou par une licence groupée. Il se contente de ne plus évoluer. Un nouvel employé ajouté au groupe source trois semaines après le 3 novembre n’apparaîtra jamais dans le groupe dynamique qui en dépendait — sans message d’erreur nulle part. C’est le genre d’écart qui ressort en audit six mois plus tard, pas le jour où ça casse.

FAQ

Est-ce que je peux encore créer un nouveau groupe memberOf avant le 3 novembre ?

Techniquement oui, mais ça n’a aucun sens : il arrêtera de se mettre à jour dès l’échéance. Autant partir directement sur un opérateur supporté ou une appartenance assignée.

Microsoft va-t-il proposer une alternative pour le cas d’usage memberOf ?

Le message officiel indique que Microsoft continue à travailler sur une solution alternative avec un meilleur niveau de fiabilité et d’échelle, sans date annoncée. En attendant, il n’y a pas de remplacement direct en préversion à adopter.

Est-ce que ça touche aussi les groupes dynamiques basés sur les appareils ?

Oui — la syntaxe device.memberof suit exactement la même règle et la même échéance que la version user.memberof.

Passe à l’action

Lance le script PowerShell ci-dessus cette semaine, pas la semaine du 2 novembre. Si tu as déjà dû gérer une échéance Entra qui est tombée sans prévenir — on en a parlé avec le couperet Entra Connect Sync du 30 septembre — tu sais que le vrai risque n’est pas la date elle-même, c’est de la découvrir après coup.

Vendredi, 17h40. Quelqu’un supprime la mauvaise stratégie d’accès conditionnel en faisant du ménage. Jusqu’au printemps dernier, ta seule option dans Entra ID était de la recréer de mémoire, ou depuis un export que tu espérais à jour. Depuis juin 2026, Microsoft Entra Backup and Recovery est disponible en GA : une sauvegarde quotidienne de ton tenant, automatique, que personne ne peut désactiver.

C’est une vraie avancée. Mais la rétention est de sept jours, et la liste des propriétés restaurables est plus courte que ce que le nom du produit laisse imaginer. Voici ce que le service couvre vraiment, ce qu’il laisse de côté, et ce que tu dois garder en plus.

Ce que fait le service

D’après la documentation Microsoft Learn, le fonctionnement tient en peu de lignes :

• une sauvegarde par jour, conservée 7 jours (c’était 5 pendant la preview) ;
• activée d’office, et impossible à désactiver, supprimer ou modifier, même par un Global Administrator ;
• stockée dans la même zone géographique que ton tenant ;
• réservée aux tenants workforce avec licences Entra ID P1 ou P2 (les tenants External ID et Azure AD B2C ne sont pas pris en charge).

Dans le centre d’administration Entra, le menu Backup and recovery te donne quatre écrans : la liste des sauvegardes, les rapports de différences, la restauration (sur tout, sur certains types d’objets ou sur des ID précis) et l’historique des restaurations. Deux rôles dédiés existent : Microsoft Entra Backup Reader pour consulter, Microsoft Entra Backup Administrator pour lancer comparaisons et restaurations.

Le fait que la sauvegarde soit hors de portée d’un admin compromis compte beaucoup. Un attaquant avec des droits élevés ne peut pas effacer ton point de retour.

Ce qui est couvert, et ce qui ne l’est pas

Bien couvert

Les stratégies d’accès conditionnel et les emplacements nommés sont sauvegardés avec toutes leurs propriétés. C’est le cas d’usage le plus solide du produit. La stratégie des méthodes d’authentification est couverte pour huit méthodes (passkeys FIDO2, Authenticator, TAP, SMS, appel vocal, OTP par e-mail, OATH logiciel tiers, authentification par certificat).

Utilisateurs, groupes, applications et principaux de service sont couverts aussi, mais sur une liste fermée de propriétés. Côté utilisateurs, par exemple : AccountEnabled, UserPrincipalName, Department, PerUserMfaState, UsageLocation, et une trentaine d’autres. Restaurer un principal de service restaure aussi ses attributions de rôles d’application et les consentements donnés par un admin pour toute l’organisation.

Pas couvert (vérifié dans la liste officielle)

La page objets et propriétés supportés est la seule qui compte. En la lisant attentivement, tu remarques ces absences :

• le manager et le sponsor d’un utilisateur ;
• les propriétaires de groupes et les règles des groupes dynamiques ;
• les consentements donnés par un utilisateur (seuls les consentements admin pour toute l’organisation sont couverts) ;
• les secrets et certificats d’application : passwordCredentials et keyCredentials ne figurent pas dans les propriétés restaurables ;
• les attributions de rôles Entra : elles n’apparaissent dans aucune catégorie d’objets supportés ;
• les objets supprimés définitivement (hard delete) : rien ne les recrée ;
• les modifications sur les objets synchronisés depuis l’AD local : elles apparaissent dans le rapport de différences, mais sont exclues de la restauration (sauf les appartenances aux groupes).

Les deux points sur les secrets et les rôles changent la lecture du produit. Prends un attaquant qui obtient un accès admin, ajoute un secret sur une app registration bien dotée en permissions et s’attribue un rôle privilégié. Une restauration ne retire ni l’un ni l’autre. Entra Backup and Recovery est un outil contre les erreurs de configuration et les modifications malveillantes de stratégies. Ce n’est pas un outil de remédiation d’incident. Pour ça, il te faut toujours ta procédure de réponse à incident, avec révocation des credentials et revue des rôles.

La bonne méthode de restauration

Microsoft le recommande, et c’est du bon sens : lance toujours un rapport de différences avant de restaurer. Tu vois exactement quels attributs et liens ont changé entre la sauvegarde et l’état actuel. Ça a un bénéfice pratique en plus : le premier accès à une sauvegarde déclenche un chargement des données qui prend un temps fixe, même sur un petit tenant. Le rapport de différences fait ce chargement à l’avance, et la restauration qui suit est plus rapide.

Restreins ensuite le périmètre. Si une seule stratégie d’accès conditionnel a sauté, restaure cet ID-là, pas tout le type d’objet. Une restauration large peut écraser des changements légitimes faits depuis la sauvegarde.

En environnement hybride, rappelle-toi que les objets dont la source d’autorité est l’AD local ne seront pas restaurés côté cloud. Si ta synchronisation tourne encore avec Entra Connect, l’échéance du 30 septembre sur Entra Connect Sync mérite d’être vérifiée au passage.

Sept jours ne suffisent pas : garde ta propre copie

Une modification discrète découverte dix jours plus tard est hors de portée du service. C’est pour ça que Microsoft renvoie lui-même vers ses bonnes pratiques de récupération, qui recommandent de documenter régulièrement l’état de référence via Microsoft Graph.

Pour les objets les plus sensibles, un export quotidien en JSON suffit. Voici une base avec le SDK Microsoft Graph PowerShell :

Connect-MgGraph -Scopes "Policy.Read.All"

$stamp = Get-Date -Format "yyyyMMdd"
$dir   = ".\entra-export\$stamp"
New-Item -ItemType Directory -Path $dir -Force | Out-Null

Get-MgIdentityConditionalAccessPolicy -All |
    ConvertTo-Json -Depth 10 |
    Out-File "$dir\conditional-access.json" -Encoding utf8

Get-MgIdentityConditionalAccessNamedLocation -All |
    ConvertTo-Json -Depth 10 |
    Out-File "$dir\named-locations.json" -Encoding utf8

Get-MgPolicyAuthenticationMethodPolicy |
    ConvertTo-Json -Depth 10 |
    Out-File "$dir\auth-methods-policy.json" -Encoding utf8

En production, fais tourner ce script en mode application (certificat ou identité managée dans Azure Automation, plutôt qu’une connexion interactive), et pousse les fichiers dans un dépôt Git ou un compte de stockage avec immuabilité. Un git diff entre deux jours devient alors ton propre rapport de différences, sans limite de rétention.

FAQ

Est-ce que ça demande une licence en plus ?

Non. Entra ID P1 ou P2 suffit, et le service est actif d’office sur les tenants éligibles.

Ça remplace Microsoft 365 Backup ?

Non, ce ne sont pas les mêmes données. Entra Backup and Recovery protège l’annuaire, Microsoft 365 Backup protège les boîtes mail, SharePoint et OneDrive. J’ai détaillé ce que couvre Microsoft 365 Backup dans un article précédent.

Et mon Active Directory local ?

Il reste à ta charge, avec ta solution de sauvegarde habituelle. Le service Entra ne touche pas à AD DS.

Un utilisateur supprimé il y a 15 jours, je le récupère comment ?

Par la corbeille Entra : les utilisateurs, groupes Microsoft 365, groupes de sécurité cloud, app registrations et principaux de service supprimés en soft delete restent restaurables 30 jours. Backup and Recovery vient en complément, pas à la place.

À faire cette semaine

Ouvre le menu Backup and recovery de ton tenant et lance un rapport de différences sur la sauvegarde d’hier, juste pour voir le délai et le rendu. Attribue le rôle Backup Administrator à deux personnes nommément, plutôt que de compter sur les Global Admins. Et mets en place l’export Graph quotidien : c’est lui qui te sauvera le jour où le problème aura plus d’une semaine. Une sauvegarde de l’annuaire s’inscrit dans la même logique que la règle 3-2-1-1-0 : une copie ne suffit jamais.

Le 30 septembre 2026 à minuit, un bon nombre de serveurs Microsoft Entra Connect Sync ont basculé silencieusement dans un état cassé. Pas de crash spectaculaire, pas d’alerte rouge dans le centre d’administration : juste des synchronisations qui s’arrêtent, des comptes qui ne se créent plus côté cloud, et des changements de mot de passe qui ne remontent jamais. Si ton serveur tournait encore sous une version antérieure à 2.5.79.0 hier à cette heure, tu es probablement concerné, même si personne ne t’a encore appelé pour te le dire.

Ce qui s’est vraiment passé le 30 septembre

Microsoft a déployé une nouvelle application de service de première partie, baptisée « Microsoft Entra AD Synchronization Service » (ID d’application 6bf85cfa-ac8a-4be5-b5de-425a0d0dc016), visible dans Enterprise Applications du centre d’administration Entra. Cette application sert désormais de pivot d’authentification entre Entra Connect et Microsoft Entra ID — c’est le cœur du durcissement de sécurité annoncé par Microsoft pour la synchronisation hybride.

Le souci, c’est que seules les versions 2.5.79.0 et ultérieures savent dialoguer avec cette nouvelle application. En dessous, le canal de communication casse net. Microsoft a documenté le changement sans détour : « all synchronization services in Microsoft Entra Connect Sync will fail » pour tout le monde resté sous la barre.

Le piège : ça a l’air de marcher, au début

C’est là que ça devient intéressant, et pas dans le bon sens. Les connexions utilisateur continuent de fonctionner un moment, parce qu’Entra ID garde les hash de mot de passe synchronisés précédemment. Tu peux donc avoir l’impression que tout va bien pendant plusieurs jours.

Sauf qu’en coulisses, le plan de contrôle identitaire est figé. Concrètement :

• les nouveaux comptes AD créés sur site n’apparaissent plus dans Entra ID ;
• les changements de groupes et d’attributs restent bloqués côté annuaire local ;
• le password writeback (si tu l’utilises) ne fonctionne plus dans aucun sens ;
• un départ collaborateur désactivé sur site ne se répercute plus dans le cloud — ce qui est le scénario qui doit vraiment t’inquiéter côté sécurité.

Autrement dit : le symptôme le plus visible (les connexions) est justement celui qui te fait croire que tout va bien.

Vérifier ta version, maintenant

Deux façons rapides de savoir où tu en es. La première, en PowerShell, directement sur ton serveur Entra Connect :

(Get-Item "C:\Program Files\Microsoft Azure AD Connect\AzureADConnect.exe").VersionInfo.ProductVersion

La seconde, plus visuelle : clic droit sur AzureADConnect.exe, Propriétés, onglet Détails. Si le chiffre affiché commence par 2.4.x, 2.3.x ou pire, 1.x — tu es largement sous le seuil et ta synchro est probablement déjà en panne silencieuse depuis le 30 septembre.

Si tu es déjà en 2.5.79.0 ou au-delà, tu es formellement conforme. Mais je te le dis franchement : ne t’arrête pas là. La version recommandée au moment où j’écris ces lignes est 2.6.92.0 (sortie le 23 septembre 2026), qui corrige plusieurs problèmes connus des versions 2.5.x et 2.6.1.0 — dont une régression de synchronisation assez vicieuse (voir plus bas). Rester au strict minimum légal n’a pas grand intérêt quand la dernière version est disponible gratuitement sur le même centre d’administration.

Comment remettre ça d’aplomb

Microsoft propose trois chemins, et le bon dépend surtout de la taille de ton annuaire :

Mise à niveau automatique

Si tu es déjà sur une version 2.3.20.0 ou supérieure avec la fonction d’auto-upgrade activée, et que ton installation est en mode Express avec moins de 100 000 objets, la mise à jour peut se faire sans intervention. Vérifie l’état avec Get-ADSyncAutoUpgrade — si elle est désactivée, Set-ADSyncAutoUpgrade -AutoUpgradeState Enabled la réactive.

Mise à niveau sur place

Pour un serveur unique, c’est la méthode la plus directe : tu télécharges le nouvel installeur et tu lances la mise à niveau in-place. Le risque principal, c’est l’indisponibilité pendant l’opération — acceptable pour une petite structure, plus délicat pour un environnement critique.

Migration par serveur de staging (swing migration)

C’est la méthode à privilégier pour les environnements de production sensibles : tu installes la nouvelle version sur un serveur de staging, tu valides que tout fonctionne, puis tu bascules la promotion vers ce serveur. Zéro coupure si c’est bien mené.

Dans tous les cas, le fichier d’installation n’est plus disponible nulle part ailleurs que sur le centre d’administration Microsoft Entra, section Gérer > Microsoft Entra Connect. L’ancien lien de téléchargement direct ne sert plus à rien.

Un bug à surveiller après la mise à niveau

Si ton fichier miiserver.exe.config a été modifié à un moment donné (ce qui arrive plus souvent qu’on ne le pense, notamment pour des ajustements de timeout), la synchronisation peut échouer après la mise à jour vers 2.5.190.0 ou 2.6.1.0 avec cette exception précise :

System.IO.FileLoadException: Could not load file or assembly 'System.Diagnostics.DiagnosticSource, Version=6.0.0.1'

Le correctif tient en quelques lignes XML à ajouter dans la section assemblyBinding du même fichier :

<dependentAssembly>
  <assemblyIdentity name="System.Diagnostics.DiagnosticSource"
                    publicKeyToken="cc7b13ffcd2ddd51"
                    culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-8.0.0.0" newVersion="8.0.0.0" />
</dependentAssembly>

Garde ce bloc sous le coude avant de lancer ta mise à niveau si tu sais avoir touché à ce fichier de config par le passé.

La prochaine échéance est déjà posée

Et ce n’est pas fini : Microsoft a déjà fixé le prochain couperet au 7 avril 2027. À cette date, il faudra être en version 2.6.84.0 ou ultérieure ET avoir configuré l’authentification par application (application-based authentication) — l’authentification héritée sera retirée, point final. Si tu viens de faire la mise à jour pour le 30 septembre, autant viser directement une version qui coche aussi cette case plutôt que de refaire l’exercice six mois plus tard.

Pour ceux qui n’ont pas de contrainte forte à rester sur Entra Connect Sync classique, c’est aussi le bon moment pour regarder Microsoft Entra Cloud Sync, que Microsoft pousse explicitement comme alternative pour les nouveaux déploiements.

FAQ

Mon serveur n’affiche aucune erreur, suis-je vraiment concerné ?

Oui, et c’est justement le piège décrit plus haut. L’absence d’erreur visible dans le Synchronization Service Manager ne garantit rien : vérifie la version exacte avec la commande PowerShell donnée plus haut, pas l’historique des exécutions.

Puis-je revenir en arrière si la mise à niveau pose problème ?

Techniquement oui via une sauvegarde de la base ADSync, mais ça te renvoie directement dans la fenêtre de rupture puisque la version précédente ne reparlera plus avec le nouveau service d’application. Mieux vaut sécuriser l’upgrade via une migration de staging que planifier un retour arrière.

Et si j’utilise Entra Connect pour la fédération AD FS, est-ce impacté différemment ?

Le durcissement concerne spécifiquement le canal de synchronisation (sync engine), pas la fédération en tant que telle. Mais si AD FS et Entra Connect Sync tournent sur la même infrastructure, un blocage de synchronisation finit presque toujours par se répercuter sur les attributs utilisés par tes règles de claims.

Ce qu’il faut retenir

Vérifie ta version aujourd’hui, pas la semaine prochaine. La commande PowerShell prend dix secondes à exécuter, et le coût d’une synchronisation cassée pendant plusieurs jours — comptes fantômes, départs non propagés, mots de passe désynchronisés — est largement supérieur à celui d’une fenêtre de maintenance planifiée. Si ton infrastructure AD mérite un tour de vérification plus large pendant que tu y es, notre guide sur les changements sécurité d’Active Directory dans Windows Server 2025 couvre les autres fronts à surveiller. Et puisque la version 2.6.84.0 ajoute le support des clés d’accès (passkeys) via Windows Web Account Manager, ça vaut aussi le coup de relire notre article sur les passkeys par défaut dans Entra ID pour préparer la suite.

Le 1^er septembre 2026, sans qu’aucun administrateur Entra ID n’ait eu à cliquer sur quoi que ce soit, Microsoft a commencé à basculer automatiquement les utilisateurs inscrits en SMS ou en appel vocal vers l’enregistrement d’une passkey. Pas une annonce vague sur une roadmap lointaine : une bascule qui tourne déjà, avec une date de coupure ferme cinq mois plus tard.

Le 1^er février 2027, Microsoft retire purement et simplement la livraison SMS/voix qu’elle opère elle-même, pour la quasi-totalité des comptes. Passé cette date, un utilisateur qui n’a que le SMS comme second facteur ne pourra plus se connecter tant qu’il n’aura pas enregistré une passkey — sans option pour repousser indéfiniment. Si ton tenant a encore des comptes qui dépendent du SMS ou de la voix, voici le calendrier exact, la commande pour savoir qui est concerné, et la checklist pour basculer avant que ce soit Microsoft qui décide à ta place.

Le calendrier complet, sans arrondi

Trois dates comptent vraiment, et elles ne concernent pas tout le monde de la même façon :

• 1er septembre 2026 : activation automatique des profils de passkeys pour les utilisateurs qui utilisent déjà le SMS ou la voix, avec une campagne d’enregistrement (« nudge ») déclenchée à la prochaine authentification multifacteur.
• 1er février 2027 : retrait du SMS/voix géré par Microsoft pour tous les utilisateurs, sauf les administrateurs généraux et les comptes externes.
• 1er juillet 2027 : même retrait, mais cette fois pour les administrateurs généraux et les utilisateurs externes — dix mois de sursis pour les comptes les plus sensibles, pas moins.

Après chacune de ces deux échéances, un utilisateur sans autre méthode MFA que le SMS ou la voix est bloqué à la connexion tant qu’il n’a pas enregistré une passkey. Aucune exemption n’existe passé ces dates — l’annonce officielle sur Microsoft Learn est explicite là-dessus.

Une nuance qui compte si tu gères des comptes B2B : les invités internes suivent la date de février, pas celle de juillet. Seuls les comptes externes proprement dits (B2B collaboration) bénéficient du délai supplémentaire.

Pourquoi maintenant, et pourquoi sans mode « je désactive et j’oublie »

Le SMS et la voix comme second facteur ont un défaut connu depuis des années : ils transitent par le réseau télécom, vulnérable au SIM swap et à l’interception. Les passkeys reposent sur de la cryptographie à clé publique — la clé privée ne quitte jamais l’appareil, donc rien à intercepter côté réseau. Ce n’est pas une nuance marketing, c’est la raison technique pour laquelle Microsoft qualifie les passkeys de méthode « phishing-resistant » quand le SMS ne l’est pas, comme le détaille le billet du Microsoft Security Blog qui a lancé cette annonce.

Ce qui change la donne par rapport aux précédentes campagnes de dépréciation Microsoft, c’est l’absence de porte de sortie après la date butoir. Tu peux repousser l’activation automatique via un opt-out temporaire — voir plus bas — mais l’échéance de blocage, elle, ne se négocie pas.

Savoir qui, dans ton tenant, dépend encore du SMS ou de la voix

Avant de basculer qui que ce soit, identifie les comptes concernés. Microsoft publie un script PowerShell dédié à cet usage exact :

# https://github.com/microsoft/entra-sms-voice-usage-analyzer
# Rôles nécessaires : Global Reader, Authentication Policy Administrator, Security Reader
.\Get-SmsVoiceUsageReport.ps1 -TenantId "<ton-tenant-id>"

Pour un contrôle ponctuel sans script, un appel Graph direct sur la politique d’authentification donne déjà une bonne partie de la réponse :

GET https://graph.microsoft.com/beta/policies/authenticationmethodspolicy

Configurer les passkeys avant que Microsoft ne s’en charge

L’activation se fait aujourd’hui exclusivement depuis le portail — il n’existe pas encore de cmdlet PowerShell native pour l’activation de base, seul le provisioning avancé passe par Microsoft Graph, en preview. Le chemin : Entra ID → Security → Authentication methods → Policies → Passkey (FIDO2), puis l’opt-in aux profils de passkeys depuis la bannière — une action irréversible, à garder en tête avant de cliquer.

Une fois l’opt-in fait, le profil par défaut se configure avec trois réglages qui ont un vrai impact opérationnel :

• Passkey types : device-bound, synced, ou les deux — les passkeys synchronisées (iCloud Keychain, Google Password Manager, gestionnaires comme 1Password) simplifient l’adoption mais sortent la clé privée de l’appareil physique unique.
• Enforce attestation : vérifie que l’authentificateur est un modèle reconnu, désactivé par défaut, à activer sur les profils sensibles.
• Enforce key restrictions : limite les modèles acceptés par AAGUID, l’identifiant unique de chaque fabricant/modèle FIDO2 — utile pour n’autoriser que Microsoft Authenticator ou des clés YubiKey précises sur les comptes à privilèges. Le détail de la procédure est dans le guide Microsoft Learn sur l’activation des passkeys FIDO2.

Tu peux créer jusqu’à trois profils au total, profil par défaut inclus, avec une limite de taille de 20 Ko pour l’ensemble de la politique — largement suffisant, sauf à lister des dizaines d’AAGUID par profil. Un exemple raisonnable pour une entreprise avec des comptes à privilèges : un profil « Admin » en device-bound uniquement avec attestation forcée, ciblé sur le groupe IT/Exécutifs, et un profil par défaut plus permissif (device-bound + synced, sans attestation) pour le reste des utilisateurs.

L’opt-out temporaire : un sursis, pas une exemption

Si tu n’es pas prêt pour la bascule automatique du 1er septembre, un appel Graph permet de sortir ton tenant de l’activation automatique et des campagnes d’enregistrement :

PATCH https://graph.microsoft.com/beta/policies/authenticationmethodspolicy
Content-Type: application/json

{
   "optOutSettings": {
     "passkeyDynamicMigration": true
   }
}

Permission requise : Policy.ReadWrite.AuthenticationMethod. Mais ne t’y trompe pas : ce réglage suspend l’activation automatique et les nudges, il ne touche pas à l’échéance de blocage du 1er février 2027 (ou du 1er juillet pour les admins/externes). Passé cette date, l’enregistrement d’une passkey redevient obligatoire, opt-out ou pas. Autant utiliser ce sursis pour préparer la bascule dans de bonnes conditions plutôt que pour la repousser indéfiniment — il n’existe pas de version « je ne fais rien » qui survit à l’échéance.

Et si tu dois vraiment garder du SMS ou de la voix

Pour des contraintes réglementaires ou des populations d’utilisateurs qui ne peuvent techniquement pas passer aux passkeys — téléphones basiques, zones sans app store —, Microsoft ouvre à partir du 30 octobre 2026 un marché de fournisseurs télécom tiers via le Microsoft Security Store. Soprano et Telesign sont les deux premiers annoncés, avec d’autres providers attendus en disponibilité générale. Ce n’est pas gratuit, et ça reste un pis-aller : la dépendance au réseau télécom ne disparaît pas, elle change juste de facturation.

FAQ

Mon tenant peut-il éviter complètement cette migration ?

Non, pas au-delà des échéances de blocage. L’opt-out ne fait que retarder l’activation automatique et les campagnes d’enregistrement ; il n’annule pas la retraite du SMS/voix géré par Microsoft.

Les passkeys synchronisées sont-elles aussi sûres que les passkeys liées à l’appareil ?

Elles restent phishing-resistant, mais la clé privée est répliquée dans le coffre du fournisseur (iCloud Keychain, Google Password Manager…), donc le modèle de menace n’est pas identique à une clé bound à un seul appareil ou à une security key physique. Pour des comptes à privilèges, le device-bound avec attestation forcée reste le choix le plus prudent.

Faut-il une licence Entra ID P1 ou P2 pour activer les passkeys ?

Non. Les méthodes d’authentification de base, passkeys incluses, sont disponibles avec Microsoft Entra ID Free — ce sont certains contrôles avancés (Conditional Access, authentication strengths personnalisées) qui nécessitent P1 ou P2.

Que tu aies déjà mis en place du Conditional Access pour sécuriser tes accès — voir notre article sur la sécurisation des identités d’agents IA dans Entra ID — ou que tu prépares encore ta politique d’enforcement — voir notre suivi du changement d’enforcement de juin 2026 —, la fenêtre entre maintenant et février 2027 est le bon moment pour traiter les passkeys comme un projet plutôt que comme une notification à ignorer. Lance le script de détection cette semaine : tu sauras exactement combien de comptes sont concernés avant que Microsoft ne bascule pour toi.

Tes équipes déploient de plus en plus d’agents IA — agents Copilot, agents personnalisés construits sur Foundry, automatisations agentiques diverses. Et depuis cette année, Microsoft ne les traite plus comme de simples comptes de service génériques : ils ont leur propre statut d’identité dans Entra ID, avec des contrôles de sécurité dédiés. Si tu gères l’identité et les accès dans ton organisation, voici ce qui a changé concrètement, et comment t’en servir pour garder la main sur ces nouveaux comptes.

Les agents IA ont désormais leur propre compte dans Entra ID

Un agent IA qui agit pour ton compte — qui lit des données, déclenche des actions, appelle des API — a besoin d’une identité au même titre qu’un utilisateur ou qu’un compte de service. Microsoft formalise ça sous la notion d’« identité d’agent » (agent identity) dans Entra ID : un objet distinct, qui peut être ciblé, gouverné et sécurisé avec les mêmes outils que ceux que tu utilises déjà pour les comptes humains — mais avec quelques mécanismes spécifiques, pensés pour le cycle de vie particulier de ces agents.

Conditional Access s’étend aux comptes d’agents

Passée en disponibilité générale en juin 2026, l’extension des protections Conditional Access aux comptes d’agents te permet désormais de :

• cibler précisément les comptes d’agents, en incluant ou excluant des agents individuels, ou en les regroupant dynamiquement via des attributs de sécurité personnalisés (custom security attributes) ;
• te protéger contre une activité d’agent à risque, en appliquant des politiques Conditional Access basées sur un score d’Agent Risk, sur le même principe que le risque de connexion pour les utilisateurs ;
• exiger des appareils conformes pour les agents qui tournent sur des points de terminaison managés, y compris Windows 365 pour les agents, garantissant que les agents ne s’exécutent que depuis des environnements conformes à tes exigences ;
• appliquer des filtres de plateforme d’appareil et de conditions réseau aux agents, sur la base de l’état de l’appareil et des emplacements réseau de confiance.

Concrètement, ça veut dire que tu peux désormais écrire une politique Conditional Access du type « tout compte d’agent taggé Team=Finance via attribut de sécurité personnalisé doit s’exécuter depuis un appareil conforme et se voit bloqué si son score de risque dépasse un certain seuil » — exactement le type de granularité que tu appliques déjà à tes comptes utilisateurs à privilèges. La documentation officielle détaille la configuration complète via le centre d’administration Entra ou Microsoft Graph.

Qui est responsable de l’agent ? Le sponsor et les Lifecycle Workflows

Un compte orphelin, sans humain responsable, est un vrai risque d’audit — c’était déjà vrai pour les comptes de service classiques, ça l’est encore plus pour des agents autonomes. Depuis mai 2026, Entra ID Governance permet de gérer le cycle de vie du sponsor d’une identité d’agent directement via les Lifecycle Workflows :

• chaque identité d’agent doit être rattachée à un sponsor humain, responsable de son accès et de son cycle de vie ;
• si ce sponsor quitte l’organisation, le parrainage de l’agent est automatiquement transféré à son manager, sans intervention manuelle ;
• les workflows incluent des tâches de notification aux co-sponsors et aux managers en cas de changement imminent de sponsor.

Résultat : tu ne te retrouves jamais avec un agent qui continue d’accéder à des ressources sensibles alors que la personne qui en était responsable a quitté l’entreprise depuis six mois. Le détail de la mise en place est documenté dans le guide « Agent identity sponsor tasks in Lifecycle Workflows ».

Mise en pratique : par où commencer

• Fais l’inventaire des identités d’agents déjà présentes dans ton tenant (centre d’administration Entra ou requêtes Microsoft Graph).
• Définis des attributs de sécurité personnalisés pour classer tes agents par équipe, criticité ou niveau de risque acceptable — c’est ce qui te permettra de les cibler finement en Conditional Access.
• Crée une politique Conditional Access dédiée aux comptes d’agents, distincte de celle de tes utilisateurs, avec des exigences adaptées (conformité d’appareil, score de risque).
• Mets en place un Lifecycle Workflow de gestion de sponsor, pour garantir qu’aucun agent ne se retrouve durablement sans responsable humain identifié.

FAQ

Un agent IA a-t-il vraiment besoin d’un compte Entra ID séparé ?

Dès qu’un agent agit de façon autonome — au-delà d’un simple appel API ponctuel avec les droits de l’utilisateur qui l’invoque — le traiter comme une identité à part entière permet de lui appliquer une gouvernance et une traçabilité propres, plutôt que de le confondre avec un compte de service générique ou avec les droits d’un utilisateur humain.

Est-ce que ça s’applique uniquement aux agents personnalisés, ou aussi à Copilot ?

Le modèle d’identité d’agent d’Entra ID est pensé comme un socle commun, que l’agent provienne de Copilot Studio, de Foundry, ou d’un développement interne. Vérifie toujours la documentation spécifique au produit agent que tu utilises, les modalités d’activation peuvent varier.

Que se passe-t-il si un agent n’a plus aucun sponsor identifiable ?

C’est précisément ce que le mécanisme de transfert automatique vers le manager du sponsor est censé éviter. En dernier recours, configure une politique d’alerte ou de désactivation automatique pour les agents qui resteraient sans sponsor valide au-delà d’un délai que tu définis.

Cette extension de Conditional Access vient compléter le changement d’enforcement que l’on avait couvert dans notre article sur Conditional Access et le changement d’enforcement de juin 2026 — les deux s’appuient sur la même mécanique de politiques, appliquée cette fois à une nouvelle catégorie d’identités. Et si tes agents tournent sur des appareils managés, ça vaut aussi le coup de relire notre article sur le bundling Intune dans M365 E3/E5, pour t’assurer que la conformité d’appareil exigée par ces nouvelles politiques est bien couverte par ta licence actuelle.

Si tu gères le parc de postes de ton organisation avec Microsoft Intune, l’été 2026 a changé la donne sans que tu aies eu grand-chose à faire : une bonne partie des fonctionnalités jusque-là vendues en add-on payant a migré directement dans tes licences Microsoft 365 E3 et E5. À côté de ça, Windows Autopatch a basculé le hotpatching en activé par défaut, et Intune continue d’élargir son périmètre sur Linux et Android. Voici ce qui a changé concrètement, et ce que ça implique pour ta feuille de route.

L’Intune Suite arrive dans tes licences M365, sans coût supplémentaire

Jusqu’ici, les fonctionnalités avancées de gestion des terminaux (Remote Help, Advanced Analytics, Endpoint Privilege Management…) nécessitaient l’add-on payant Intune Suite. Depuis l’été 2026, Microsoft les intègre progressivement dans les abonnements Microsoft 365 E3 et E5 existants.

Le partage entre les deux niveaux n’est pas identique :

• Microsoft 365 E3 reçoit Intune Plan 2 (Microsoft Tunnel, mises à jour firmware over-the-air, gestion des terminaux spécialisés), Remote Help et Advanced Analytics.
• Microsoft 365 E5 reçoit l’intégralité de l’Intune Suite, avec en plus les trois capacités premium qui restent exclusives à E5 : Endpoint Privilege Management (élévation de privilèges à la demande, sans compte admin permanent), Enterprise App Management, et Cloud PKI.

Le déploiement s’est fait progressivement entre juin et début août 2026, avec un préavis de 30 jours dans le centre d’administration avant le provisionnement automatique de chaque tenant — aucune action manuelle n’était nécessaire pour recevoir les entitlements. Deux points de vigilance si ce n’est pas encore fait de ton côté :

• Nettoyage des licences : si ton organisation payait déjà l’add-on Intune Suite en standalone, vérifie que tu ne payes pas en double à ton prochain renouvellement.
• Mise en service réelle : recevoir l’entitlement ne veut pas dire que la fonctionnalité est configurée. Endpoint Privilege Management en particulier change la façon dont tu gères les droits admin sur les postes — ça mérite une vraie phase de conception avant activation en masse, pas juste un clic dans le centre d’administration.

Windows Autopatch : le hotpatching passe en activé par défaut

Depuis la mise à jour de sécurité de mai 2026, les mises à jour hotpatch sont activées par défaut pour tous les appareils éligibles gérés via Windows Autopatch. Le principe : les correctifs de sécurité s’installent plus vite et avec beaucoup moins de redémarrages qu’une mise à jour cumulative classique, ce qui réduit la fenêtre d’exposition entre la sortie du correctif et son application effective sur le parc.

Si ton organisation n’est pas prête pour ce changement, deux options de désactivation existent, disponibles depuis le 1er avril 2026 dans le centre d’administration Intune :

• un réglage au niveau du tenant, qui désactive le hotpatching pour l’ensemble des appareils éligibles ;
• une stratégie de mise à jour qualité, qui permet de contrôler le comportement pour un groupe d’appareils spécifique — cette stratégie a priorité sur le réglage tenant pour les appareils qu’elle cible.

Autopatch update readiness : un tableau de bord unifié

Toujours côté Autopatch, la fonctionnalité update readiness centralise le suivi des mises à jour Windows sur l’ensemble des appareils, qu’ils soient gérés directement par Intune ou inscrits dans un groupe Windows Autopatch. Tu retrouves en un seul tableau de bord le parcours de mise à jour de chaque appareil, des alertes centralisées sur les échecs et conflits de stratégie, un vérificateur de préparation qui signale les appareils à risque (espace disque, compatibilité), et la possibilité de déclencher une réinstallation de l’OS à distance pour réparer les appareils bloqués. De quoi limiter les allers-retours de diagnostic manuel quand une campagne de mise à jour cale sur une partie du parc.

Linux et Android : le périmètre de gestion continue de s’élargir

Deux évolutions à noter si ton parc dépasse le seul Windows :

Côté Linux, Intune supporte désormais RHEL 9 LTS et RHEL 10 LTS. Le support de RHEL 8 LTS prend fin en juillet 2026 — les appareils déjà inscrits en RHEL 8 restent gérés, mais il vaut mieux planifier la bascule des postes restants plutôt que d’attendre une rupture de support.

Côté Android, Intune finalise sa migration vers l’Android Management API de Google pour les appareils personnels en mode profil professionnel (BYOD). Concrètement, ça apporte un enrôlement web sans installation d’application dédiée, et une nouvelle implémentation de la distribution des stratégies alignée avec ce qui existe déjà pour les appareils corporate. La migration se pilote par groupes ciblés plutôt qu’en bascule globale, ce qui te laisse la main sur le rythme.

Comment préparer ta feuille de route

• Vérifie dans le centre d’administration Microsoft Intune quelles licences Intune Suite ton tenant a effectivement reçues, et compare avec ce que tu payais déjà en add-on.
• Si tu es sur Windows Autopatch et que le hotpatching par défaut ne convient pas à ton contexte (applications sensibles au redémarrage, contraintes de test), configure le réglage tenant ou une stratégie de mise à jour qualité avant la prochaine campagne.
• Si Endpoint Privilege Management t’intéresse, commence par un pilote sur un groupe restreint : le changement de modèle (fin des comptes admin permanents) demande un accompagnement utilisateur, pas juste un déploiement technique.
• Recense tes postes RHEL 8 restants si applicable, et planifie leur migration avant que le manque de support ne devienne un problème de sécurité.

Ces changements de gestion des terminaux s’articulent naturellement avec tes politiques d’accès conditionnel : plus la conformité des appareils remonte finement dans Intune, plus tes règles dans Entra ID peuvent s’appuyer dessus. Si tu n’as pas encore revu tes règles suite au changement d’enforcement de l’accès conditionnel de juin 2026, c’est le bon moment de faire les deux en même temps.

FAQ

Dois-je faire une demande pour recevoir les nouvelles licences Intune Suite ?

Non. Le provisionnement s’est fait automatiquement pour les tenants disposant de licences Microsoft 365 E3 ou E5, avec un préavis de 30 jours affiché dans le centre d’administration avant l’activation. Si ton déploiement n’a pas encore eu lieu, vérifie l’état dans le centre d’administration Microsoft 365 plutôt que d’ouvrir un ticket support.

Le hotpatching remplace-t-il complètement les mises à jour cumulatives classiques ?

Non, il s’y ajoute en alternance : les hotpatchs couvrent les mois intermédiaires sans redémarrage lourd, tandis que les mises à jour cumulatives de référence (baseline) restent appliquées périodiquement selon le cycle Windows Autopatch.

Que se passe-t-il pour mes appareils RHEL 8 après juillet 2026 ?

Ils restent inscrits et gérés, mais ne bénéficient plus des correctifs et évolutions associés au support LTS. Migrer vers RHEL 9 ou 10 reste recommandé dès que possible plutôt que de laisser ces postes sur une version non supportée.

En résumé

2026 aura été une année de simplification côté licences Intune (Suite intégrée dans E3/E5) et de durcissement côté exploitation (hotpatching par défaut, meilleure visibilité sur la préparation aux mises à jour). Rien de tout ça n’exige une action dans l’urgence, mais chaque point mérite une vérification de ton côté : les licences que tu payes peut-être encore en double, le comportement de mise à jour que tu n’as peut-être pas choisi, et le périmètre Linux/Android qui s’est élargi pendant que tu avais le dos tourné.

Si tu administres un tenant Microsoft Entra ID, une échéance mérite ton attention avant l’été : à partir du 15 juin 2026, Microsoft change la façon dont les Conditional Access policies gèrent les exclusions de ressources. Le changement corrige une vraie faille de sécurité, mais il peut aussi bloquer des applications qui fonctionnaient sans souci jusque-là si tu ne l’anticipes pas. Voici ce qui change, pourquoi, et comment vérifier que ton tenant est prêt.

Le problème que ce changement corrige

Jusqu’à présent, quand une Conditional Access policy ciblait « All resources » (toutes les ressources) tout en excluant certaines applications, ces applications exclues échappaient aussi à l’enforcement sur ce que Microsoft appelle les baseline scopes — des permissions considérées comme peu sensibles par défaut : lecture du profil de l’utilisateur (User.Read, profile, openid…), appartenance aux groupes, informations de base sur les collègues.

Concrètement, ça veut dire qu’une application desktop comme Azure CLI ou VS Code, qui ne demande que ces scopes basiques, pouvait passer complètement à côté de tes politiques MFA — même sur un tenant où la MFA est censée être obligatoire pour tout le monde. À partir du 15 juin 2026, ces baseline scopes sont évalués comme un accès normal à l’annuaire, et donc soumis aux Conditional Access policies même en présence d’exclusions.

Qui est concerné ?

• Les applications qui ne demandent que des baseline scopes (OIDC : email, offline_access, openid, profile ; annuaire : User.Read, User.Read.All, User.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.All, Member.Read.Hidden)
• Les policies ciblant « All resources » avec des exclusions de ressources configurées

Si tes applications demandent déjà des scopes plus larges (Mail.Read, Files.ReadWrite, etc.), rien ne change pour toi : elles étaient déjà soumises à l’enforcement.

Comment vérifier si ton tenant est concerné

1. Repérer les policies à risque

Dans le portail Entra, filtre tes Conditional Access policies pour identifier celles qui ciblent « All resources » avec au moins une exclusion d’application. Ce sont les seules concernées par le changement.

2. Auditer les connexions réelles avec Microsoft Graph

Pour savoir quelles applications de ton tenant s’appuient sur ces exclusions, tu peux interroger les logs de connexion via l’API Microsoft Graph :

GET https://graph.microsoft.com/beta/auditLogs/signIns?$filter=createdDateTime ge 2026-05-26T00:00:00Z and createdDateTime lt 2026-05-27T00:00:00Z and conditionalAccessAudiences/any(a:a eq '<ton-app-id>')&$select=createdDateTime,appId,appDisplayName,userDisplayName,userPrincipalName,ipAddress,conditionalAccessStatus

Si tu préfères scripter cet audit plutôt que de passer par des requêtes REST brutes, le module PowerShell Microsoft Graph (Microsoft.Graph.Reports) permet de faire la même chose avec des cmdlets plus lisibles à intégrer dans un script de contrôle régulier — on détaille les bases de l’automatisation PowerShell côté administration système dans notre guide complet PowerShell pour administrateurs.

3. Tester avant le 15 juin

Microsoft permet d’activer l’enforcement dès maintenant, avant la bascule automatique, pour tester son impact dans un tenant de test ou avec un groupe pilote. C’est l’option la plus sûre : tu identifies les applications qui vont réclamer un défi MFA avant que ça n’arrive en production sans prévenir.

Tes trois options

Option A — Activer l’enforcement (recommandé)

Depuis les paramètres Baseline scopes, connecte-toi avec un rôle Conditional Access Administrator, sélectionne « Enable enforcement », puis confirme. C’est l’option qui referme la faille de sécurité pour de bon.

Option B — Personnaliser par application (approche hybride)

Si une application métier a vraiment besoin de rester exclue, crée une application « placeholder » dédiée dans Entra ID, exclus-la explicitement des policies concernées, puis configure ce comportement personnalisé dans les paramètres Baseline scopes plutôt que de désactiver l’enforcement pour tout le monde.

Option C — Désactiver l’enforcement

Techniquement possible, mais déconseillé : ça revient à conserver la faille corrigée par ce changement. À réserver aux cas de blocage critique le temps de trouver une solution propre.

Et si tu ne fais rien ?

L’enforcement s’active automatiquement à partir du 15 juin 2026, en rollout progressif sur plusieurs semaines. Si tu n’as pas d’exclusions configurées sur tes policies « All resources », ce changement ne te concerne tout simplement pas. Si tu en as, mieux vaut avoir testé et anticipé plutôt que de découvrir un blocage de connexion un lundi matin.

FAQ

Ce changement s’applique-t-il à toutes les licences Entra ID ?

Les Conditional Access policies nécessitent Microsoft Entra ID P1 au minimum ; le changement d’enforcement s’applique à tout tenant utilisant déjà ce type de policies avec des exclusions de ressources, quelle que soit la volumétrie.

Comment savoir si mes comptes de secours (break-glass) sont concernés ?

Les comptes d’urgence doivent rester exclus de toutes tes policies Conditional Access par principe, y compris de celle-ci — ce changement ne remet pas en cause cette bonne pratique fondamentale, tant que l’exclusion reste documentée et surveillée.

Où suivre les prochaines évolutions des Conditional Access policies ?

Le blog officiel Microsoft Entra sur Tech Community et la documentation Microsoft Learn dédiée à ce changement sont mis à jour au fil du rollout.

En résumé

Ce changement d’enforcement referme une faille bien réelle, mais il demande une vérification active de ta part avant le 15 juin 2026 si tes policies « All resources » comportent des exclusions. Prends le temps d’auditer tes applications, de tester en mode pilote, et de documenter les exceptions que tu choisis de garder. Pour construire tes politiques Conditional Access sur des bases solides dès le départ, la documentation Microsoft Learn sur la planification du déploiement reste la référence à suivre, phase par phase.