Microsoft has informed Entra ID administrators that self-service password reset (SSPR) will undergo a fundamental shift on September 7, 2026. After that date, SSPR will only accept authentication methods that users have explicitly registered. Methods automatically populated by the system—such as phone numbers or email addresses synced from HR systems—will no longer work for password resets unless users actively confirm them during a new registration campaign.

The change, communicated through the Microsoft 365 admin center and Entra admin center message center, aims to bolster security by ensuring that recovery methods are intentionally provided. A two-month registration campaign will begin on July 6, 2026, giving organizations time to prompt users to verify and register their authentication contacts.

The Current State of SSPR

Currently, Entra ID (formerly Azure AD) SSPR can be configured to use authentication methods that are automatically populated from user profiles. For example, an administrator can set up SSPR to leverage the phone number stored in a user's Active Directory mobile attribute or the email address in the mail attribute. If a user has not explicitly registered a method via the security info portal (https://aka.ms/mysecurityinfo), the system falls back to these admin-provided values.

This design simplified deployment, especially in hybrid environments where user contact data was already managed on-premises. It reduced helpdesk calls by enabling password resets without requiring users to first register a phone or email. However, this convenience came with a security trade-off. Stale or inaccurate attributes—such as a phone number of a former employee stored in Active Directory—could inadvertently grant a malicious actor an easy reset vector. Additionally, users might never verify whether the auto-populated method was correct, leading to lockouts or support tickets down the line.

What Changes on September 7, 2026

Starting September 7, 2026, SSPR will ignore any authentication method that a user has not explicitly registered. The only methods accepted will be those shown as “Registered” in the user’s security info within the My Sign-Ins portal. This applies to all SSPR scenarios: password reset from the login screen, from the Microsoft 365 portal, and through the SSPR reset portal.

Microsoft will not change the allowed authentication methods configured by admins in the SSPR policy. The existing policy settings—such as enabling security questions, mobile app notifications, or phone call verification—remain as before. However, the system will now check, for each user attempting a reset, that at least one of the allowed methods has been explicitly registered by that user. If no explicit registration exists, the reset will fail, and the user will be redirected to an administrator for manual intervention.

The registration campaign launching July 6, 2026, is designed to close the gap. Over these two months, users will be nudged to register their preferred methods. The campaign uses a grace period mechanism: when a user logs in, they may be prompted to register security info if their current methods are solely auto-populated. Administrators can control the frequency and urgency of these prompts through a campaign configuration in the Entra admin center.

The Registration Campaign: What Admins Need to Know

The registration campaign feature, first introduced for Azure MFA and SSPR converged registration, will now be extended to cover pre-populated method cleanup. Key details:

  • Campaign window: July 6, 2026 to September 6, 2026. Users who do not register explicit methods during this period will lose self-service reset capability on the cutover date.
  • User experience: Depending on admin configuration, users will see a prompt after sign-in: “Your organization needs you to register or verify your security information for account recovery.” They can skip a limited number of times before being forced to register.
  • Admin controls: In the Entra admin center, under Security > Authentication methods > Registration campaign, admins can set the number of days allowed to snooze, and choose whether the campaign is targeted at all users or specific groups. A Microsoft Graph API (authenticationMethodsPolicy resource) allows automated management of the campaign state.
  • Reporting: The Registration and usage insights dashboard in Entra will show how many users have auto-populated methods versus explicitly registered ones. A new tile will track campaign progress.

Microsoft recommends that admins audit their current SSPR configuration immediately. Run a report on users who rely on auto-populated methods. The Get-MgUserAuthenticationMethod PowerShell cmdlet or Microsoft Graph call GET /users/{id}/authentication/methods can list a user’s registered methods—absent methods indicate auto-populated reliance.

Why Microsoft Is Making This Change

This shift aligns with a broader identity security strategy centered on phishing-resistant, user-verified contact information. Auto-populated methods create a vulnerability: if an attacker gains write access to an on-premises directory, they could change a target user’s mobile number and then trigger an SSPR flow, receiving the reset code. By requiring explicit registration, the attack surface shrinks because a user must present a second factor (like an existing MFA method) to register or change recovery info.

Moreover, as Microsoft expands passwordless authentication with passkeys and Windows Hello for Business, the reliance on correct contact methods for recovery becomes critical. An inaccurate recovery phone number can break the fallback path, increasing helpdesk costs. Explicit registration ensures that the recovery path is tested and available.

The change also supports compliance requirements. Standards like NIST SP 800-63B discourage out-of-band verification methods that are not under the user’s control. Requiring explicit registration is a step toward such compliance.

Impact on Organizations

Organizations that have heavily relied on auto-populated SSPR methods will face the most disruption. Common scenarios include:

  • Hybrid environments with synchronized attributes: If Active Directory telephoneNumber or mobile feeds into Entra ID, many users may never have opened the My Sign-Ins portal.
  • First-year students or new hires: Often bulk-onboarded with HR-sourced contact data, these users may not know that SSPR exists or that they must register.
  • High turnover industries: Where phone numbers and email addresses change frequently, auto-populated data may be outdated, causing both security and usability issues.

