Microsoft is making a change to Entra ID SSPR that is operationally correct: starting September 7, 2026, only explicitly registered authentication methods will satisfy SSPR verification. Phone numbers imported from HR, directory contact fields that were never enrolled as recovery methods, none of those count after the deadline. That is the right call. For organizations with coverage gaps, the first signal will be a help desk surge on or after September 7. But the change does not fix the governance model. The fundamental condition that Storm-2949 exploited, that credential reset authority lives with the user, remains intact after the deadline. Requiring explicit registration makes the reset harder to initiate without user involvement. It does not remove the user from the decision seat. Here is what the September 7 change does, what it does not do, and what that means for your credential governance posture.

Key Takeaway

The September 7 Entra ID SSPR enforcement change is operationally correct and will reduce one category of exposure. But it does not change the governance model that made Storm-2949 possible, because the user remains the custodian of the credential.

Quick Summary

• Starting September 7, 2026, Entra ID SSPR will only accept explicitly registered authentication methods. Directory contact data that was never deliberately enrolled will no longer satisfy SSPR verification.
• The registration campaign begins August 6. Users without compliant methods will see prompts. After September 7, they cannot self-reset.
• Organizations relying on HR-synced contact data, business phone numbers, or alternate emails never explicitly registered are directly affected.
• The change is operationally correct. It is not a fix for the governance model. The user remains the custodian of the credential after the deadline.
• Microsoft says 86% of SSPR traffic already uses registered methods. The remaining population is exactly where the help desk surge originates.
• Enterprise credential lifecycle management removes the dependency on individual user registration. It shifts reset governance to policy. The deadline becomes a compliance checkpoint, not a crisis.
  

Entra ID SSPR Is Changing September 7. Here Is What It Still Does Not Fix. 

Microsoft is making a change to Entra ID SSPR that is operationally correct: starting September 7, 2026, only explicitly registered authentication methods will satisfy SSPR verification. 

What Is an Explicitly Registered Authentication Method?

A registered authentication method is one a user has deliberately enrolled through the Microsoft Entra combined security registration experience. A phone number that HR imported into your directory is not registered in this sense. It exists as directory contact data. Until the user actively enrolls it as a recovery method, Entra ID will not accept it for SSPR verification after September 7.

• Valid after September 7: Microsoft Authenticator app (registered), FIDO2 security key (registered), phone number if the user explicitly enrolled it as a method, email if explicitly enrolled.
• No longer valid: mobile phone stored only as a directory attribute, business phone from HR sync, alternate email in the user object that was never registered for SSPR.
• Why Microsoft is making this change: directory contact data is not tied to a device or a deliberate enrollment decision. It provides weaker identity assurance than an explicitly registered method. Storm-2949 demonstrated what happens when weaker assurance sits on the account takeover path. (See Blog 1.)
• What this change does not address: even with all methods explicitly registered, the user remains the approver in the reset flow. Social engineering that targets that approval, as Storm-2949 did, is not closed by registration enforcement alone.

This change closes the unregistered contact data exposure. It does not close the governance model gap that Storm-2949 exploited in May 2026. We covered the full attack chain and the governance argument in our previous post.

What Changes on September 7

Today, Entra ID SSPR can verify identity using directory attribute contact data — even data that was never enrolled as a recovery method. After September 7, that path closes. Only methods the user deliberately enrolled will satisfy SSPR verification. The change is correct. For organizations with coverage gaps, it will feel abrupt.

• Today: SSPR can use mobile phone, business phone, or alternate email from directory attributes without explicit user enrollment.
• After September 7: only methods enrolled through the combined security registration experience count. Directory attributes never enrolled are ignored.
• Microsoft gives two dates: August 6, when the registration campaign begins prompting affected users to enroll; and September 7, when enforcement goes live. Unregistered users cannot self-reset after that date.
• Affected organizations: tenants where users have never completed combined registration; where HR sync populates contact fields relied on for SSPR; or where privileged accounts have no registered fallback method.
• What does not change: the governance model. The user is still the approver. Requiring a more robust enrollment process makes the reset harder to trigger without user involvement. It does not remove the user from the reset decision.

Reference: Microsoft MC1325414, Entra ID SSPR authentication method change, enforcement September 7, 2026.

What the Change Still Does Not Fix

The September 7 change removes one exposure: unregistered directory contact data as a valid SSPR factor. That is worth doing. It does not remove the condition that made Storm-2949 possible. After September 7, an attacker who calls a user at the moment an SSPR prompt appears can still succeed if the user approves it. The user is still the custodian. The custodian is still reachable.

