The phone number on the record was a credential: Entra ID stops accepting it

Think about the "mobile phone" field on any employee record in your directory. Who typed it in? At most companies we work with, the user did not: it arrived through a sync from on-premises Active Directory, or from somebody onboarding a new hire on a Tuesday morning. And until now, with that field populated, that person could reset their password at the self-service portal. Microsoft is about to stop accepting it.

What exactly changes

Microsoft Entra ID self-service password reset—SSPR—will start requiring explicitly registered authentication methods to verify whoever asks for the change. Contact details living in directory attributes will no longer count unless the user registered them as a method. The documentation names all three: mobilePhone, businessPhone and otherMails. The message centre post describing it is MC1325414, and it affects every tenant with SSPR enabled, in the public cloud and in the US government clouds.

Microsoft's stated reason is that verification should now rest on "trusted, user-validated methods rather than directory-sourced attributes". It is a product-note sentence, but it describes precisely what was there before.

Who writes that field

What is interesting is that this was never a covered-up oversight: it is documented as a feature, with its own Microsoft Learn page and a title that says it all, "Prepopulate user authentication contact information". Two sentences from that page, verbatim:

"This synchronized data is made available to Microsoft Entra ID and SSPR without requiring user interaction. When users need to change or reset their password, they can do so even if they haven't previously registered their contact information."

"If you provided a value for Mobile phone or Alternate email, users can immediately use those values to reset their passwords, even if they haven't registered for the service."

The same page carries the sync connector's mapping table: telephoneNumber from on-premises Active Directory becomes Office phone, and mobile becomes Mobile phone. That closes the circuit. A value written on an object in your own domain travels up through the sync and, at the far end, proves identity at the recovery portal without its owner having done anything at all.

The difference from a registered method is who writes it. A registered method is enrolled by the user themselves from their security info page, proving they control that phone or mailbox; it can also be set on their behalf by an administrator holding the Privileged Authentication Administrator role, which is a short and auditable list. A contact attribute is written by anyone with write access to the object, and nobody has reviewed that list since it was created.

Put that way, write access to a user's contact details has amounted, in practice, to being able to recover their account. With the SSPR policy requiring two methods you need two fields, mobile and alternate email, which a delegation over the object usually does grant. That permission appears in no role matrix, no privileged access review looks at it, and nothing alerts when it changes. Nobody granted it on purpose: it slipped in through the back door of a feature designed to keep people from calling support on day one.

The question that follows answers itself in an afternoon and does not depend on Microsoft: who can write to the contact details of any user in your directory today? Make the list properly, with names. If it includes admin staff, or an automated process nobody maintains, then you know how accounts get recovered at your company. We wrote a few weeks ago about what piles up in a directory when nobody looks, explaining why there are more records than employees.

The hybrid case, which is the one that hurts

If you sync from an on-premises Active Directory, that number is not born in Entra. It is born on an object in your own domain, and write permission over the contact attributes of an organisational unit is exactly the kind of delegation made ten or fifteen years ago so that admin staff could update contact numbers without bothering IT. There is nothing malicious about it. It is simply that the full chain—who writes in on-premises AD, what the sync carries up, what the recovery portal accepts—was never drawn end to end on one whiteboard.

It is the same argument we made when explaining that your identity provider is not just another application: if the directory decides who gets into everything, permissions over the directory outweigh permissions over any application hanging off it. A text field included.

The 86%: check the denominator

The figure that comes with this change and reassures everyone is this: roughly 86% of SSPR verifications already use registered methods. The noun matters. Those are verifications, not users.

A verification is generated by somebody who uses the system. Think of the person who joined in 2019, knows their password by heart and has never once visited the reset portal: they contribute not a single verification to that statistic, in either direction. They are invisible in the numerator and in the denominator. And they are precisely the person who will find the door shut on the day they need it, most likely after a holiday or a long absence, which is when people forget passwords. The 86% describes how things go for those already using the system. It says nothing about those who never have.

The useful measure is a list of accounts, not a percentage. You get it from the user registration details report in the Entra admin centre, under Authentication methods → Monitoring, filtered by SSPR-capable users; or from the command line, which is easier to repeat every week:

Get-MgReportAuthenticationMethodUserRegistrationDetail -All ``
  -Filter "isSsprEnabled eq true and isSsprRegistered eq false" ``
  | Select-Object UserPrincipalName, UserDisplayName

One caveat about that report, because it cuts in the same direction as the problem: we have not found it documented whether isSsprRegistered distinguishes a method the user registered from a value inherited from the directory. If it does not, the report carries the same bias as the 86% and leaves out the people at risk. Cross-check it on a small sample by looking at the raw attributes, which is half a dozen commands:

Get-MgUser -UserId '[email protected]' ``
  | Select businessPhones, mobilePhone, otherMails | Format-Table

Four dates for one cutoff

