Does this mean prepopulating authentication contact info from Active Directory is no longer supported?

No, and this is the distinction most coverage will blur. Prepopulation still works and Microsoft still documents the requirements for it — properly formatted data in the on-premises directory and the right synchronization configuration. What changes is what prepopulated data buys you. Before this date, a synced mobile phone number could satisfy SSPR verification on its own. After it, that number is a convenience that makes registration faster, not a substitute for registration. The attribute still arrives in the tenant; it just no longer counts as a registered method.

How do we find out which users are affected before the deadline?

The population you care about is users who are enabled for SSPR and have no explicitly registered method. That is a different set from users with no contact information at all, which is the report most tenants look at first and the reason this gets underestimated. Check registration state rather than attribute presence: the authentication methods registration data in Entra tells you who has registered what, and the gap between that population and your SSPR-enabled group is your exposure. Do it before the enforcement date, because the failure surfaces at the worst possible moment — a locked-out user who cannot reset.

Why does Microsoft's registration campaign start after the enforcement date?

We do not know, and we are not going to invent a reconciliation. Both dates appear on the same Microsoft page. Enforcement is stated as starting October 5, 2026. The registration campaign that prompts affected users to register methods, described on that page as happening ahead of enforcement, is stated as starting November 9, 2026 — five weeks later. Read literally, the prompt designed to prepare users arrives after the change it was preparing them for. Plan against the October date and treat the campaign as a backstop that may help users you have already missed, rather than as the mechanism that will fix this for you.

What happens to a user who is not registered when enforcement starts?

They lose the self-service path and fall back to whatever your help desk process is. That is the practical cost of this change and it is why it is worth acting on early: SSPR exists to keep password resets away from a queue, so an unregistered population converts directly into help desk volume at the moment they are already locked out and least patient. For a regulated organization there is a second cost — the identity-verification step your help desk performs on a password reset is a control that gets audited, and pushing volume onto it increases the number of times that control has to be performed correctly.

Blog · 7 min read · September 9, 2026

Entra SSPR: unregistered contact info stops Oct 5

From October 5, 2026, Entra self-service password reset accepts only explicitly registered authentication methods. Directory-sourced properties — mobilePhone, businessPhone, otherMails — that a user never registered stop working for SSPR verification. Microsoft's own page also announces a registration campaign starting November 9, 2026, which is five weeks after the enforcement it is meant to precede.

On October 5, 2026, Microsoft Entra self-service password reset stops accepting authentication contact information that the user never explicitly registered. If your tenant has been relying on phone numbers and alternate email addresses synced up from Active Directory to carry SSPR verification, those attributes stop counting on that date.

This is a small change with a disproportionate operational tail, and it is the kind that surfaces as a help desk problem rather than as an outage. Nothing breaks visibly on October 5. What happens is that a population of users you have never had to think about discovers, individually and at the worst possible moment, that the self-service reset no longer works for them.

The 60-second version: prepopulating contact info from your on-premises directory still works, but it no longer counts. From October 5 the user has to have registered the method themselves. The population at risk is not "users with no contact details" — it is users who are SSPR-enabled and have no explicitly registered method, which is a larger and less obvious set. Find it now, because the alternative is finding it one locked-out user at a time.

What Microsoft actually says

From learn.microsoft.com/en-us/entra/identity/authentication/howto-sspr-authenticationdata, a page last updated August 4, 2026:

"Starting Oct 5, 2026, SSPR will only accept explicitly registered authentication methods. Directory-sourced properties — such as mobilePhone, businessPhone, and otherMails — that were never registered will no longer work for SSPR verification."

Three attributes are named and they are the three that matter, because they are precisely the ones an organization is most likely to have populated in Active Directory for reasons that had nothing to do with authentication. A mobile number in AD is usually there because it was in the HR feed. That number has quietly been load-bearing for password resets, and after October 5 it is not.

The date that does not line up, and we are not going to explain it away

The same page carries a second date, in an Important callout, and it is worth quoting because the ordering is genuinely strange:

"Starting Nov 9, 2026, If your SSPR settings require users to register during sign-in, and enabled users do not have enough methods to complete SSPR, a registration campaign will prompt affected users to register methods ahead of enforcement."

Read those two statements together. Enforcement begins October 5. The registration campaign that exists to prompt users ahead of enforcement begins November 9 — five weeks after the thing it precedes.

We are not going to reconcile that for you, because any reconciliation would be a guess dressed as analysis. It may be a documentation error, a staged rollout where the two mechanisms genuinely land in that order, or a campaign aimed at a different population than the enforcement. What matters operationally is the planning consequence, and that is unambiguous: plan against October 5 and treat the campaign as a backstop, not as the mechanism. A tenant that waits for Microsoft to prompt its users will be prompting them after the enforcement has already started.

Finding the affected population, and why the obvious report is the wrong one

The instinct is to look for users with no authentication contact information. That report will understate the problem, sometimes badly, because it counts attribute presence rather than registration state. A user with a perfectly good synced mobile number appears healthy in that view and is exactly the user who breaks.

