SMS Sign-In Dies in Entra ID in February 2027

Read the headline that dropped on September 21 too fast and you’ll panic your whole helpdesk for nothing. Microsoft is not killing SMS multi-factor authentication. Text-a-code as your second factor still works after February 2027, still limps along with all its SIM-swap charm intact. What’s being switched off is SMS as a first factor — the flow where a user types a phone number, gets a code, and is in. No password. That’s the thing dying.

Small blast radius for most tenants. Genuinely load-bearing for the handful who leaned on it. Text message sign-in was pitched years ago as the passwordless option for frontline and kiosk workers — retail, logistics, deskless staff with a shared badge and no appetite for a password. If you turned that on and forgot about it, February 2027 is the morning those users stop being able to log in. Nobody gets a warning banner. They just fail, and you get the ticket.

So the job is boring and important: find who actually uses it. In Graph, the signal is a property called smsSignInState hanging off a user’s phone authentication method. When it reads ready, that user can sign in with SMS as their first factor. That’s your list.

Start in the portal to size the problem before you script anything. Entra admin center → Identity → Monitoring & health → Sign-in logs, then add the Authentication method column or filter and look for SMS on interactive sign-ins. That tells you who’s genuinely doing it, not just who could. The registration state below tells you who’s exposed.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

# Audit: which users have SMS enabled as a first-factor sign-in method?
# Read-only. Needs UserAuthenticationMethod.Read.All (admin consent).
Connect-MgGraph -Scopes "User.Read.All","UserAuthenticationMethod.Read.All"
​
$affected = [System.Collections.Generic.List[object]]::new()
​
# Pull users with paging; -All handles the nextLink for you.
$users = Get-MgUser -All -Property "id,userPrincipalName,accountEnabled" `
                    -ErrorAction Stop
​
foreach ($u in $users) {
    try {
        $phones = Get-MgUserAuthenticationPhoneMethod -UserId $u.Id -ErrorAction Stop
    }
    catch {
        Write-Warning "Could not read phone methods for $($u.UserPrincipalName): $($_.Exception.Message)"
        continue
    }
​
    foreach ($p in $phones) {
        if ($p.SmsSignInState -eq 'ready') {
            $affected.Add([pscustomobject]@{
                UserPrincipalName = $u.UserPrincipalName
                AccountEnabled    = $u.AccountEnabled
                PhoneType         = $p.PhoneType
                SmsSignInState    = $p.SmsSignInState
            })
        }
    }
}
​
$affected | Sort-Object UserPrincipalName |
    Export-Csv .\sms-firstfactor-affected.csv -NoTypeInformation
​
Write-Host "Found $($affected.Count) users with SMS first-factor sign-in enabled."

That per-user call is slow across a big directory — this is an audit you run overnight against a CSV, not a live loop you point at 60,000 people at lunchtime. Export it, eyeball it, hand it to whoever owns those workers. Don’t disable anything off the back of a raw query. That’s how you lock out the night shift by accident.

Migration is the easy part, which is the small mercy here. Three roads. Microsoft Authenticator is free, works in every Entra tier, and phone sign-in through the app is the like-for-like replacement — a genuine passwordless flow that isn’t a text message begging to be intercepted. Passkeys / FIDO2 are the better answer if the hardware cooperates; they need a capable device or a security key, and they cost nothing at the licence level — passkeys sit in every Entra tier too, no P1 or P2 required. And keep a Temporary Access Pass in your pocket for the deskless user who shows up with a locked account and no enrolled method, because that user always exists.

The uncomfortable read: if SMS was your only sign-in method for a group of people, you were one SIM-swap away from a bad week the whole time, and Microsoft just set a deadline on the risk you’d been ignoring. Five months is plenty. It won’t feel like it in late January when the change freeze lands and someone remembers the warehouse tablets.

Run the audit this week. Fix it in October. Don’t be the ticket.