Entra SMS and Voice MFA Retirement: What Changes in 2027

As many of you might know, Microsoft have made the frustrating decision to retire their own SMS and voice MFA in Entra ID. Many will understand my frustration with this, especially in areas like education. But alas, needs must, and most of what I've read about it boils down to "SMS codes stop working in 2027". That's roughly true and not much use if you're the one planning it. The details are what matter, like who moves on which date, what users see when they sign in that day, and how little the opt-out actually gets you.

Below is what Microsoft's documentation and FAQ say, and then the Conditional Access side, which most articles skip. That part is worth reading even if you skim the rest, because it decides whether you migrate your users once or twice.

The Dates

Two scope details are easy to get wrong.

• Only the Global Administrator role gets the later date. Microsoft's wording is "all users except Global Administrators and external users". Privileged Role Administrators, Security Administrators, Exchange Administrators and every other admin role are on the February date. If your admins still lean on SMS, most of them move in February, not July.
• Internal guests count as internal. It sounds obvious written down, but "guest" and "external" get used interchangeably in most tenants. Internal guest users aren't in the July group, so they're on the February date with everyone else.

It covers self-service password reset too, so the "forgot my password, text me a code" route goes the same way. A few things sit outside it. The timeline applies to the public cloud only (other clouds follow later), Azure AD B2C and External ID tenants aren't affected by this announcement, and external MFA methods aren't retired. A user on external MFA is only in scope if they're also enabled for SMS or voice.

What Users Actually See

After their retirement date, a user whose only MFA method is SMS or voice gets a blocking prompt at sign-in and has to register a passkey before carrying on. There's no skip button and no opt-out. Users with anything else registered, like Authenticator, don't get the prompt. 1 February 2027 is a Monday, so if you do nothing, that's the morning your service desk finds out how many users have nothing but a phone registered.

That last point has confused plenty of admins. When someone asked about it on Microsoft's Q&A forum in October, it took nearly three weeks and an updated FAQ to get a clear answer. Expect your users to need it explained before the day.

Registration can go wrong, too. Another admin posted in August that they'd followed every step (QR code scanned, Bluetooth on, PIN and fingerprint accepted) and still got "PassKey not registered", on both Android and iPhone, with no confirmed fix. Test registration on your own devices and app protection policies before your users find these problems for you.

If You Really Need to Keep SMS

You can keep it, but you'll be paying for it. It goes through a telephony provider you contract with yourself via Microsoft Security Store. Soprano and Telesign are the initial providers during the private preview, with more promised by general availability, and Microsoft says the configuration experience opens on 30 October 2026. Pricing comes from the provider and varies by region. Users you've migrated to a provider before their retirement date don't get the blocking prompt.

Microsoft pitches it at organisations with a genuine regulatory or operational need, not as a way to dodge the change, and I'd treat it the same way. Paying per message to keep the weakest method in your tenant only makes sense for a documented group of users who have nothing else that works. "The finance director doesn't like apps" isn't a regulatory requirement.

The Opt-Out Doesn't Do What You Might Think

There is a temporary opt-out, and it's the part I'd expect to be misread most. You set passkeyDynamicMigration to true in the authentication methods policy through Microsoft Graph. It needs the Policy.ReadWrite.AuthenticationMethod permission and, for now, the beta endpoint.

PATCH https://graph.microsoft.com/beta/policies/authenticationmethodspolicy
Content-Type: application/json

{
  "optOutSettings": {
    "passkeyDynamicMigration": true
  }
}

It only delays the automatic passkey enablement and registration campaign between September and February. From 1 February 2027, Microsoft says "standard passkey migration and enforcement timelines will apply regardless of this setting."

So it pauses Microsoft's nudges, not the deadline. A few months without the registration prompts is useful if you'd rather run your own rollout, but the February date doesn't move.

The Conditional Access Part

This is the part worth checking now rather than in February.

Conditional Access can require an authentication strength, not just "MFA". The built-in Phishing-resistant MFA strength allows Windows Hello for Business or platform credential, FIDO2 (which is the method passkeys belong to), and certificate-based authentication (multifactor). Passkeys meet it, and Microsoft's own passkey FAQ gives enforcing phishing-resistant MFA through an authentication strength as one of the reasons users get prompted to register one. SMS doesn't meet it, which won't surprise anyone. Neither do Authenticator codes, which might. Microsoft says TOTP "isn't phishing-resistant and doesn't satisfy a Conditional Access policy that requires phishing-resistant authentication."

