I killed SMS for password reset before Microsoft did. Here’s what broke.

The claim on the table, courtesy of this week’s Entra News: SMS is going away as a self-service password reset method. Short, scary, retweetable. So I treated my lab tenant like it was already gone, ripped SMS out of the SSPR path and watched what screamed.

Most of the fear is misplaced. Some of it isn’t. Let’s take the headline apart.

Does “SMS for SSPR retires” mean your users can’t get a reset code anymore?

Not the way people are reading it. This is SSPR-specific. The method that’s being deprecated is text-message verification inside the password reset flow, the “we texted a code to the phone ending in 42” step when someone’s locked out. It is not SMS for sign-in MFA, which is a separate, much louder conversation Microsoft has been having for years. If your Conditional Access and authentication-methods policy still allow SMS at sign-in, that keeps working regardless of this change. Conflating the two is how you end up explaining to a VP why half the sales team got locked out of their own phones.

The honest caveat: the newsletter is thin on a hard cutover date, and I’m not going to invent one. Treat this as a “migrate now, verify the deadline in Message Center” item, not a “panic by Friday” item. The retirement direction is real; the exact day it stops answering is the part you confirm against your own tenant’s Message Center post, not a blog, mine included.

Who’s actually affected?

Anyone whose SSPR registration leans on a phone number as the only usable factor. That’s disproportionately your frontline and deskless staff, your execs who refused the Authenticator prompt, and that one service-adjacent account somebody registered with a personal mobile in 2019. License tier isn’t the gate here, SSPR configuration is. If the Authentication Methods policy permits phone, and a user registered only that, they’re exposed.

What do they migrate to?

In rough order of “please do this”: Microsoft Authenticator (push or passwordless), FIDO2 / passkeys, voice call, and email as the low-trust fallback. Voice call survives SMS’s retirement, which feels absurd, it’s the same phone number, but it’s a different method object and a different registration. Don’t assume a user with SMS automatically has voice; they frequently don’t.

How do I find the exposed users without guessing?

Here’s the trap. There is no clean “SSPR = SMS” flag per user. SSPR eligibility is driven by the tenant policy plus whatever the user registered. So the real audit is: who has a phone method registered and little else to fall back on. That’s a read against authentication/phoneMethods. Read-only, paginated, with the error handling you’ll want when you hit a guest account that returns nothing useful.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

Connect-MgGraph -Scopes "User.Read.All","UserAuthenticationMethod.Read.All"
​
# Read-only audit: flag users whose only phone method is SMS-capable mobile
$results = foreach ($u in Get-MgUser -All -Property Id,UserPrincipalName,AccountEnabled) {
    try {
        $phones = Get-MgUserAuthenticationPhoneMethod -UserId $u.Id -ErrorAction Stop
        $sms = $phones | Where-Object { $_.PhoneType -eq 'mobile' }
        if ($sms) {
            [pscustomobject]@{
                UPN           = $u.UserPrincipalName
                Enabled       = $u.AccountEnabled
                MobileNumbers = ($sms.PhoneNumber -join '; ')
                OtherMethods  = ($phones | Where-Object { $_.PhoneType -ne 'mobile' }).PhoneType -join '; '
            }
        }
    }
    catch {
        Write-Warning "Lookup failed for $($u.UserPrincipalName): $($_.Exception.Message)"
    }
}
​
$results | Export-Csv .\sms-sspr-exposure.csv -NoTypeInformation

Note the shape: pull the list, export it, then go read the CSV and decide. You do not pipe a live query straight into a bulk change. That’s a resume-generating event. When you’re ready to nudge a reviewed set of users toward re-registration, drive it off that CSV with -WhatIf on first, every time.

And the Token Protection thing, related?

No, and the newsletter stacking them in one issue doesn’t make them one story. Token Protection (token binding) is a Conditional Access control that ties a sign-in session token to the device it was issued to, so a stolen token won’t replay from an attacker’s machine. The “enforcement” callout is about tightening it from a soft, report-only posture toward actual block in specific sign-in scenarios. It touches your CA policies, not your SSPR methods. Check your Token Protection policies in report-only before you flip enforce, a wrongly-scoped bind will lock out legitimate sessions as efficiently as it stops a thief.

The verdict

Where to look, both of them, in the Entra admin center: SSPR methods under Protection → Authentication methods (and the legacy Password reset blade for the SSPR scoping); Token Protection under Protection → Conditional Access, inside the session controls of a policy.

So: “SMS for SSPR retires” is true but undersold. The precise version is, a fallback factor your least-covered users quietly depend on is being removed, on a timeline you still need to confirm, and the fix is registration coverage, not a single toggle. Audit the phone-only crowd, get them onto Authenticator or a passkey, and keep Token Protection in report-only until you’ve proven it won’t bind someone out of their own session. Two separate jobs. Do them as two separate jobs.