The SSPR blind spot Microsoft's SMS retirement is about to expose
Two dates. One dependency map most Entra tenants have never drawn. Here's how to find it before February 2027 finds it for you.
In every Entra tenant we've reviewed this quarter, one pattern keeps repeating.
A meaningful share of users still have SMS or Voice registered as one of their authentication methods. Some as their only method. Many as one of two methods on an SSPR policy that requires two.
And in almost every case, the identity team can't tell us the exact number without opening the portal.
That was tolerable while SMS and Voice were still fully supported. It stops being tolerable now that Microsoft has put dates on the retirement.
What Microsoft is actually changing
Microsoft announced the change on 13 July 2026. Two dates matter.
1 September 2026. Passkeys became the default authentication experience in Entra ID. Users enabled for SMS or Voice in the Authentication Methods Policy (or in legacy MFA settings) were auto-enabled for passkeys. The Registration Campaign moved to Microsoft-managed state and began nudging those users to register a passkey at their next sign-in. SMS and Voice still work as a fallback during this window.
1 February 2027. Microsoft-provided SMS and Voice delivery retires. That includes SSPR. Users whose only available MFA method is SMS or Voice will hit a blocking passkey registration prompt before they can sign in.
The change doesn't ban SMS from Entra ID outright — it changes who operates and pays for the delivery channel. Organisations with a regulatory or operational need to keep SMS can configure a customer-managed telecom provider through the Microsoft Security Store. Everyone else is being moved to passkeys, Windows Hello for Business, or FIDO2.
A temporary opt-out exists between the two dates. It gives you room to run your own migration plan. It does not delay the 1 February 2027 retirement.
The sequencing matters more than either date on its own. September starts the nudging. February removes the fallback. The window in between is when you find out what your tenant actually depends on.
(Note: these dates apply to the public cloud. GCC, GCC High and DoD tenants follow separate schedules.)
The scenario most identity teams haven't modelled
Take a typical user. SSPR policy requires two methods. The user has:
Microsoft Authenticator
SMS
Today, that user meets the policy. Two registered methods. Two working recovery channels. Compliant on paper and functional in practice.
After 1 February 2027, that user has one working method.
Same user. Same registered methods. Different reality.
They can still sign in with Authenticator. But if they lose access to their phone, forget their password, or get flagged by risk-based sign-in, the SSPR flow that used to give them two paths back into the account now gives them one — and if that one path (Authenticator) is what they've lost access to, they can't self-recover at all.
This is the scenario nobody has modelled, because nobody has been forced to. Requiring two methods for SSPR has been the recommended posture for years. It reads as defence in depth on the policy page. And for as long as both of the accepted methods were valid, it was.
The moment one of the two disappears, the policy becomes a documentation artefact, not a control.
Why this matters beyond MFA
Authentication and account recovery are the same problem viewed from two ends. A well-designed sign-in flow is worth very little if the recovery flow behind it is fragile.
This is where SMS retirement stops being a migration exercise and becomes a resilience question:
If a user is locked out on the morning of 2 February 2027, what path do they have back in?
If that path depends on the help desk, what does the help desk verify against?
If that path depends on email, is the mailbox itself protected by something other than the method being retired?
If a break-glass or service account was configured with SMS as a fallback years ago, does anyone still know?
None of these questions are new. What's new is the deadline that turns them from "we should look at this" into "we will find out on 2 February whether we looked at this."
What to check in your tenant this week
The data you need is already in your tenant. It has been sitting in the Entra portal the whole time. Four places to look, in order — no PowerShell, no Graph, no scripts.
1. Authentication methods activity — registration report
Entra ID → Authentication methods → Activity → Registration
This is the report that answers the question the identity team usually can't. For every user, it shows:
Which methods they have registered
Whether they are MFA capable
Whether they are passwordless capable
Whether they are SSPR enabled, SSPR registered, and SSPR capable
Filter for users whose registered methods include only Mobile phone or Alternate mobile phone. Filter separately for users whose registered methods are limited to a phone-based method plus one other. Those two filters give you the "single-method exposed" population and the "policy says two, reality says one after February" population.
2. Authentication Methods Policy
Entra ID → Authentication methods → Policies
Confirm which populations are still enabled for SMS and Voice. Cross-reference against the registration report to identify users who are in scope for auto-enablement — they were nudged to register a passkey at next sign-in from 1 September 2026 onwards.
3. Password Reset — Authentication methods
Entra ID → Password reset → Authentication methods
This is where the SSPR "two methods required" setting lives. Confirm the number of methods required, and confirm which methods are accepted. If Mobile phone (SMS) or Office phone (Voice call) is one of the accepted methods, this is the policy that will silently break for users who registered against it.
4. Users flagged for review
Entra ID → Users → filter by role and privilege
Cross-reference the registration report against your privileged role assignments, break-glass accounts, and any account used by external identity administrators, MSPs, or vendors. These are the accounts where a broken recovery path is not an inconvenience — it's an incident.
All four checks can be performed by anyone with the right read permissions in the Entra portal, in under an hour for most tenants.
What to tell the board
If this reaches an executive briefing, three sentences are usually enough.
Microsoft is removing SMS and Voice as a supported authentication and recovery channel across Entra ID, with a hard date of 1 February 2027.
Our real exposure isn't the users who lose SMS — it's the users whose recovery path silently drops from two methods to one, and the accounts we don't yet know about.
We have a window to measure the exact number, migrate the users, and redesign the recovery path so it's resilient rather than compliant on paper. That work should be planned now, not in January.
The board question that usually follows is "how much of this is already done?" The registration report answers that question in numbers, not opinions.
Sequencing the migration without breaking recovery
A workable order of operations, based on what we've seen work — and what we've seen fail:
Measure first. Run the registration report. Get the two numbers: users with SMS or Voice as their only method, and users with SMS or Voice as one of two registered SSPR methods. These are the numbers that anchor every conversation from here.
Fix the SSPR policy before you migrate users. Update the accepted methods list so that phishing-resistant methods (passkeys, Windows Hello for Business, FIDO2) count toward the two-method requirement, and phone-based methods are removed from the accepted list on the same change.
Prioritise privileged users, break-glass accounts, and shared identities. Get these onto phishing-resistant methods and verified recovery paths before the wider rollout. These are the accounts where "we'll get to it" turns into a Sev-1.
Register users for phishing-resistant methods before Microsoft's nudge does it under pressure. The nudge is already active. If you don't want users making method decisions at sign-in while a prompt is in their way, get ahead of it.
Only opt out temporarily if you have a real reason. The opt-out is a planning tool, not a strategy. If you use it, put a date on when you'll turn it off.
Rehearse the recovery path. Pick a real user, simulate a lost-device scenario under 2 February 2027 conditions, and walk through the recovery. If it works, document it. If it doesn't, that's the finding.
Closing
The retirement of Microsoft-provided SMS and Voice isn't the interesting story. The interesting story is what it forces every Entra tenant to confront: that authentication resilience and phishing resistance are separate properties, and that "we require two methods" is only a control for as long as both of those methods stay valid.
The tenants that come through this cleanly won't be the ones that migrated the fastest. They'll be the ones that measured accurately, fixed the recovery path before the deadline, and stopped confusing policy configuration with resilience.
If you want a second set of eyes on your tenant's exposure — the numbers, the SSPR policy, and the recovery paths that need to be rehearsed before February — that's the kind of work we do at Nimbus Cyber. Get in touch and we'll show you what we'd check first.
Comments