The population you actually want is the intersection of two sets:

Users enabled for SSPR — whatever group your SSPR policy is scoped to, which in many tenants is everyone.
Users with no explicitly registered method that satisfies the policy — not users with no attributes, users with nothing they registered themselves.

Entra's authentication methods registration data is where that lives. Pull registration state, not directory attributes, and compare it against the SSPR scope. The difference is your work.

The number that makes this urgent for a mid-market estate: the affected population skews toward exactly the users least equipped to self-recover — shop floor, field crews, clinical staff, anyone who was onboarded from an HR feed and has never opened the registration prompt because they have never needed to. They are also the users least likely to respond to an email campaign, which is the mechanism Microsoft is offering.

What to do, in the order worth doing it

Measure the gap. SSPR-enabled users with no registered method, from registration data rather than attribute data. Until you have that number, everything else is speculation.
Decide whether you are running your own campaign. Given the November 9 date, assume Microsoft's prompt arrives too late to help you and run registration through whatever channel actually reaches your workforce. For frontline staff that is usually not email.
Check what your help desk does today on a password reset. If SSPR coverage drops, that process absorbs the difference. In a regulated environment, confirm the identity-verification step is documented and performed consistently, because it is about to be performed more often.
Keep prepopulation in place. It still works, and it still makes registration faster for the user. Just stop treating it as coverage.

The wider pattern this belongs to

This is the third Entra change in a year with the same shape: a control that silently stops applying, with no error, to an estate that has not been touched. Passkeys became the default authentication method in September 2026 and auto-enrolled users who were on SMS or voice. Legacy risk policies in Entra ID Protection retire in October 2026, and a tenant that does nothing simply stops applying risk-based access control. Now SSPR stops honoring an attribute it used to honor.

In none of those cases does anything appear in a log as a failure. The estate continues to look exactly as it did. That is the reason to run a dated review against changes like this rather than waiting for a symptom — the symptom, when it comes, is a person who cannot log in and a ticket that starts with "this used to work."

Sources

Microsoft Learn, Prepopulate authentication contact information for SSPR — learn.microsoft.com/en-us/entra/identity/authentication/howto-sspr-authenticationdata, page updated_at 2026-08-04. Both dated statements above were read directly from this page.

Questions we get asked

What changes for Entra SSPR on October 5, 2026?: Self-service password reset stops honoring authentication contact information that was never explicitly registered by the user. Microsoft's documentation states, verbatim, that starting October 5, 2026 SSPR will only accept explicitly registered authentication methods, and that directory-sourced properties such as mobilePhone, businessPhone and otherMails that were never registered will no longer work for SSPR verification. Prepopulating those attributes from an on-premises directory remains supported as a way to seed the data, but the user still has to complete registration for it to count at reset time.
Does this mean prepopulating authentication contact info from Active Directory is no longer supported?: No, and this is the distinction most coverage will blur. Prepopulation still works and Microsoft still documents the requirements for it — properly formatted data in the on-premises directory and the right synchronization configuration. What changes is what prepopulated data buys you. Before this date, a synced mobile phone number could satisfy SSPR verification on its own. After it, that number is a convenience that makes registration faster, not a substitute for registration. The attribute still arrives in the tenant; it just no longer counts as a registered method.
How do we find out which users are affected before the deadline?: The population you care about is users who are enabled for SSPR and have no explicitly registered method. That is a different set from users with no contact information at all, which is the report most tenants look at first and the reason this gets underestimated. Check registration state rather than attribute presence: the authentication methods registration data in Entra tells you who has registered what, and the gap between that population and your SSPR-enabled group is your exposure. Do it before the enforcement date, because the failure surfaces at the worst possible moment — a locked-out user who cannot reset.
Why does Microsoft's registration campaign start after the enforcement date?: We do not know, and we are not going to invent a reconciliation. Both dates appear on the same Microsoft page. Enforcement is stated as starting October 5, 2026. The registration campaign that prompts affected users to register methods, described on that page as happening ahead of enforcement, is stated as starting November 9, 2026 — five weeks later. Read literally, the prompt designed to prepare users arrives after the change it was preparing them for. Plan against the October date and treat the campaign as a backstop that may help users you have already missed, rather than as the mechanism that will fix this for you.
What happens to a user who is not registered when enforcement starts?: They lose the self-service path and fall back to whatever your help desk process is. That is the practical cost of this change and it is why it is worth acting on early: SSPR exists to keep password resets away from a queue, so an unregistered population converts directly into help desk volume at the moment they are already locked out and least patient. For a regulated organization there is a second cost — the identity-verification step your help desk performs on a password reset is a control that gets audited, and pushing volume onto it increases the number of times that control has to be performed correctly.

Related service

Identity, Security & Compliance

Written by the team at Pro IT NW · Senior-led Microsoft project consultancy · Seattle and the Pacific Northwest, delivered USA-wide.

Share on LinkedIn Follow Pro IT NW