You know that moment when someone can’t get into email, Teams, or the CRM because their password has expired, and they’re stuck? Self-service password reset (SSPR) is meant to stop that from turning into a helpdesk fire drill.

Microsoft is changing how SSPR verifies identity in Microsoft Entra ID, and if your business relies on phone numbers or emails that are simply synced from Active Directory or HR systems, you may find they stop working for password resets.

What’s changing on November 9, 2026

Starting November 9, 2026, Microsoft Entra ID SSPR will require explicitly registered authentication methods for the verification step. In plain English: SSPR will stop accepting “directory-sourced” contact info (like a mobile number or email address that exists on the user object) unless the user has actually registered it as a verification method.

This is one of those changes that sounds subtle, but it affects real life:

  • If an employee has a mobile number filled in on their Entra profile (or synced from on-prem AD) but they never registered it in Security info, SSPR may not let them use it.
  • The same goes for certain email attributes that were handy for password reset in hybrid setups.

Microsoft is also planning an SSPR registration campaign prompt ahead of enforcement, beginning October 5, 2026, to nudge affected users to register the right methods.

Why directory-sourced phone numbers and emails may stop working

Most growing businesses did the sensible thing: populate contact fields centrally so users don’t have to. The problem is those fields were never designed to prove “the person resetting the password is the person who owns this phone or inbox”.

Microsoft’s updated approach is basically: if it’s going to be used to reset a password, it should be something the user has intentionally set up and can prove they control.

Here’s what tends to catch businesses off guard:

  • “But it’s in Active Directory.” SSPR has historically been able to use synced attributes like mobilePhone, businessPhone, and otherMails without the user doing anything. Microsoft is explicitly calling out that directory-sourced properties that were never registered will no longer work for SSPR verification.
  • “We already have their phone number on file.” Having it “on file” is not the same as having it registered as an authentication method in Entra Security info.
  • “Our onboarding script sets it automatically.” If your process fills in attributes but does not drive the user through Security info registration, the user may still be unprepared for SSPR.

The practical takeaway: you want employees to have at least one, preferably two, usable methods registered in Entra, not just stored somewhere in the directory.

What “registered” looks like for an employee

For most users, “registered” means they’ve gone to the Security info experience (the same place used for MFA and password reset) and added methods there.

Common methods you’ll see in the combined registration experience include:

  • Microsoft Authenticator. Usually the smoothest option for day-to-day verification.
  • Phone (SMS or call). Still common in many environments, but you should be deliberate about when you allow it.
  • Email. Often used as a secondary method for SSPR.
  • Passkeys (FIDO2). A strong option, especially for phishing-resistant setups.

And one key detail that matters for planning: a user is considered “registered for SSPR” only when they’ve registered enough methods to meet your organisation’s SSPR policy (for example, if you require two methods, one method registered is not enough).

A quick readiness campaign you can run this month

You don’t need a six-month project plan. You need a clear target, a short window, and reporting.

1) Decide your “good enough” method set

Pick a simple standard that fits how your team works.

A common baseline looks like:

  • Microsoft Authenticator + one backup method. Authenticator plus email, or Authenticator plus phone, gives people a second way in if they lose a device.
  • Two methods required for SSPR (where appropriate). If you set the policy to require two methods, make sure your user comms say “register two” so people don’t stop after one.

2) Measure who is actually ready (not who you think is ready)

In Entra, you can report on registration coverage using the Authentication Methods Activity reporting, including whether users are SSPR capable and which methods they have registered.

What you’re looking for:

  • SSPR Capable. Users who both have enough methods registered and are enabled for SSPR.
  • Methods registered. Whether they have Authenticator, email, phone, passkey, and so on.

This is the step that usually reveals the gap between “we populated the phone field” and “the user can reset their password at 7am on a Monday without calling anyone”.

3) Run a short, friendly registration push

Aim for a two to three week campaign. Keep it simple and repetitive.

  • Clear instruction. Tell staff exactly where to go (Security info) and what to add (for example, Authenticator plus one backup).
  • A calendar deadline. Use the real enforcement date in your message: November 9, 2026.
  • A manager assist. Ask department leads to give people 10 minutes during a team meeting to complete it, especially for frontline staff who don’t live in email.

4) Use a registration campaign prompt (and make sure it won’t block people)

Microsoft Entra supports registration campaigns that nudge users during sign-in to set up an authentication method. Microsoft has also stated it will deploy an SSPR registration campaign prompt starting October 5, 2026.

A couple of practical tips before you flip any switches:

  • Conditional Access applies here. Policies governing security info registration can apply before a user is nudged to register. If your Conditional Access rules are strict (device compliance, trusted locations, specific authentication strengths), test with a pilot group so you don’t accidentally create a loop where users can’t register.
  • Pilot first. Start with IT and a small business group, then expand.

5) Plan for the “new hire” and “lost phone” cases

Even if you get everyone registered today, you still need a repeatable process for edge cases:

  • New hires. Make Security info registration part of day-one onboarding, not week three.
  • Device loss. Make sure your helpdesk has a documented way to get someone back in without lowering security for everyone else.

The simple goal

By the time you get to early November 2026, you want password resets to be boring again. No surprises, no “it used to work”, no last-minute scramble.

If you would like help reviewing your Entra SSPR settings, measuring registration coverage, and running a quick readiness campaign before November 9, 2026, the Flexnet Networks team can help you get it done.

Sources