If you have read anything about this over the past few months, you probably have 7 September 2026 written down. That was the date in the first version of the notice, published 28 May. MC1325414 was updated on 4 August and the whole calendar shifted. But when we went to collect the dates we found there is not one, there are four, and they do not agree:

That last row is the one that matters, and it is not a nuance. Microsoft Learn has the two dates the wrong way round compared to the message centre: it says that from 5 October "SSPR will only accept explicitly registered authentication methods", and that the registration campaign starts on 9 November. Which would put the campaign meant to prepare people a month after the cutoff. One of the two pages is wrong, and from outside you cannot tell which.

The practical conclusion is short: plan as if 5 October were the cutoff, because it is the earliest date on which an official Microsoft page says this stops working. And confirm it in your own message centre, which holds the version that applies to your tenant. We read MC1325414 in public archives that collect those notices, not in a live tenant.

This does not come alone

The SSPR change is one piece of a larger move, and the deadlines overlap. Since 1 September 2026, five days ago, users enabled for SMS or voice are auto-enabled for passkeys and pulled into a Microsoft-managed registration campaign that nudges them when they complete MFA. And from 1 February 2027, Microsoft-provided SMS and voice delivery retires: anyone who still needs it will have to bring their own telecom provider through the Microsoft Security Store. The documentation leaves no room: "There is no opt out from this February 1 behavior. It will be enforced for all tenants." There is a temporary opt-out, yes, but it only covers the September-to-February stretch.

We wrote about the September start and the cases that do not fit the happy path in detail a few days ago. And if your plan leans on third-party multi-factor, read first why there is an MFA that Entra does not count as MFA. The lesson rhymes with today's: what counts is what the directory recognises as a method, not what you know the user has.

What we would do, in order

• Pull the list of accounts enabled for SSPR with no registered methods. By name, repeated every Monday until it hits zero.
• Audit who writes to the contact attributes. In Entra and, if you are hybrid, in on-premises AD. Until the cutoff, that list is your real list of people able to recover other people's accounts. After the cutoff it becomes a different and much shorter one: whoever holds the Privileged Authentication Administrator role. Worth looking at both, because a privilege is changing hands.
• Do not wait for Microsoft's campaign. Running your own before 5 October, in your own words and tone, spreads the load over weeks instead of concentrating it on the day the system starts nudging by itself. And if Learn has the dates right, Microsoft's campaign would arrive late.
• Define the human fallback. Anyone who can neither register nor reset will end up calling, and at that point the thing verifying identity is a person in a hurry. Write down how you verify a caller before you need to, because that becomes your real recovery path and it is the easiest one to fool.
• Rehearse it on a real account, stopwatch in hand.

That last point is the one everybody skips and the only one that discovers anything. In infrastructure we have put it the same way for years: an untested backup is not a backup, it is a lucky charm. Identity recovery behaves the same, and we devoted a whole post to the continuity plan nobody has rehearsed, because the pattern repeats everywhere. What only gets tested on the day of the incident is exactly what you cannot afford to fail that day.

When this is not about you

If you have twenty people, all with Authenticator registered and their phone in hand, this change will pass over you without your noticing, and that is fine. No project required. But the underlying problem has a domestic version that applies to anyone: look at the recovery email address on your domain registrar account, or on your cloud provider's console. More often than you would think it points at the mailbox of somebody who no longer works here, or at a distribution list half the company reads. There too, the recovery detail is not controlled by the account holder, and there is no Microsoft coming to fix it for you.

We are left with two questions about any employee in your directory. Which of their fields, written by whom, could give them back access to their account today. And what happens when that field stops counting and they have registered nothing.

Sources: the two quoted sentences about synchronised data being usable without prior registration, the telephoneNumber/mobile mapping table, the Privileged Authentication Administrator role, the attribute-reading commands and the 5 October and 9 November dates all come from "Prepopulate user authentication contact information for SSPR", Microsoft Learn. The MC1325414 identifier, publication date (28 May 2026), update date (4 August 2026), scope and message centre dates—title 9 November, timeline with campaign 5 October and enforcement 7 November, "act by" field 6 November—come from the public Microsoft 365 message centre archive. The first-version dates (campaign 6 July, enforcement 7 September) and the Microsoft line about "trusted, user-validated methods" come from Petri's coverage. The 86% of verifications figure and the Get-MgReportAuthenticationMethodUserRegistrationDetail cmdlet come from Tony Redmond at Office 365 for IT Pros, 17 June 2026. The passkey and SMS/voice retirement dates and the no-opt-out sentence come from Microsoft Learn, updated 10 August 2026. What we do not claim: we have not read MC1325414 in a live tenant but in public archives that collect those messages, so confirm the dates in your own message centre; we do not know which of the two Microsoft pages has the dates right, only that they contradict each other; we do not know whether the registration report distinguishes a registered method from an inherited attribute, and we say so where it matters; we do not know how many Spanish companies have users without registered methods, because nobody publishes that; and we describe no real abuse of this path, because we have none documented to cite.