Microsoft has set a hard deadline of September 7, 2026 for organizations to stop using directory-sourced phone numbers and alternate email addresses for self-service password resets (SSPR) in Entra ID. After that date, users who rely on these unverified contact methods will be locked out of resetting their own passwords.

The Changes Take Effect in Two Phases

The deprecation arrives in two waves, according to Microsoft’s advisory. Starting January 2026, newly created tenants will no longer be able to configure SSPR with phone-based or email-based methods that rely on directory attributes (the phone numbers and alternate email addresses stored directly in Active Directory or Entra ID). Existing tenants can continue using those methods until September 7, 2026, when the feature is removed globally. Admins who try to enable these methods after the cutoff will see the options greyed out, and users attempting a password reset through those channels will receive an error.

Microsoft is not removing the ability to reset a password via phone or email altogether—just the dependence on directory-sourced contact data. Verified methods, such as the authentication phone number or alternate email address that a user has explicitly confirmed, remain supported. The distinction matters: a phone number imported from on-premises Active Directory and never confirmed by the user will no longer work; a number the user entered and verified through a one-time passcode will continue to function.

What This Means for You

For end users

If your organization hasn’t migrated yet, you may have been using your office phone number or a secondary email that was copied from the company directory to reset your password. After September 7, 2026, those options will disappear. You’ll need to set up a verified authentication method—Microsoft Authenticator, a hardware token, a security key, or a confirmed phone number/email—before the deadline. Without at least one method registered, you won’t be able to recover a forgotten password on your own and will have to contact your IT helpdesk.

For IT administrators

This is not a passive change. You must audit your tenant’s SSPR configuration now. Check:
- Which authentication methods are currently offered to users?
- How many users have only a directory-sourced phone or email registered?
- Are there Conditional Access policies or legacy applications that depend on these methods?

Microsoft provides reports in the Entra admin center under Protection > Authentication methods > Usage & insights that show method adoption. Use the Get-MgUserAuthenticationPhoneMethod and Get-MgUserAuthenticationEmailMethod Graph API calls to pull detailed inventories. Once you identify affected users, you’ll need to drive registration campaigns to ensure they add approved alternatives.

Hybrid environments with Azure AD Connect face an extra wrinkle. Many organizations have been syncing phone and email attributes from on-premises AD for years, assuming SSPR would use them. That pipeline will no longer serve password resets. You can continue syncing those attributes—they remain useful for other purposes—but you must decouple SSPR from directory data. Consider enabling the converged registration experience (ssprComboRegistrationEnabled) to let users manage all authentication methods from one portal, which raises enrollment rates significantly.

For developers and ISVs

Any custom application or identity workflow that triggers SSPR and expects directory-based phone or email to work will break after the cutoff. Audit your code for calls to the SSPR API and ensure the user-facing prompts guide users toward verified methods. If your application hard-codes assumptions about available reset channels, update the logic to handle cases where only modern methods are registered.

How We Got Here

The retirement of directory-sourced contact methods is part of Microsoft’s multi-year push to eliminate weak authentication factors. In 2021, Microsoft began blocking legacy authentication protocols in Exchange Online, and it has steadily expanded multifactor authentication requirements for admin portals and privileged roles. The SSPR change aligns with the broader Zero Trust principle of “never trust, always verify”: a phone number or email that an admin typed into a directory field has no assurance of being under the user’s control.

Microsoft first signaled this direction in a message center post (MC261538) in mid-2022, advising tenants to move users to “combined registration” and verified methods. At that point, no date was set. In September 2023, the Entra product group published a timeline: directory-based methods would stop working for new tenants in January 2025, and for all tenants by late 2025. After feedback from large enterprises struggling with migration, Microsoft pushed the dates back—to January 2026 for new tenants and September 2026 for existing ones. The final date is now codified in the Entra admin center under Password reset > Authentication methods, where a banner warns of the upcoming change.

What to Do Now

  1. Assess your current state
    - Run the authentication methods usage report to see how many users have only directory-sourced methods registered.
    - Check the StrongAuthenticationRequirement property in the SSPR policy. If it’s set to NotRequired, you may have users without any verified method—an immediate risk.

  2. Plan your replacement methods
    - The strongest and most phishing-resistant options are Windows Hello for Business, FIDO2 security keys, and certificate-based authentication. Microsoft Authenticator with number matching is the most practical step up for most organizations.
    - If you must continue using phone or email for password resets, ensure you migrate to the verified variants. That means instructing users to go to aka.ms/mysecurityinfo and manually enter a phone number or alternate email that they can receive codes on, then verify it.

  3. Drive user registration
    - Turn on the combined registration experience if you haven’t already. It presents SSPR and MFA setup in one flow, reducing confusion.
    - Use Conditional Access policies to require users to register security info. The “require registration” control can be scoped to specific apps or all cloud apps.
    - Schedule a multi-phase communication campaign: awareness emails starting 12 months out, targeted reminders at 6 months, and a “last chance” push 90 days before the deadline.

  4. Clean up legacy dependencies
    - Review your Azure AD Connect sync rules. If you’re syncing telephoneNumber or mail specifically to enable SSPR, consider removing those flows after users have transitioned, to avoid confusion.
    - Document any internal helpdesk scripts that reset passwords and call SSPR—they may need to be updated to accommodate the new method mix.

  5. Test the cutoff in a sandbox
    - If you have a development tenant, remove all verified methods from a test user and try a password reset after setting the policy to directory-only methods. You’ll see the failure message users will encounter. This helps frame your helpdesk training.

Outlook

Microsoft has not announced plans to retire verified phone and email methods entirely, but the long-term trajectory points toward passwordless and phishing-resistant credentials. The SSPR deprecation is a milestone on that road rather than an endpoint. Organizations that treat this as an opportunity to modernize their authentication stack—adding passkeys, deploying certificate-based authentication, and integrating with conditional access—will exit the transition more secure and with fewer helpdesk calls. Those that delay until the last minute risk a surge of locked-out users on September 8, 2026.