Microsoft is tightening how self-service password reset (SSPR) verifies identity in Microsoft Entra ID. Starting September 7, 2026, SSPR will accept only authentication methods that a user or administrator has explicitly registered.
A phone number or email address that appears on a user’s directory profile will no longer be enough if it was never registered as an authentication method. That distinction is easy to miss, and it can leave a user looking fully documented in the directory but unable to complete account recovery when a password problem occurs.
Microsoft began an automatic registration campaign for affected users on July 6. That prompt helps, but it does not replace an administrator’s readiness check. Users can miss prompts, Conditional Access can shape the registration experience, and the recovery policy may require more methods than a user has completed.
The dates that matter
| Date | Microsoft change | Business action |
|---|---|---|
| Starting Jul 6, 2026 | Microsoft begins prompting affected users and administrators to register authentication methods. | Communicate why the prompt is legitimate, monitor completion, and provide a clear help path. |
| Aug 2026 | The readiness window remains open before enforcement. | Audit SSPR registration, remediate gaps, and test recovery for representative user groups. |
| Starting Sep 7, 2026 | SSPR accepts only explicitly registered authentication methods. | Expect recovery failures for users who still depend only on directory-sourced phone or email properties. |
Microsoft says this change covers all users, including administrators, across Public cloud, GCC, GCC High, and DoD environments.
What actually changes
Many organizations have contact information in Microsoft Entra ID because it was synchronized from HR, created in on-premises Active Directory, imported during a migration, or entered by an administrator. Historically, some of that directory-sourced information could be used during password reset even when the user had not formally registered it for authentication.
After enforcement, the recovery method needs an intentional registration record. That creates a stronger connection between the person, the method, and the recovery event. It also removes a risky assumption: profile data is not automatically verified authentication data.
The change does not mean SSPR is being retired. It means organizations need to verify that enabled users have enough registered methods to satisfy the current SSPR policy.
Use the registration report—not the contact profile
For appropriately licensed tenants, the Microsoft Entra admin center provides an Authentication Methods Activity report under Entra ID > Authentication methods > Activity. The Registration details view includes the fields needed for a meaningful readiness review:
- SSPR Registered: whether the user has registered authentication information
- SSPR Enabled: whether the user is in scope for the tenant’s SSPR policy
- SSPR Capable: whether the user has enough allowed methods to reset
- Methods registered: the authentication methods associated with the user
- MFA and passwordless capability: useful context, but not a substitute for the SSPR-specific status
Microsoft notes that report data is not real time and can take up to 36 hours to reflect most users. Build that delay into validation instead of treating a newly completed registration as a reporting failure.
Read the three SSPR statuses together
| Observed status | What it means | Priority |
|---|---|---|
| Enabled, registered, and capable | The user is in scope and currently has enough approved methods. | Test a sample and monitor. |
| Enabled and registered, but not capable | Information exists, but it does not satisfy the policy’s method or quantity requirements. | High—remediate before enforcement. |
| Enabled, but not registered | The user is expected to use SSPR but has not completed registration. | High—target registration and support. |
| Not enabled | The user is outside the current SSPR scope. | Confirm that the exclusion is intentional. |
A user can be MFA-capable and still not be SSPR-capable. The methods allowed for sign-in, multifactor authentication, and password reset overlap, but the policy and registration conditions are not identical.
A practical readiness plan before September 7
1. Export a clean baseline
Capture Registration details for the users in scope for SSPR. Segment the results by enabled, registered, and capable status. Retain the baseline so the team can measure progress and identify users who repeatedly fail or avoid registration.
2. Validate the SSPR policy
Confirm which groups are enabled, which authentication methods are permitted, and how many methods are required to reset. A stricter policy may be appropriate, but the rollout needs to account for users who cannot practically use a specific method.
3. Prioritize high-impact accounts
Start with administrators, executives, remote staff, users who travel, and teams that work outside help-desk hours. Include hybrid users whose cloud password reset writes back to on-premises Active Directory, because the complete recovery path has more components to validate.
4. Make registration understandable
Tell users what Microsoft’s prompt looks like, why it is appearing, where to review Security Info, and how to get help. Keep the communication focused: the goal is to register a supported recovery method, not to send a password or verification code to IT.
5. Test the complete journey
Use pilot accounts that represent cloud-only, hybrid, administrative, remote, and restricted-access scenarios. Test registration, the forgotten-password flow, account unlock where enabled, password writeback where applicable, and the user’s next sign-in.
6. Watch Conditional Access during registration
Conditional Access policies for the Register security information user action can affect where and how registration succeeds. Review report-only results and test from the networks and devices your users actually use. A campaign cannot fix a registration path that policy unintentionally blocks.
7. Prepare the help desk for September
Create a short triage guide that distinguishes an unregistered method, an insufficient method set, a blocked registration attempt, a writeback problem, and an ordinary password-policy failure. Monitor Authentication Methods Activity and SSPR audit events after enforcement begins.
Use the deadline to improve recovery security
This is more than a compliance exercise. Password reset is a privileged identity event: if recovery methods are stale, shared, weakly governed, or misunderstood, the help desk and the user can both become targets for social engineering.
As registration gaps are remediated, use the opportunity to:
- Remove stale phone numbers and email addresses from authentication records
- Prefer phishing-resistant methods where the user experience supports them
- Maintain protected emergency-access accounts outside ordinary recovery dependencies
- Require stronger verification for administrative support procedures
- Document ownership for SSPR policy, authentication methods, communications, and monitoring
Frequently Asked Questions
What happens on September 7, 2026? Microsoft Entra SSPR begins accepting only authentication methods that were explicitly registered by a user or administrator.
Is a phone number in the user profile enough? Not if it exists only as a directory property and was never registered as an authentication method.
Does Microsoft prompt affected users automatically? Microsoft says an automatic registration campaign began July 6, 2026. Administrators should still audit completion and readiness rather than assume every prompt succeeded.
Does MFA-capable mean SSPR-capable? No. Review the SSPR-specific Registered, Enabled, and Capable fields and compare the user’s methods with the SSPR policy.
What should we do first? Export the Authentication Methods Registration details, identify enabled users who are not capable, and schedule targeted registration and recovery testing before September 7.
Need a defensible SSPR readiness plan?
Accred Consulting can audit authentication-method registration, review Entra recovery policies, test cloud and hybrid reset paths, and turn the September deadline into a controlled identity-hardening project.
Book a Free Consultation