Entra ID SSPR méthodes enregistrées uniquement novembre 2026 : ce qui casse et comment corriger

Entra ID SSPR méthodes enregistrées uniquement novembre 2026 : ce qui change

À partir du 9 novembre 2026, Microsoft Entra ID SSPR n'acceptera plus que les méthodes enregistrées pour la vérification de réinitialisation de mot de passe — exactement le changement que l'intérêt de recherche désigne déjà sous le terme Entra ID SSPR méthodes enregistrées uniquement novembre 2026. Les informations de contact issues de l'annuaire — les attributs mobilePhone, businessPhone et otherMails, alimentés via la synchronisation Microsoft Entra Connect ou renseignés directement par un administrateur — ne compteront plus comme vérification SSPR valide, sauf si l'utilisateur a explicitement enregistré ce même numéro de téléphone ou cette même adresse e-mail comme méthode d'authentification.

Il s'agit d'un resserrement discret mais lourd de conséquences. De nombreux tenants se sont appuyés sur des attributs de contact synchronisés ou renseignés par un administrateur comme solution de secours SSPR implicite, car ces valeurs permettent à un utilisateur de réinitialiser un mot de passe oublié même s'il n'est jamais passé par le flux d'enregistrement des méthodes d'authentification de Microsoft — un comportement que confirme aujourd'hui même la documentation Microsoft sur le pré-remplissage des données de contact SSPR. Selon l'avis de déploiement de Microsoft (Message Center MC1325414), environ 86 % des vérifications SSPR utilisent déjà aujourd'hui des méthodes enregistrées — ce qui signifie aussi qu'une minorité significative de réinitialisations ne réussit actuellement que grâce à cette solution de secours bientôt supprimée.

Microsoft déploie ce changement en deux étapes datées, confirmées dans l'article Microsoft Learn ci-dessus et dans le Message Center MC1325414 :

• 5 octobre 2026 — une campagne d'enregistrement intégrée commence à inciter les utilisateurs connectés et les administrateurs qui n'ont pas encore assez de méthodes enregistrées à compléter le SSPR conformément à leur stratégie. Aucune action administrateur n'est requise pour l'activer.
• 9 novembre 2026 — application : la vérification SSPR n'accepte plus que les méthodes explicitement enregistrées. Les numéros de téléphone et adresses e-mail issus de l'annuaire mais non enregistrés cessent de fonctionner, point final.

Le blog Microsoft Entra présente ceci comme la fermeture d'un écart de longue date : le SSPR n'a jamais été censé faire confiance à des attributs dont personne n'a vérifié la propriété. Un numéro de téléphone synchronisé depuis un champ telephoneNumber/mobile on-prem, ou saisi dans le profil d'un utilisateur par un administrateur lors de l'onboarding, peut être obsolète, réattribué, ou tout simplement erroné — et jusqu'à présent, il pouvait quand même réinitialiser le mot de passe de cet utilisateur.

Ce changement s'inscrit dans une vague plus large de modifications d'authentification Entra cette année, aux côtés du retrait de la MFA SMS/voix au profit des passkeys et du retrait des contrôles personnalisés dans Conditional Access — aucun n'étant facultatif à ignorer si votre tenant s'appuie encore sur des solutions de secours d'authentification héritées.

Détection

Comme les méthodes enregistrées et non enregistrées fonctionnent aujourd'hui de façon identique pour le SSPR, aucun événement du journal de connexion ne signale « cette réinitialisation a utilisé une méthode non enregistrée » — l'écart ne devient visible que si vous inventoriez directement la couverture d'enregistrement, avant l'échéance du 9 novembre.

Interrogez directement via Microsoft Graph PowerShell :

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

Get-MgReportAuthenticationMethodUserRegistrationDetail -All `
  -Filter "isSsprEnabled eq true and isSsprCapable eq false" |
  Select-Object UserPrincipalName, IsSsprRegistered, IsSsprCapable, MethodsRegistered

Ou l'appel Graph REST équivalent :

GET https://graph.microsoft.com/v1.0/reports/authenticationMethods/userRegistrationDetails?$filter=isSsprCapable eq false and isSsprEnabled eq true

Chaque utilisateur retourné par cette requête peut aujourd'hui réinitialiser son mot de passe via un attribut issu de l'annuaire, et ne le pourra plus le 9 novembre — un pic d'appels au support prêt à se déclencher si ce n'est pas corrigé au préalable.

Remédiation

1. Faites l'inventaire maintenant. Récupérez le rapport complet userRegistrationDetails et isolez chaque compte activé pour le SSPR où isSsprCapable est false. Priorisez les comptes à rôles privilégiés — un administrateur exclu du SSPR a un parcours de récupération bien plus coûteux. Notre guide d'audit de la sécurité Microsoft Entra ID couvre ce rapport ainsi que le reste de votre posture MFA et Conditional Access.
2. Enregistrez de vraies méthodes, pas des copies d'annuaire. Faites terminer aux utilisateurs concernés le flux d'enregistrement combiné MFA/SSPR afin qu'un numéro de téléphone ou un e-mail soit explicitement enregistré, pas simplement présent comme attribut de profil. Enregistrer mobilePhone comme méthode d'authentification est une action ponctuelle par utilisateur, pas automatique. Dans la mesure du possible, orientez les utilisateurs vers une passkey comme première méthode enregistrée plutôt que téléphone/e-mail, car elle satisfait à la fois les exigences MFA et SSPR en une seule fois.
3. Vérifiez le nombre de méthodes requis par votre stratégie SSPR. Dans Centre d'administration Entra → Méthodes d'authentification → Propriétés de réinitialisation de mot de passe, vérifiez combien de méthodes votre stratégie exige. Si ce nombre est fixé à un, les lacunes d'enregistrement touchent moins de monde ; si c'est deux, les lacunes s'accumulent.
4. Ne comptez pas uniquement sur la campagne. La campagne d'enregistrement du 5 octobre ne sollicite que les utilisateurs qui manquent déjà de méthodes — elle ne remplit rien rétroactivement, et elle peut être exclue pour des groupes spécifiques. Communiquez directement l'échéance du 9 novembre à votre organisation plutôt que de supposer que les rappels intégrés atteindront tout le monde à temps.
5. Relancez le rapport avant le 9 novembre. Confirmez que isSsprCapable vaut true pour chaque utilisateur activé pour le SSPR, puis vérifiez à nouveau après l'échéance pour rattraper les retardataires avant qu'ils n'appellent le support.

Comment EtcSec détecte cela

L'audit Entra ID d'EtcSec vérifie exactement ce type de lacune d'enregistrement. AUTH_METHODS_NO_REGISTRATION signale les tenants qui n'ont pas activé la campagne d'enregistrement des méthodes d'authentification de Microsoft, SSPR_NOT_ENABLED signale un SSPR totalement désactivé, et SSPR_NOT_REQUIRED_ADMINS détecte le cas le plus à risque — des administrateurs exemptés des exigences d'enregistrement SSPR, qui sont sur le point de perdre leur solution de secours non enregistrée en même temps que tout le monde.