What Microsoft is changing in Entra ID SSPR
Since the Entra security bulletin from June 2026 ("Microsoft Entra ID Security Updates: What Organizations Need to Do Now"), Microsoft Entra ID is putting an end to a historical behavior of Self-Service Password Reset (SSPR): the ability to rely on user profile attributes — mobile, otherMobile, mail — to verify identity during a password reset.
Starting September 7, 2026, only authentication methods explicitly registered in the Entra ID method registry will be accepted for SSPR verification. A phone number populated by HR sync or provisioning script, and never formally registered via My Security Info or the Microsoft Graph API, will no longer constitute valid proof.
Enforcement on September 7, 2026
The registration campaign pushed by Microsoft has been active since July 6, 2026 in all tenants where SSPR is enabled. Enforcement takes effect on September 7, 2026. Administrators are included in the scope.
Profile attribute vs registered method: a fundamental distinction
Entra ID has always distinguished between two sources of information:
- User object attributes (
mobile,otherMail, etc.): writable by admins, provisioning workflows, Microsoft Entra Connect sync, or On-Premises AD scripts. They carry no proof of possession. - Registered authentication methods: managed by the Authentication Methods policy, visible in My Security Info, they attest that the user has demonstrated effective control of the channel at the time of registration.
Historically, SSPR accepted both sources. This shortcut is disappearing. The method registry becomes the sole source of truth, continuing the shift from September 30, 2025 that had already consolidated legacy per-user MFA and SSPR policies toward the Authentication Methods policy.
The list of methods supported by SSPR does not change: Microsoft Authenticator, SMS, voice call, FIDO2 keys, Passkeys, and other methods authorized by your policy remain usable. The only new requirement is that the method be registered as an authentication method — not inferred from a profile field.
Who will be impacted on September 7
The exposed profile is predictable: any hybrid environment that built its SSPR on numbers synchronized from On-Premises Active Directory, precisely because it was the fastest path to roll out the service without a prior registration campaign.
These users show no symptoms in production:
- Their sign-in works normally.
- Their MFA, if they have one, is operational.
- Nothing signals a problem in the dashboards.
The problem manifests only during a password reset — that is, at the precise moment when SSPR was supposed to avoid a helpdesk ticket. The risk is a spike in tickets spread over several weeks, user by user, with accounts already locked by the time it's noticed.
Silent change
Nothing breaks at sign-in on September 7. No dashboard alert. The rupture occurs at the first failed reset, for each affected user individually.
Five blind spots that the official announcement does not highlight
Administrator registration is a legitimate mass lever
Registration does not pass only through My Security Info. An administrator can add authentication methods — phone number included — directly from the Entra admin center (user card > Authentication methods) or via the Microsoft Graph authentication methods API. A method added through this channel is a fully registered method.
This lever is particularly useful for populations without smartphones, accounts with low digital autonomy, or industrial sites. However, be careful: an incorrect number in profile attributes would become an incorrect registered method. This path is only valid for data whose reliability is proven.
SSPR compatibility rests on three conditions, not one
A user who has registered a method is not automatically "SSPR Capable". The three cumulative conditions are:
- Have at least one registered method.
- That method is among those authorized by the SSPR policy.
- The number of registered methods reaches the threshold required by the policy (1 or 2 methods depending on configuration).
Classic case: users equipped with Microsoft Authenticator who show up as "Not Capable" because the method is not enabled on the SSPR side, or because the policy requires two methods and they have only registered one.
The portal gives the answer without a script: Entra ID > Authentication methods > User registration details, filter SSPR Capable: Not Capable. This is the nominative list of accounts that will fail after September 7.
The campaign executes under your existing Conditional Access policies
Microsoft's campaign directs users toward the security information registration flow. This flow is subject to Conditional Access policies targeting the Register security information action. If your registration policy requires a compliant device or trusted network, a non-compliant remote user prompted by the campaign can get blocked: invited to register a method, but unable to do so.
Test the complete journey from an off-network workstation before any user communication.
Group scoping remains ambiguous
Microsoft has not confirmed, in the official Q&A, that the campaign is restricted to the SSPR target group when scoped. The prudent working hypothesis: users outside the SSPR group may receive the invitation. Prepare your communication for the entire tenant, not just the stated SSPR scope — a user who receives an unexpected invitation without context may report it as a phishing attempt.
Privileged accounts and break-glass accounts are explicitly in scope
Microsoft's bulletin targets "administrators and end users". The SSPR policy for administration accounts is separate from that of standard users, active by default, with a requirement for two methods. Any admin or break-glass account that relied on an alternate email placed in the profile loses that safety net on September 7. These accounts should be prioritized, preferably with phishing-resistant methods (Passkeys, FIDO2, Certificate-Based Authentication).
Summary of dates and scope
| Item | Status | Action required |
|---|---|---|
| Microsoft registration campaign | Active since July 6, 2026 | Inform helpdesk and users: legitimate invitation, not phishing |
| SSPR enforcement – registered methods only | September 7, 2026 | Target zero exposure before August 24, 2026 |
| Supported SSPR methods | Unchanged | Verify alignment between SSPR policy and actually registered methods |
| Affected population | All tenants with SSPR enabled, admins included | Treat privileged and break-glass accounts first |
| CA at enrollment + Custom Controls removal | Active since July 6 – deadline September 30, 2026 | Group the three components in the same decision folder |
Express Lab: measure your exposure in read-only mode
The two scripts below make no modifications. They require the AuditLog.Read.All scope on Microsoft Graph.
Quantify global exposure
1# Read-only: AuditLog.Read.All scope, no modifications2Connect-MgGraph -Scopes "AuditLog.Read.All"3 4Get-MgReportAuthenticationMethodUserRegistrationDetail -All |5 Group-Object IsSsprCapable |6 Select-Object Name, CountThis first script returns the distribution of accounts by their IsSsprCapable status. The False figure represents your raw exposure.
Get the nominative list of at-risk accounts
1# Accounts that will fail SSPR after September 7, 20262Get-MgReportAuthenticationMethodUserRegistrationDetail -All |3 Where-Object { -not $_.IsSsprCapable } |4 Select-Object UserPrincipalName, IsAdmin, @{n='Methods'; e={ $_.MethodsRegistered -join ', ' }}The Methods column indicates what each user has already registered, which directly guides remediation: missing authorized method, method not recognized by SSPR policy, or insufficient number.
Export and coverage tracking
Add | Export-Csv -Path .\sspr-exposure.csv -NoTypeInformation -Encoding UTF8 at the end of the pipeline to have a file usable in a dashboard. Re-run the script each week to measure coverage progress.
Remediation plan before September 7
Measure exposure today
Run the two Express Lab scripts. Export the results and communicate the exposure figure to your management. Set the objective: zero non-compliant accounts in the SSPR population before August 24, 2026, with two weeks of margin before enforcement.
Treat privileged and break-glass accounts as priority
Identify all admin and break-glass accounts in the export result (IsAdmin = True). Register strong methods — Passkeys, FIDO2, or Certificate-Based Authentication — test them, and document the unlock procedure via Temporary Access Pass (TAP) for emergency scenarios.
Deploy the three remediation levers in parallel
Three populations, three paths:
- Self-registration: short internal communication that legitimizes the Microsoft campaign invitation and directs toward My Security Info. This is the mass channel.
- Admin registration: for populations without smartphones or with low digital autonomy, transform validated repository numbers into registered methods via the Entra user card or the Microsoft Graph API, in controlled batches.
- Temporary Access Pass: for blocked cases (lost phone, onboarding), a TAP allows bootstrapping the registration of a strong method without relying on a password.
Validate configuration before pushing users
Three configuration checks:
- Test the end-to-end registration journey from a remote workstation to verify that your Conditional Access policies targeting Register security information do not create a deadlock.
- Verify that the methods authorized in the SSPR policy match the methods your users actually register, including required method threshold.
- Take advantage of the registration wave to guide toward phishing-resistant methods rather than default to SMS.
Prepare the aftermath: helpdesk and monitoring
Before September 8, brief the helpdesk on the scenario "reset failed, method not registered" and its unlock procedure via TAP. Enable monitoring of SSPR failures in Entra ID audit logs in the weeks following enforcement. This component is part of the same June bulletin as Conditional Access at enrollment and Custom Controls removal (deadline September 30, 2026): group all three in a single decision folder.
Official reference
The Microsoft Q&A dedicated to this change is available on Microsoft Learn. The Entra security bulletin from June 2026 documents all associated hardening measures.
