Ce que Microsoft modifie dans le SSPR d'Entra ID
Depuis le bulletin de sécurité Entra de juin 2026 (« Microsoft Entra ID Security Updates : What Organizations Need to Do Now »), Microsoft Entra ID tire un trait sur un comportement historique du Self-Service Password Reset (SSPR) : la possibilité de s'appuyer sur des attributs de profil utilisateur — mobile, otherMobile, mail — pour vérifier l'identité lors d'une réinitialisation de mot de passe.
À partir du 7 septembre 2026, seules les méthodes d'authentification explicitement enregistrées dans le registre des méthodes d'Entra ID seront acceptées pour la vérification SSPR. Un numéro de téléphone alimenté par la synchro RH ou un script de provisioning, et jamais formellement enregistré via My Security Info ou l'API Microsoft Graph, ne constituera plus une preuve valide.
Enforcement au 7 septembre 2026
La campagne d'enregistrement poussée par Microsoft est active depuis le 6 juillet 2026 dans tous les tenants où le SSPR est activé. L'enforcement entre en vigueur le 7 septembre 2026. Les administrateurs sont inclus dans le périmètre.
Attribut de profil vs méthode enregistrée : une distinction fondamentale
Entra ID a toujours distingué deux sources d'information :
- Les attributs de l'objet utilisateur (
mobile,otherMail, etc.) : inscriptibles par les admins, les workflows de provisioning, la synchro Microsoft Entra Connect ou des scripts AD On-Premises. Ils ne portent aucune preuve de possession. - Les méthodes d'authentification enregistrées : gérées par l'Authentication Methods policy, visibles dans My Security Info, elles attestent que l'utilisateur a démontré le contrôle effectif du canal au moment de l'enregistrement.
Historiquement, le SSPR acceptait les deux sources. Ce raccourci disparaît. Le registre des méthodes devient l'unique source de vérité, dans la continuité de la bascule du 30 septembre 2025 qui avait déjà consolidé les anciennes policies per-user MFA et SSPR vers l'Authentication Methods policy.
La liste des méthodes supportées par le SSPR ne change pas : Microsoft Authenticator, SMS, appel vocal, clés FIDO2, Passkeys et autres méthodes autorisées par votre policy restent utilisables. La seule exigence nouvelle est que la méthode soit enregistrée comme méthode d'authentification — pas déduite d'un champ de profil.
Qui sera impacté le 7 septembre
Le profil exposé est prévisible : tout environnement hybride ayant construit son SSPR sur des numéros synchronisés depuis l'Active Directory On-Premises, précisément parce que c'était le chemin le plus rapide pour ouvrir le service sans campagne d'enregistrement préalable.
Ces utilisateurs ne présentent aucun symptôme en production :
- Leur connexion fonctionne normalement.
- Leur MFA, s'ils en disposent un, est opérationnel.
- Rien ne signale de problème dans les dashboards.
Le problème se manifeste uniquement lors d'une réinitialisation de mot de passe — c'est-à-dire au moment précis où le SSPR était censé éviter un ticket helpdesk. Le risque est un pic de tickets étalé sur plusieurs semaines, utilisateur par utilisateur, avec des comptes déjà verrouillés au moment où l'on s'en aperçoit.
Changement silencieux
Rien ne casse à la connexion le 7 septembre. Aucune alerte dashboard. La rupture se produit au premier reset raté, pour chaque utilisateur concerné individuellement.
Cinq angles morts que l'annonce officielle ne met pas en avant
L'enregistrement par l'administrateur est un levier de masse légitime
L'enregistrement ne passe pas uniquement par My Security Info. Un administrateur peut ajouter des méthodes d'authentification — numéro de téléphone inclus — directement depuis le centre d'administration Entra (fiche utilisateur > Authentication methods) ou via l'API Microsoft Graph des méthodes d'authentification. Une méthode ajoutée par ce canal est une méthode enregistrée à part entière.
Ce levier est particulièrement utile pour les populations sans smartphone, les comptes à faible autonomie numérique ou les sites industriels. Attention toutefois : un numéro erroné dans les attributs de profil deviendrait une méthode enregistrée erronée. Ce chemin ne vaut que pour les données dont la fiabilité est avérée.
La compatibilité SSPR repose sur trois conditions, pas une
Un utilisateur ayant enregistré une méthode n'est pas automatiquement « SSPR Capable ». Les trois conditions cumulatives sont :
- Avoir au moins une méthode enregistrée.
- Que cette méthode figure parmi celles autorisées par la SSPR policy.
- Que le nombre de méthodes enregistrées atteigne le seuil exigé par la policy (1 ou 2 méthodes selon la configuration).
Cas classique : des utilisateurs équipés de Microsoft Authenticator qui ressortent « Not Capable » parce que la méthode n'est pas activée côté SSPR, ou parce que la policy exige deux méthodes et qu'ils n'en ont enregistré qu'une.
Le portail donne la réponse sans script : Entra ID > Authentication methods > User registration details, filtre SSPR Capable : Not Capable. C'est la liste nominative des comptes qui échoueront après le 7 septembre.
La campagne s'exécute sous vos Conditional Access existants
La campagne de Microsoft oriente les utilisateurs vers le flux d'enregistrement des informations de sécurité. Ce flux est soumis aux policies Conditional Access ciblant l'action Register security information. Si votre policy d'enregistrement exige un appareil conforme ou un réseau de confiance, un utilisateur distant non conforme sollicité par la campagne peut se retrouver bloqué : invité à enregistrer une méthode, mais incapable de le faire.
Testez le parcours complet depuis un poste hors réseau avant toute communication aux utilisateurs.
Le scoping par groupe reste ambigu
Microsoft n'a pas confirmé, dans la Q&A officielle, que la campagne se restreint au groupe cible du SSPR quand celui-ci est scopé. L'hypothèse de travail prudente : des utilisateurs hors du groupe SSPR peuvent recevoir l'invitation. Préparez votre communication pour l'ensemble du tenant, pas uniquement pour le périmètre SSPR déclaré — un utilisateur qui reçoit une invitation inattendue sans contexte peut la signaler comme tentative de phishing.
Les comptes à privilèges et break-glass sont explicitement dans le scope
Le bulletin Microsoft cible « administrators and end users ». La politique SSPR des comptes d'administration est distincte de celle des utilisateurs standard, active par défaut, avec une exigence de deux méthodes. Tout compte admin ou break-glass qui comptait sur un e-mail alternatif posé dans le profil perd ce filet le 7 septembre. Ces comptes doivent être traités en priorité, avec des méthodes phishing-resistant de préférence (Passkeys, FIDO2, Certificate-Based Authentication).
Récapitulatif des dates et du périmètre
| Élément | Statut | Action requise |
|---|---|---|
| Campagne d'enregistrement Microsoft | Active depuis le 6 juillet 2026 | Informer le helpdesk et les utilisateurs : invitation légitime, pas du phishing |
| Enforcement SSPR – méthodes enregistrées uniquement | 7 septembre 2026 | Viser zéro exposition avant le 24 août 2026 |
| Méthodes SSPR supportées | Inchangées | Vérifier l'alignement entre SSPR policy et méthodes réellement enregistrées |
| Population concernée | Tous tenants SSPR activé, admins inclus | Traiter les comptes à privilèges et break-glass en premier |
| CA à l'enrôlement + retrait Custom Controls | Actif depuis le 6 juillet – échéance 30 septembre 2026 | Regrouper les trois volets dans un même dossier de décision |
Lab Express : mesurer votre exposition en lecture seule
Les deux scripts suivants ne réalisent aucune modification. Ils nécessitent le scope AuditLog.Read.All sur Microsoft Graph.
Quantifier l'exposition globale
1# Lecture seule : scope AuditLog.Read.All, aucune modification2Connect-MgGraph -Scopes "AuditLog.Read.All"3 4Get-MgReportAuthenticationMethodUserRegistrationDetail -All |5 Group-Object IsSsprCapable |6 Select-Object Name, CountCe premier script retourne la répartition des comptes selon leur statut IsSsprCapable. Le chiffre False représente votre exposition brute.
Obtenir la liste nominative des comptes à risque
1# Comptes qui échoueront au SSPR après le 7 septembre 20262Get-MgReportAuthenticationMethodUserRegistrationDetail -All |3 Where-Object { -not $_.IsSsprCapable } |4 Select-Object UserPrincipalName, IsAdmin, @{n='Methodes'; e={ $_.MethodsRegistered -join ', ' }}La colonne Methodes indique ce que chaque utilisateur a déjà enregistré, ce qui oriente directement la remédiation : manque de méthode autorisée, méthode non reconnue par la SSPR policy, ou nombre insuffisant.
Export et suivi de couverture
Ajoutez | Export-Csv -Path .\sspr-exposure.csv -NoTypeInformation -Encoding UTF8 en fin de pipeline pour disposer d'un fichier exploitable en tableau de bord. Relancez le script chaque semaine pour mesurer la progression de la couverture.
Plan de remédiation avant le 7 septembre
Mesurer l'exposition aujourd'hui
Lancez les deux scripts du Lab Express. Exportez les résultats et communiquez le chiffre d'exposition à votre management. Fixez l'objectif : zéro compte non compatible sur la population SSPR avant le 24 août 2026, avec deux semaines de marge avant l'enforcement.
Traiter les comptes à privilèges et break-glass en priorité
Identifiez tous les comptes admin et break-glass dans le résultat de l'export (IsAdmin = True). Enregistrez des méthodes fortes — Passkeys, FIDO2 ou Certificate-Based Authentication — testez-les, et documentez la procédure de déblocage par Temporary Access Pass (TAP) pour les scénarios d'urgence.
Déployer les trois leviers de remédiation en parallèle
Trois populations, trois chemins :
- Auto-enregistrement : communication interne courte qui légitime l'invitation de la campagne Microsoft et oriente vers My Security Info. C'est le canal de masse.
- Enregistrement par l'admin : pour les populations sans smartphone ou à faible autonomie, transformez les numéros de référentiel validés en méthodes enregistrées via la fiche utilisateur Entra ou l'API Microsoft Graph, par lots contrôlés.
- Temporary Access Pass : pour les cas bloqués (perte de téléphone, onboarding), un TAP permet d'amorcer l'enregistrement d'une méthode forte sans dépendre d'un mot de passe.
Valider la configuration avant de pousser les utilisateurs
Trois contrôles côté configuration :
- Tester le parcours d'enregistrement de bout en bout depuis un poste distant, pour vérifier que vos policies Conditional Access ciblant Register security information ne créent pas d'impasse.
- Vérifier que les méthodes autorisées dans la SSPR policy correspondent aux méthodes que vos utilisateurs enregistrent réellement, seuil de méthodes requis inclus.
- Profiter de la vague d'enregistrements pour orienter vers des méthodes phishing-resistant plutôt que de reconduire SMS par défaut.
Préparer l'après : helpdesk et surveillance
Avant le 8 septembre, briefez le helpdesk sur le scénario « reset échoué, méthode non enregistrée » et sa procédure de déblocage par TAP. Activez une surveillance des échecs SSPR dans les audit logs d'Entra ID les premières semaines suivant l'enforcement. Ce volet s'inscrit dans le même bulletin de juin que le Conditional Access à l'enrôlement et le retrait des Custom Controls (échéance 30 septembre 2026) : regroupez les trois dans un seul dossier de décision.
Référence officielle
La Q&A Microsoft dédiée à ce changement est disponible sur Microsoft Learn. Le bulletin de sécurité Entra de juin 2026 documente l'ensemble des mesures de durcissement associées.