The immediate consequence for users who fail to register by September 7 is a broken self-service flow. Password resets will require administrator intervention, increasing helpdesk call volume. For organizations with thousands of users, this could overwhelm support teams during the first week after cutover.

Preparing for the Transition: A Step-by-Step Plan

Administrators should start preparing now. Here is a recommended four-phase approach:

Phase 1: Discovery (Now – Q1 2026)

  • Use Microsoft Graph to export all users and their currently registered authentication methods. Look for users whose methods array is empty or contains only methods that were auto-populated (like phone with attribute source).
  • Cross-reference with SSPR policy to identify which users would be immediately blocked post-cutover.
  • Determine the email, SMS, and in-app notification channels available to reach affected users.

Phase 2: Planning (Q2 2026)

  • Decide on the registration campaign parameters. For example, allow users to snooze for 3 days, with a maximum of 2 snoozes before a mandatory prompt.
  • Prepare communication materials: emails, Teams posts, intranet banners. Explain what SSPR is, why explicit registration is required, and how to do it (via https://aka.ms/mysecurityinfo).
  • Consider piloting the campaign with a small group using a custom Microsoft Graph policy to refine the user experience.

Phase 3: Execution (July 6 – September 6, 2026)

  • Enable the registration campaign in the Entra admin center.
  • Monitor compliance via the Registration insights dashboard.
  • Run weekly reports to track progress and send reminders to laggard users.
  • For users who remain unregistered close to the deadline, consider bulk enrollment using Temporary Access Passes or direct manager follow-up.

Phase 4: Post-Cutover Validation (September 7, 2026 onward)

  • Review SSPR success rates and helpdesk ticket volume.
  • For users who fall through the cracks, provide an assisted recovery path, such as a self-service tool that issues a Temporary Access Pass after identity verification by a manager.
  • Adjust the authentication methods policy to include only methods that are both secure and usable in your environment (e.g., Microsoft Authenticator, FIDO2 keys).

Technical Deep Dive: How Explicit Registration Differs

Under the hood, an explicitly registered method is one that the user has added through the My Sign-Ins portal or via an equivalent API call. Entra ID stores these methods as objects linked to the user object, with a specific source attribute. Auto-populated methods have a source of “Attribute” (or similar) and lack the user-initiated flag.

The SSPR engine currently queries the combination of both propagated attributes and registered methods. After the change, it will filter out any method with source not equal to “UserRegistration”. This is a server-side enforcement—no admin configuration toggle will revert to the old behavior.

For developers and automation specialists, the Microsoft Graph authenticationMethods endpoint will expose new properties to distinguish registration source. Beta endpoints may surface this before GA. Although the exact schema has not been publicly documented as of this writing, admins can expect an enhancement like "registrationSource": "attribute" versus "userRegistered".

Potential Pitfalls and How to Avoid Them

False sense of security: Some admins might assume that if SSPR is already using email or phone, users are registered. This is not true if the methods were auto-populated. Verify.

Scope of campaign: Ensure the registration campaign covers guest users and administrators. Administrators without registered recovery methods create a single point of failure. Use a break-glass account as a fallback.

Authentication strengths: The change interacts with Azure AD Conditional Access Authentication Strengths. If a strength requires, for example, a certain method for password reset, that method must be explicitly registered. Otherwise, the user cannot complete the reset even if another method is allowed.

On-premises writeback: If you use password writeback to Active Directory, the same explicit registration requirement applies. Failure to register will still result in an on-premises password reset failure.

The Bigger Picture: Convergence and Passwordless

This SSPR change is part of a multi-year effort to unify authentication under the “security info” umbrella. Since 2021, Microsoft has been converging SSPR and MFA registration. Initially, registration was separate, leading to confusion. The converged experience allows users to register once for both SSPR and MFA.

Explicit registration ties into that convergence. In the future, Microsoft may require all authentication methods to be user-registered, eliminating auto-population entirely. This would pair with passwordless sign-in where the primary credential (like a passkey) is already user-managed.

By forcing explicit registration now, Microsoft is preparing the ecosystem for a future where self-service recovery is more secure and reliable. It also pushes organizations to educate users about identity security—a long-standing weak point in many phishing attacks.

Conclusion: Act Now to Avoid September Surprises

September 7, 2026, might seem distant, but the preparation work is significant. Organizations with thousands of users should treat this as a major project with dedicated resources. The July 6 registration campaign gives a two-month window, but passive communication alone rarely achieves full compliance. Proactive nudging, manager involvement, and analytical monitoring will be essential.

Expect Microsoft to reiterate this deadline in future technical blogs, Ignite sessions, and message center posts. However, the best defense against a spike in helpdesk calls is early action. Start auditing your SSPR methods today, design your communication plan, and test the registration campaign in a lab tenant.

By aligning with Microsoft’s explicit registration mandate, you not only comply with the upcoming change but also raise the bar for identity security across your organization, reducing both external threats and operational friction.