Since 7 September 2026, Microsoft Entra ID self-service password reset (SSPR) only verifies users with authentication methods they have explicitly registered. Contact details that exist only as directory attributes, such as the mobilePhone, businessPhone and otherMails fields, no longer count. Microsoft announced the change in Message Center item MC1325414 and ran a registration campaign from 6 July to prepare users.
The fix closes a quiet account takeover path. The side effect is that some users, and some admin and service accounts, can no longer reset their own passwords.
What's affected
Every tenant with SSPR enabled, in the public cloud and the US government clouds, according to the Message Center text. Rollout was scheduled for early to mid-September 2026.
Before the change, SSPR could fall back to contact information stored on the user object to send a code. Those attributes are often populated by HR sync, on-premises Active Directory through Entra Connect, or bulk scripts, and nobody ever proved the user controlled that phone or mailbox. After the change, only methods registered through My Security Info, or set by an admin as an authentication method, are accepted.
Microsoft said about 86% of SSPR verifications already used registered methods before enforcement. Office 365 for IT Pros applied the remaining 14% to Microsoft 365's 450 million paid seats and estimated about 67.5 million accounts could be affected. That is a rough upper bound, not a Microsoft figure.
Users without a registered method can't complete a reset. They are prompted to register, or told to contact an administrator.
How to check if you're exposed
List SSPR-enabled users who haven't registered for SSPR. With the Microsoft Graph PowerShell SDK and the AuditLog.Read.All permission:
Connect-MgGraph -Scopes "AuditLog.Read.All"
Get-MgReportAuthenticationMethodUserRegistrationDetail -All `
-Filter "isSsprEnabled eq true and isSsprRegistered eq false" |
Select-Object UserPrincipalName, IsAdmin, IsSsprCapable, MethodsRegistered |
Export-Csv sspr-unregistered.csv -NoTypeInformation
The same data is in the Entra admin center under Authentication methods, User registration details. It is a summary report and can lag behind real time.
Then sort the list:
- Admins (
IsAdmintrue). An admin who can't reset is a help desk ticket during an incident. - Shared and service accounts that sign in interactively. These often had a phone attribute set and no registered method.
- Break-glass accounts. If your emergency access process relied on SSPR to a directory phone number, it no longer works.
What to do now
- Run the report weekly until the unregistered count is near zero.
- Pre-register methods for users who can't do it themselves. Admins can add a phone or email authentication method for a user in the Entra admin center, or through the Graph authentication methods API. Verify the number with the user first. Copying an unverified directory attribute into an authentication method recreates the risk Microsoft just removed.
- Set up a help desk path with real identity verification for users who can't self-register. This is now a likely target for social engineering, so write the script and require a callback or manager approval.
- Fix break-glass accounts. They should rely on FIDO2 keys and stored credentials, not SSPR.
- Watch the SMS retirement too. Microsoft's separate retirement of Microsoft-provided SMS and voice on 1 February 2027 also applies to SSPR, so a phone method registered today is a short-term fix. Plan for passkeys or the Authenticator app.
Why it matters
Directory attributes are not identity proof. Anyone who could edit a user's mobilePhone, through a compromised sync source, an over-permissioned HR integration or a careless admin script, could then reset that user's password. That is an account takeover path that never touches MFA.
Microsoft framed this change as part of its Secure Future Initiative, and it fits a pattern of identity providers tightening recovery flows. Recovery is where attackers go when sign-in is hard. Once phishing-resistant MFA is in place, the weakest link is often whatever lets a user prove who they are when they've lost everything else.
The operational lesson is the help desk. Every recovery path you tighten pushes more people to a human, and that human needs a process attackers can't talk their way through.
Try it yourself
Run the PowerShell report above and export it. Count unregistered admins and unregistered service accounts separately, then open a tracked task for each group with an owner and a deadline. The demo below shows how evidence for controls like this can be collected automatically for audits.
Click through it at your own pace, or open it full screen.
Quick check
A user has a mobile number in their Entra profile. Can they still reset via SSPR?
Only if that number is also registered as an authentication method. A number that exists only as a directory attribute no longer counts.
Is it safe for admins to bulk-copy mobilePhone into authentication methods?
It removes the user friction but recreates the old risk, because nobody verified the user controls that number. Verify before you register a method on a user's behalf.
Which report shows who is affected?
User registration details in the Entra admin center, or Get-MgReportAuthenticationMethodUserRegistrationDetail filtered on isSsprEnabled eq true and isSsprRegistered eq false.
Sources
- Office 365 for IT Pros: Microsoft Tightens Security for Self-Service Password Reset
- Petri: Microsoft Entra ID SSPR to Require Registered Authentication Methods
- MC1325414 reproduction: Entra ID SSPR will require registered authentication methods starting September 7, 2026
- Microsoft Learn: FAQ for Microsoft-provided SMS and voice retirement