Microsoft Hands Your SMS and Voice MFA to Third Parties on October 30

The account was protected by MFA. That was the first line of the breach report, and it was technically true. The attacker ported the victim’s number to a SIM they controlled, waited for the six-digit code to arrive, and walked through the front door with a valid second factor. Entra logged a clean, successful sign-in. No impossible travel, no risky-session flag that fired in time. The “something you have” turned out to be something a bored call-center rep handed to a stranger on the phone.

That failure mode is not new, and Microsoft knows it. SS7 interception, SIM swaps, and OTP phishing kits have been quietly gutting telephony MFA for years while the registration numbers stayed stubbornly high. The response arrives on October 30, 2026, and it is a strange one: Microsoft is stepping out of the SMS and voice-call business inside your tenant. From that date, native SMS and voice-call MFA — the service Microsoft itself has run — gives way to a model that requires a supported third-party telephony provider to deliver those codes and calls.

Read the scope carefully, because it is easy to panic about the wrong thing. This touches telephony methods only: SMS one-time codes and automated voice calls. Microsoft Authenticator push, TOTP, FIDO2 security keys, passkeys, and Windows Hello for Business are untouched. If your users already carry a passkey, you can close this tab and go to lunch. The population that bites you is the one you quietly leaned on telephony for — frontline staff without managed phones, contractors, onboarding flows, and the break-glass fallbacks nobody re-tests.

On the provider list, I’ll say what the source says and no more: Microsoft has indicated supported third-party providers will be named, and the configuration lands under Protection > Authentication methods in the Entra admin center, where SMS and Voice call sit today. I’m not going to invent vendor names or quote pricing I haven’t seen. If anyone sends you a confident provider list this week, ask them where they got it.

Before you touch any configuration, find out who actually depends on this. Don’t guess from memory — pull it. This is read-only:

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

Connect-MgGraph -Scopes "AuditLog.Read.All"
​
try {
    $details = Get-MgReportAuthenticationMethodUserRegistrationDetail -All -ErrorAction Stop
}
catch {
    Write-Error "Could not read registration details: $($_.Exception.Message)"
    return
}
​
# Users registered for a phone-based method
$telephony = $details | Where-Object {
    $_.MethodsRegistered -contains 'mobilePhone'          -or
    $_.MethodsRegistered -contains 'officePhone'          -or
    $_.MethodsRegistered -contains 'alternateMobilePhone'
}
​
$telephony |
    Select-Object UserPrincipalName,
                  @{N='Methods';E={ $_.MethodsRegistered -join ';' }},
                  IsMfaRegistered |
    Sort-Object UserPrincipalName |
    Export-Csv .\telephony-mfa-users.csv -NoTypeInformation
​
Write-Host "$($telephony.Count) users rely on a phone-based method."

Cross-check that CSV against reality in the admin center. In Monitoring & health > Sign-in logs, filter the Authentication Details to SMS and voice call and look at the last 30 days — registered and actively used are different numbers, and the gap tells you how hard the migration bites. For spot checks, Users > [user] > Authentication methods shows the per-user picture. Treat the export as a worklist to review, not a script to blast state changes through.

What happens to the stragglers after the 30th is the part worth nailing down against Microsoft’s own docs, not a blog summary: once native delivery stops, a user whose only factor is SMS or voice, with no third-party provider configured, has no working telephony path. That’s a lockout waiting to happen during an incident — exactly when you can least afford it. Verify your break-glass accounts do not depend on a phone call.

Here is what the incident report would have said if someone had read it early:

1. Telephony MFA was never strong; it was convenient. This deadline just removes the option to pretend otherwise. Move anyone who can move to phishing-resistant methods — passkeys, FIDO2, Windows Hello for Business — rather than swapping one SMS pipe for another.
2. Audit usage, not registration. The sign-in logs tell you who’ll actually feel the cutover. Most tenants have far fewer active telephony users than registered ones.
3. Break-glass is the trap. A fallback that routes through a voice call you no longer control is not a fallback. Fix those accounts first.
4. Do not treat “required third-party provider” as a free security upgrade. It’s a contract, a new dependency, and an onboarding flow you now own. Budget the operational cost honestly.

You have a week. The users who’ll call the help desk on November 2 are already in that CSV.