Microsoft Is Retiring SMS and Voice MFA: Who Breaks on February 1, 2027 and How to Check Your Tenant

Microsoft updated its guidance this week with the full retirement plan for SMS and voice authentication, under a headline that tells you where this is going: passkeys by default. Texted codes and voice calls have been the weakest link in multifactor authentication for years, phishable and vulnerable to SIM swap, and Microsoft is now removing its own telecom delivery for them entirely. This guide covers exactly what is retiring and when, what happens to users who still rely on a phone number, how to find those users in your tenant this week, and the migration options, including the paid path for organizations that genuinely must keep SMS.

What exactly is Microsoft retiring

The retirement covers Microsoft-provided SMS and voice call authentication in Microsoft Entra ID, for both MFA sign-in and self-service password reset. Three boundary lines matter:

• It is the Microsoft-provided telecom delivery that ends. Organizations with a genuine regulatory or operational need for SMS or voice can keep the methods by contracting a telecom provider through the new Microsoft Security Store, at their own cost, typically per-message.
• It applies to users enabled for SMS or voice in the Authentication Methods Policy or in legacy per-user MFA settings. Both populations get the passkey auto-enablement.
• Public cloud only, for now. Government and other cloud environments follow on a later schedule with separate communications.

In parallel, passkeys become the default authentication experience. Users already signing in with passkeys, Windows Hello for Business, or FIDO2 security keys keep working as they are, though anyone still enabled for SMS or voice in policy may still be prompted to register a passkey on eligible devices.

The retirement timeline

Will your users be locked out?

Microsoft's answer is a careful no, and the mechanics matter. After February 1, 2027, a user whose only available MFA method is SMS or voice does not lose the account. They get a blocking registration prompt: sign-in pauses until they register a passkey, then continues. No account gets disabled.

Now picture that mechanic on a Monday morning in a company where 40 people still authenticate by text message. Every one of them hits a registration wall at 8 a.m., on whatever device they happen to hold, with varying familiarity with passkeys, and the help desk absorbs the difference. That is what "no lockout" looks like in practice. The blocking prompt lands on a date you already know, so the support load can be planned in advance. The same retirement also applies to self-service password reset, so a phone-only user who forgets their password after the deadline has no self-service reset path until they register something better.

# Who hits the blocking passkey prompt? Users whose ONLY registered methods
# cannot satisfy MFA after the retirement: phone (SMS/voice), email, security questions.
# Requires Microsoft Entra ID P1 or P2. Role: Reports Reader, Security Reader, or Global Reader.
# Install once: Install-Module Microsoft.Graph.Reports -Scope CurrentUser

Connect-MgGraph -Scopes 'AuditLog.Read.All' -NoWelcome

$phone = 'mobilePhone', 'alternateMobilePhone', 'officePhone'
$weak  = $phone + 'email' + 'securityQuestion'

$affected = @(
    Get-MgReportAuthenticationMethodUserRegistrationDetail -All | Where-Object {
        $m = @($_.MethodsRegistered)
        ($m | Where-Object { $_ -in $phone }).Count -gt 0 -and
        ($m | Where-Object { $_ -notin $weak }).Count -eq 0
    }
)

$affected |
    Select-Object UserPrincipalName, UserDisplayName,
                  @{ n = 'MethodsRegistered'; e = { $_.MethodsRegistered -join ', ' } } |
    Sort-Object UserPrincipalName | Format-Table -AutoSize

"Users who would hit the blocking passkey prompt: $($affected.Count)"

What to move them to

The replacement Microsoft is steering everyone toward is the passkey: a cryptographic credential that resists phishing, SIM swap, and replay, because there is no code to intercept and nothing to type into a fake login page. Entra ID supports two kinds:

• Synced passkeys live in a platform credential manager like iCloud Keychain or Google Password Manager and follow the user across their devices. They are the natural fit for phone-centric users, which is exactly who your SMS population is.
• Device-bound passkeys stay on one device: a passkey in Microsoft Authenticator, Windows Hello, or a FIDO2 hardware key. They fit admins, high-privilege accounts, and regulated roles.

The rollout tool is the registration campaign: in the Microsoft Entra admin center under Entra ID, Authentication methods, Registration campaign, target the security group of phone-only users you just identified and the campaign prompts them to set up a passkey the next time they complete MFA. Running your own campaign before September 1 means your users hear about the change from you, with your instructions, before Microsoft's prompt reaches them. Microsoft also publishes end-user communication templates worth stealing.

If you genuinely need to keep SMS

Some environments have a real reason a texted code must survive: a compliance regime that mandates an out-of-band channel, or a user population where no other method is workable. For those cases Microsoft is opening a paid path: contract a telecom provider directly through the Microsoft Security Store. Provider options publish September 18, 2026, configuration opens October 30, 2026, and pricing is typically per-message and varies by provider, volume, and region. Two practical notes: document the specific regulation or scenario that justifies it, because an auditor or insurer will ask, and scope it to the user segments that need it. Migrating everyone else to passkeys costs nothing.

This retirement is one move in a bigger cleanup Microsoft has been running for two years: mandatory MFA on admin portals, number matching enforced by default, and now the weakest second factor removed outright. If your tenant still runs a mix of MFA methods and policies, our guide to per-user MFA vs Security Defaults vs Conditional Access covers which enforcement method should be underneath these authentication methods in the first place.