SSPR Entra ID évolue : à partir du 7 septembre 2026, la réinitialisation de mot de passe en self-service n’acceptera plus que les méthodes d’authentification explicitement enregistrées. Décryptage d’un changement qui paraît procédural, mais qui touche un point sensible de la chaîne d’identité.
Le résumé en une phrase
Un numéro de téléphone qui existe dans l’annuaire n’est pas, à lui seul, une preuve d’identité. C’est exactement cet écart que Microsoft corrige avec la notification MC1325414, publiée le 28 mai 2026 dans le Centre de messages M365.
Ce qui se passe aujourd’hui
Le SSPR (Self-Service Password Reset) permet à un utilisateur de réinitialiser son mot de passe sans passer par un administrateur. C’est pratique : ça réduit la charge du support et ça redonne la main à l’utilisateur au moment précis où il est bloqué.
Le problème est dans le détail de la vérification d’identité. Aujourd’hui, dans certains cas, le SSPR peut accepter des informations de contact stockées comme simples attributs d’annuaire (mobilePhone, businessPhone, otherMails) pour vérifier qui vous êtes, même si ces valeurs n’ont jamais été enregistrées comme méthodes d’authentification.
Concrètement : un numéro de mobile saisi par la RH à l’embauche, ou un email alternatif renseigné lors de l’onboarding, pouvait silencieusement devenir un facteur de récupération de compte, sans aucune démarche d’enrôlement délibérée. Ça rendait le SSPR plus facile à déployer, et plus flatteur dans les rapports de couverture, mais ça brouillait une frontière importante : la différence entre « on sait comment joindre cette personne » et « on fait confiance à ce facteur pour prouver son identité ».
Ce qui change le 7 septembre 2026
À partir de cette date, seules les méthodes d’authentification explicitement enregistrées et validées au préalable seront acceptées pour la réinitialisation. Les informations de contact qui n’existent que sous forme d’attribut d’annuaire ne seront plus reconnues.
Le changement s’inscrit dans la Secure Future Initiative de Microsoft, sa démarche de fond pour renforcer la vérification d’identité sur l’ensemble de ses plateformes. Il concerne tous les utilisateurs, administrateurs compris, dans les tenants où le SSPR est activé, sur le cloud public comme sur les clouds gouvernementaux américains (GCC, GCC High, DoD).
Le calendrier à retenir :
- 6 juillet 2026 : démarrage de la campagne d’enregistrement, qui invite automatiquement les utilisateurs et administrateurs à enregistrer des méthodes.
- 7 septembre 2026 : entrée en vigueur. Le SSPR cesse d’accepter les informations de contact issues de l’annuaire.
Pourquoi c’est une bonne décision
Sur le principe, il n’y a pas de débat : c’est le bon réflexe de sécurité. Un attribut d’annuaire n’est pas un facteur de confiance. Il peut avoir été renseigné par un tiers (un système RH, un script de provisioning), il n’a pas été validé par l’utilisateur, et il n’a jamais fait l’objet d’un consentement explicite à servir de méthode de récupération.
En exigeant des méthodes réellement enregistrées et validées, Microsoft réduit la surface d’attaque sur l’un des points les plus sensibles du cycle de vie d’un compte : le moment où un utilisateur verrouillé, ou un attaquant, tente de reprendre la main. C’est précisément là qu’un facteur faible fait le plus de dégâts.
Là où ça va faire mal : l’opérationnel
La vraie histoire de cette notif n’est pas le changement technique, qui est simple. C’est son impact sur les organisations qui ont traité la couverture SSPR comme une case à cocher plutôt que comme un cycle de vie d’identité.
Si une partie de vos utilisateurs s’appuyaient, sans le savoir, sur un attribut d’annuaire pour passer la vérification, ces utilisateurs ne pourront plus réinitialiser seuls leur mot de passe après le 7 septembre. Résultat direct : un report de charge vers le helpdesk, au pire moment, sur une opération (le reset) qui était censée justement le décharger.
Deux angles morts classiques méritent une attention particulière :
- Les comptes à privilèges. Ce sont souvent les moins bien enregistrés, parce qu’ils sont créés à part, en dehors des campagnes habituelles. Or ce sont eux qu’il faut le moins voir bloqués.
- Les utilisateurs « couverts sur le papier ». Un rapport qui affiche un bon taux de couverture SSPR ne dit pas combien de cette couverture reposait sur des attributs d’annuaire qui vont disparaître. Le chiffre rassurant d’aujourd’hui peut cacher le problème de demain.
La checklist SSPR Entra ID avant la rentrée
L’action est à mener avant le 7 septembre 2026. Trois étapes simples :
- Auditer la couverture réelle. Entra admin center > Authentication methods > User registration details. L’objectif : vérifier que chaque utilisateur, administrateurs inclus, dispose d’au moins une méthode d’authentification enregistrée qui satisfait votre politique SSPR.
- Activer ou autoriser la campagne d’enregistrement. Elle démarre le 6 juillet et invite automatiquement les utilisateurs à enregistrer leurs méthodes. C’est votre meilleur levier pour combler le retard sans intervention manuelle.
- Préparer le helpdesk et la communication. Prévoyez un processus d’enregistrement assisté pour les retardataires, et communiquez en amont aux utilisateurs pour éviter les resets en échec. Traitez les comptes sensibles en priorité.
En résumé
MC1325414 a l’air procédural, mais il corrige une vraie ambiguïté : un moyen de contact n’est pas une preuve d’identité. La décision est saine. Le seul risque réside dans l’inertie : une bonne mesure de sécurité ne coûte rien quand elle est anticipée, et cher quand elle est subie un lundi matin de septembre, ticket après ticket.
Le travail à faire d’ici là n’est pas technique, il est organisationnel : savoir où vous en êtes réellement, et combler les trous avant que l’échéance ne le fasse à votre place.
Source : Microsoft 365 Message Center, notice MC1325414 (28 mai 2026). Documentation officielle : Microsoft Entra architecture icons et SSPR sur Microsoft Learn.