The Wall Is Coming Down: What SMS Retirement Means for Your SSPR Strategy

Every wall falls eventually. Winterfell held the North for a thousand years before it burned. The Wall itself stood against everything beyond it, until it didn't. In Destiny, even the Traveler's Light has limits; the tools that got a Guardian through one Crucible match don't always survive the meta shift into the next season.

SMS-based authentication is having its own Season of the Wall Falling. For years it's been the reliable, boring workhorse behind self-service password reset (SSPR), the thing nobody thought about until it was gone. Now Microsoft has put a date on its retirement and if you're a consultant with clients leaning on SSPR, you need to understand exactly what's changing, why your front lines are already feeling it, and what the actual end state should look like.

What's Happening and When?

Microsoft has confirmed it's retiring Microsoft-provided SMS and voice authentication across Entra ID, with passkeys becoming the default sign-in experience. The timeline breaks into three milestones:

• September 1, 2026: Any tenant with users enabled for SMS or voice gets those users auto-enrolled for passkey registration. This isn't optional and isn't a hard cutover yet. It's Microsoft starting the nudge campaign and prompting users to register a passkey the next time they complete MFA.
• February 1, 2027: Microsoft-provided SMS and voice delivery is retired for everyone except Global Administrators and external users (internal guest users are still included in this February date). If a user's only registered MFA method is SMS or voice at this point, they'll hit a blocking prompt requiring passkey registration before they can sign in. There's no opt-out from this behavior once the date hits.
• July 1, 2027: The same retirement lands for Global Administrators and external users.

Organizations with a genuine business, regulatory, or technical need to keep SMS/voice alive aren't completely out of options. Microsoft is opening the door to customer-managed telecom providers through the Microsoft Security Store, with details expected September 18, 2026. But that's a paid, opt-in path you have to actively configure. It is not the default, and it is not free.

Critically, this retirement isn't limited to MFA. It applies across Entra, which means it hits SSPR just as hard.

What We're Seeing at the Front Lines

This is where it stops being a slide in a roadmap deck and starts being a Tuesday-morning support ticket. Myself and my colleague, Robert (Rob) Breese, have been in the middle of these conversations with clients this recently, and the range of reactions has been... illuminating.

Some clients are handling it exactly the way you'd hope, recognizing SMS was never a strong method to begin with and treating this as the forcing function to finally modernize. Others have gone the opposite direction entirely. Others whose reaction to losing SMS for SSPR was simply to disable SSPR altogether and hand the burden back to the service desk. That's not a security decision, that's a shrug dressed up as a decision, and it just relocates the pain to your help desk queue instead of solving it.

There's also a more subtle landmine hiding in the SSPR configuration itself, and it's the kind of thing that trips up admins who assume Microsoft Authenticator is a clean drop-in replacement for SMS. When your "Number of methods required to reset" policy is set to two, Microsoft Authenticator cannot be counted as one of just two methods, the documentation is explicit that Authenticator can't be selected as the only method when one is required, and can't be paired with just one additional method when two are required. In practice, that means if you're relying on Authenticator plus one other method to satisfy a "2 methods required" SSPR policy, you're not actually compliant, you need a third method registered underneath it. We've ran into exactly this while walking a client through their policy, and it's an easy thing to miss if you're not reading the fine print on Microsoft's authentication methods documentation.

Keeping SSPR at Two Methods Without SMS

So if SMS is going away and Authenticator doesn't stack cleanly with a single backup method, what's the realistic bridge for clients who aren't ready to abandon SSPR with a password entirely?

Email OTP. It's listed right alongside SMS and Authenticator as a supported SSPR authentication method, and, unlike SMS, it isn't on Microsoft's retirement list. For clients who need to preserve a "2 methods required to reset" policy without falling back to personal phone numbers or paid third-party telecom providers, pairing Email OTP with something like Software OATH tokens or a secondary registered method keeps that two-factor SSPR requirement intact without asking users to hand over a personal mobile number.

But is it actually more secure than SMS?

This is the debate Rob and I kept coming back to, and the honest answer is: not really, it's a lateral move, not an upgrade.

Based on Microsoft's own documentation, both SMS and Email OTP sit in the same security tier for SSPR. Both are single-factor, out-of-band OTP methods delivered over a channel Microsoft doesn't control end-to-end, and Microsoft's authentication methods table lists them side by side as valid SSPR options with no differentiated risk tier between them.

SMS's well-known weaknesses are SIM-swapping, SS7 interception, and number-porting attacks, an attacker doesn't need your password, just control of your phone number. Email OTP doesn't eliminate that category of risk. It just relocates it. The "intercept the out-of-band channel" problem shifts to the security of the user's mailbox. If that inbox is protected by nothing more than a password, or worse, the very password that's currently being reset, an attacker who's already compromised or guessed the mailbox credentials gets the reset code just as easily as an attacker who cloned a SIM. You haven't removed the weak link. You've just changed which lock it's attached to.

Microsoft's own guidance reflects this parity: SMS sign-in and Email OTP are both listed only as secondary/SSPR authentication methods, never as strong or phishing-resistant credentials, and Microsoft explicitly recommends configuring two or more SSPR methods precisely because any single method, including these two, can be unavailable or compromised. Neither one was ever meant to carry the account on its own.

So the practical read for clients: Email OTP is the pragmatic bridge once SMS is off the table, but frame it internally as a lateral move in security posture, not a hardening. Don't let "we replaced SMS with Email OTP" get reported up the chain as a security win, it's a compliance patch that keeps SSPR functional, nothing more.

The Actual End Goal

None of this — Email OTP, third-party telecom providers, careful method-counting — is the destination. It's scaffolding. Microsoft has made its intent unmistakable: passkeys are the default now, and phishing-resistant authentication (passkeys, Windows Hello for Business, FIDO2) is where every tenant needs to land, SSPR included.

The uphill battle you're describing is real, especially for hybrid clients who aren't ready to fully decouple from on-prem passwords. But that's exactly the fight worth having internally: give every user a strong password they never actually need to type, pair it with Windows Hello for Business via cloud trust, and the password functionally disappears from daily use, on-prem resources included (sort of, there are limitations). Email OTP buys you runway. It shouldn't be the destination on your roadmap slide.

The Wall doesn't hold forever. Better to have your Guardians already through the gate before it comes down.

Thanks for reading! Drop a comment for topics you'd like to see covered or your thoughts on today's blog. And if you're up for it, subscribe to be alerted to new blogs!

Stay vigilant out there.

— Kevin