Two things follow from that.

1. If you already require the phishing-resistant strength anywhere, users whose only methods are SMS or codes are failing that policy now. The 2027 date doesn't change that.
2. If you're moving people from SMS to codes to get past February, that works for the retirement, but it doesn't get you to phishing-resistant. You'll end up doing the migration twice, and asking users to change how they sign in twice in one year doesn't go down well.

If you're heading to passkeys anyway, this is a good time to get there in one move. The September change already put SMS and voice users into a passkey profile that allows every type of passkey, synced ones included. Microsoft's recommendation is device-bound passkeys (security keys or passkeys in Microsoft Authenticator) for admins and highly privileged users, and synced passkeys for everyone else. If you enforce attestation in a passkey profile, synced passkeys are excluded, so settle that before users start registering rather than after. The adversary-in-the-middle post covers the attack this closes off. A reverse proxy can relay a phishable MFA sign-in, but a passkey won't complete its ceremony through it.

If you'd rather check the built-in strengths yourself, Graph lists every method combination they allow.

GET https://graph.microsoft.com/beta/identity/conditionalAccess/authenticationStrength/policies?$filter=policyType eq 'builtIn'

Roll-Out Guide

Eight steps from now to the other side of the deadline. The timings are my suggestion, not Microsoft's.

The step 02 script

It reads the authentication methods registration report and lists users with a phone registered and nothing else that works for MFA, admins first. Email and security questions are ignored because they only count for password reset.

Connect-MgGraph -Scopes "AuditLog.Read.All"

$phone = 'mobilePhone', 'alternateMobilePhone', 'officePhone'

$phoneOnly = Get-MgReportAuthenticationMethodUserRegistrationDetail -All |
  Where-Object {
    $m = $_.MethodsRegistered
    # Has a phone, and nothing else apart from password-reset-only methods
    ($m | Where-Object { $_ -in $phone }) -and
    -not ($m | Where-Object { $_ -notin $phone -and $_ -ne 'email' -and $_ -notlike 'securityQuestion*' })
  }

$phoneOnly |
  Sort-Object @{ Expression = 'IsAdmin'; Descending = $true },
    @{ Expression = 'UserType'; Descending = $true }, UserPrincipalName |
  Select-Object UserPrincipalName, UserType, IsAdmin,
    @{ Name = 'Methods'; Expression = { $_.MethodsRegistered -join ', ' } } |
  Export-Csv .\phone-only-users.csv -NoTypeInformation

It needs AuditLog.Read.All, one of Reports Reader, Security Reader or Global Reader, and Entra ID P1 or P2. The report can be up to 36 hours behind.

The step 08 policy

Seeing It in One Place

The fiddly part is knowing which of your policies already require the phishing-resistant strength, and who they cover. AccessLens reads your policies (read-only) and shows each one's authentication strength next to who it covers, and its gap analysis flags admin roles that aren't held to phishing-resistant MFA. The change tracker follows this retirement too, dates included. I built it, so I'm biased. There's a demo mode if you want to poke around without connecting a tenant.

February sounds a long way off. Once you add a passkey rollout, user comms and a guest population nobody has looked at since the last audit, it isn't. Run the script this week and you'll know how much work you actually have.

Sources

• Microsoft Learn: Passkeys by default and retirement of Microsoft-provided SMS and voice authentication
• Microsoft Learn: FAQ for Microsoft-provided SMS and voice retirement
• Microsoft Learn: Choose a telephony provider for SMS and voice authentication
• Microsoft Learn: Overview of Conditional Access authentication strengths
• Microsoft Learn: Passkey FAQs
• Microsoft Learn: Passkeys (FIDO2) authentication method in Microsoft Entra ID
• Microsoft Graph: List userRegistrationDetails
• Microsoft Learn: Authentication Methods Activity
• Microsoft Learn: Configure a Temporary Access Pass
• GitHub: microsoft/entra-sms-voice-usage-analyzer
• Microsoft Q&A: Impact of SMS/Voice MFA Retirement (February 2027)
• Microsoft Q&A: Entra PassKey Registration Issue, PassKey Not Registered