• Explicit registration makes the reset flow more deliberate. It does not make the approver less susceptible to social engineering at the moment the prompt fires.
• Privileged accounts with explicitly registered methods are still exposed to the same technique Storm-2949 used. The attacker initiates SSPR, calls the target, and waits for approval. Registration enforcement changes what methods are valid. It does not change who approves them.
• Service accounts and non-human identities remain outside the SSPR governance model entirely. They have no registered methods and no user custodian. Storm-2949's post-compromise enumeration targeted these accounts specifically.
• IT staff handling assisted resets in Entra ID natively must hold the Helpdesk Administrator role. Microsoft classifies it as a privileged role with a documented lateral movement risk path. The September 7 change increases the volume of users who cannot self-reset, driving more assisted resets through staff who carry that role. PIM can gate activation to a time window, but the role still holds directory-level credential manipulation capability for the duration of every support session. Registration enforcement does not change this condition.
• Scale exposes weak design. A tenant that managed SSPR informally at 500 users will not manage it the same way at 50,000. Coverage gaps scale into help desk crises. Governance gaps, including the privileged role exposure carried by IT staff in a native Entra ID model, scale into breach impact.

Your Pre-September Action List - What To Do By August 6

September 7 is a deadline, not a destination. Completing the registration campaign before August 6 puts you in compliance with Microsoft's enforcement change. It does not change the governance model that made Storm-2949 possible. Organizations that use this deadline to reassess how credentials are managed will be in a materially different position by year end. The ones that treat it as a registration cleanup sprint will be in the same position, better registered.

• Step 1: Audit your coverage now. Go to Microsoft Entra admin center, Authentication methods, User registration details. Identify every user whose SSPR access depends on unregistered directory contact attributes. This is the baseline. You cannot run a registration campaign or assess your real exposure without it.
• Step 2: Prioritize privileged accounts. IT staff, senior leadership, and service account owners first. These accounts have the highest blast radius if locked out and are also the targets Storm-2949 specifically chose.
• Step 3: Start the registration campaign before August 6. Microsoft’s August 6 prompt is the minimum. Begin your own internal communication before that date for users with no registered method. Four weeks is not much time if your tenant has gaps at scale.
• Step 4: Ask the harder question. What percentage of your credential resets should require a user to initiate anything? In an enterprise-managed credential model, the answer approaches zero. Bravura Pass generates, rotates, and delivers credentials through policy. Users retrieve current credentials from Bravura Safe (our secure credential delivery store) and autofill them. They do not initiate resets, because they do not hold passwords to forget or lose. SSPR becomes the exception, not the norm.
• Step 5: Govern the exceptions. When assisted resets do occur, delegated administration in Bravura Pass allows IT support staff to handle them without holding any Entra ID privileged role. The exception is governed, auditable, and scoped by policy. The help desk surge September 7 may generate does not require expanding privileged role activation to absorb it.

SSPR Readiness by Organization Type

Every organization type carries the same model gap. The September 7 change does not close it.

How Bravura Pass Addresses the Gap the Deadline Exposes

The September 7 change is Microsoft correcting a dependency on user action that should never have been a governance control. Bravura Pass takes that principle further: policy-based credential rotation means users are never reliant on remembering a password in the first place. When they need to authenticate, they retrieve the current credential from Bravura Safe and autofill it. There is nothing to forget, nothing to reset, and no SSPR flow to social-engineer. The deadline becomes a compliance checkpoint on a model the organization is already moving away from, not a crisis to manage.

• In an enterprise-managed credential model, the help desk surge the September 7 deadline may generate does not arrive. Users with enterprise-managed credentials never call the help desk when they cannot log in. They fetch the current credential from Bravura Safe. The forgotten password as a support category is eliminated, not routed differently.
• The Entra ID Helpdesk Administrator role becomes a structural observation rather than an ongoing risk. In a native model, IT staff handling SSPR support must hold a Microsoft-classified privileged role with documented lateral movement risk. Post-September 7 lockouts drive more users to assisted recovery, so that role gets used more. In an enterprise-managed credential model, that volume does not materialize and the role does not need to be held. When a genuine edge case does require help desk assistance, delegated administration in Bravura Pass handles it without any Entra ID role assignment. The exception is governed. The norm is automated.
• We integrate with the MFA platform you already run. The governance layer does not require replacing existing authentication infrastructure.

Enterprise-managed credential delivery — policy-based rotation, vault delivery, and autofill — requires both Bravura Pass and Bravura Safe working together.

A Note on Identity Platform Coverage - If You Think You're Already Covered

"Our identity platform already handles this." Entra ID is the identity platform. This change is Microsoft modifying how Entra ID itself handles SSPR verification. Having Entra ID does not mean your users have registered compliant methods, and it does not mean the governance model has changed. The gap is in your SSPR coverage data and your credential governance posture, not in the platform you are running.

When This Does Not Apply

This post addresses organizations using Microsoft Entra ID with SSPR enabled. If your organization does not use Entra ID SSPR, the September 7, 2026 enforcement change does not affect your environment directly. The underlying governance principle, that user-level credential reset authority carries social engineering risk regardless of registration enforcement, applies to any SSPR implementation on any platform.

Need To Learn More about Entra ID?

These pieces cover the governance model, the Entra ID gap, and how enterprise credential management changes the equation.