Entra Is Retiring SMS and Voice MFA: Passkeys Are Already the Default and the Cutoff Is February 1, 2027
February 1, 2027 is the date Microsoft stops delivering SMS and voice call codes for Microsoft Entra multifactor authentication, for every user except Global Administrators and external users. Those two groups follow on July 1, 2027. The part that surprises people is that the change already started: since September 1, 2026, passkeys are the default and users who are enabled for SMS or voice are being nudged to register one at sign-in.
After the cutoff, a user whose only MFA method is SMS or voice cannot finish signing in until they register a passkey. Microsoft says plainly that this prompt is blocking and that there is no opt-out from it. This post gives you the dates, a script to find the people at risk, the one temporary opt-out that exists, and what I could and could not check from my own lab tenant.

Quick guide
- Find who still depends on SMS or voice. Use Microsoft’s analyzer script, or the Graph report below.
- Put those users in one security group. You will use it for the registration campaign and for messaging.
- Turn on a passkey registration campaign for that group so users register before the deadline.
- Decide who truly needs a phone channel and plan a telephony provider for them.
- Check again in January. Anyone with SMS or voice as their only method will be blocked on February 1.
The timeline
| Date | What happens |
|---|---|
| September 1, 2026 | Passkeys become the default. Users enabled for SMS or voice are auto-enabled for passkeys and nudged to register at the next MFA sign-in. The Registration Campaign is set to Microsoft Managed for passkeys. |
| October 30, 2026 | Customers who need to keep SMS or voice can pick and configure a telephony provider in Microsoft Security Store. Soprano and Telesign are the first providers, in private preview. |
| February 1, 2027 | Microsoft-provided SMS and voice retire for all users except Global Administrators and external users. Internal guest users stay on this date. A user with only SMS or voice must register a passkey to sign in. |
| July 1, 2027 | Same retirement for Global Administrators and external users. |
All of this comes from the Microsoft Learn page on the retirement, last updated September 23, 2026, and message center item MC1426371.
Step 1: find users who still use SMS or voice
Microsoft links its own PowerShell analyzer for this, and you need the Global Reader, Authentication Policy Administrator or Security Reader role to run it. Use it first, because it is the one Microsoft maintains.
If you want a quick list of your own, the Graph registration report has a methodsRegistered value per user. This read-only script keeps users who have a phone method and none of the stronger ones. I wrote it from the Graph documentation. I did not run it, because my lab tenant gives my app no directory permissions, as shown in the next section.
Connect-MgGraph -Scopes 'AuditLog.Read.All'
$strong = 'fido2|passKey|windowsHello|microsoftAuthenticator'
$atRisk = Get-MgReportAuthenticationMethodUserRegistrationDetail -All |
Where-Object {
$_.MethodsRegistered -contains 'mobilePhone' -and
-not ($_.MethodsRegistered -match $strong)
}
$atRisk | Select-Object UserPrincipalName, MethodsRegistered, IsMfaRegistered |
Export-Csv .\sms-only-users.csv -NoTypeInformation -Encoding UTF8
"{0} users have a phone method and no stronger method" -f @($atRisk).Count
Two warnings about that script. First, the strong-method pattern is my own guess at the names Graph uses, so check a few real values in your tenant before you trust the count. Second, a user with a phone and an authenticator app is not at risk of being blocked, only the phone-only users are. That is why the script excludes them.
What my lab tenant said when I tried
I tried the policy read and the registration report from my lab app. Both came back 403, and the access token had no application roles at all. This is the normal first wall for a scanner account, and it tells you which permissions to grant before the script can work.

To run the report you grant the app AuditLog.Read.All and have an admin consent to it. To read or change the authentication methods policy you need Policy.Read.All or Policy.ReadWrite.AuthenticationMethod. I did not grant any of them, because the lab tenant is for testing other things and I would rather show the wall honestly than fake a result.
Step 2: push users to register a passkey before the deadline
Microsoft’s most effective tool here is the registration campaign. In the Entra admin center, as an Authentication Policy Administrator, go to Entra ID, Authentication methods, Registration campaign. Set the state to Microsoft Managed and target the security group of your SMS and voice users. Before that, make sure Passkey (FIDO2) is enabled and that the group is covered by a passkey-enabled policy.
By default users can snooze the nudge without limit, so a campaign alone will not get everyone across. Pair it with a clear message from the help desk and a date. Microsoft publishes end-user message templates for this.
Step 3: the temporary opt-out, and what it does not do
There is one escape hatch. Between September 1, 2026 and February 1, 2027 you can opt the tenant out of the automatic passkey enablement and campaign. It needs the Policy.ReadWrite.AuthenticationMethod permission, and the call is a PATCH to the authentication methods policy on the beta endpoint. This is the request exactly as Microsoft documents it.
PATCH https://graph.microsoft.com/beta/policies/authenticationmethodspolicy
Content-Type: application/json
{
"optOutSettings": {
"passkeyDynamicMigration": true
}
}
Read the limits before you use it. It delays the automatic rollout. It does not delay the February 1 retirement, and Microsoft says there is no opt-out from the blocking passkey prompt after that date. It is also a beta endpoint. I did not send it, since my app has no permission and I would not change a policy just to take a screenshot. I also could not find out whether it undoes the enablement that already happened on September 1, so test it on a small tenant first.
Step 4: keep a phone channel only where you must
If a regulation or a real operational case needs SMS or voice, plan a telephony provider through Microsoft Security Store, available from October 30, 2026. Document the reason per user segment, then run a pilot before you roll it out. For everyone else, passkeys are the default Microsoft recommends. Passkeys can be synced ones in a platform credential manager or device-bound ones such as a hardware security key or the passkey in Microsoft Authenticator.
A rollout order that fits the calendar
- This week: run the analyzer and list the phone-only users with their managers.
- By mid-November: enable the campaign for that group and send the first message.
- December: chase the users who snoozed, and decide on a telephony provider for the exceptions.
- January: re-run the list. Every name still on it is someone who will be blocked on February 1.
FAQ
Does the February 1 date apply to Global Administrators?
No. Global Administrators and external users have until July 1, 2027. Internal guest users do not get the extra time and follow February 1.
Can I delay the retirement?
No. The opt-out only delays the automatic passkey enablement. Microsoft says there is no opt-out from the retirement itself.
What happens to a user who only has SMS after February 1?
They are required to register a passkey during sign-in before they can continue. The prompt is blocking.
Is the Microsoft Authenticator app affected?
The retirement is about Microsoft-provided SMS and voice delivery. Users who already use passkeys, Windows Hello for Business or another phishing-resistant method can keep using them.
Sources
- Passkeys by default and retirement of Microsoft-provided SMS and voice authentication, Microsoft Learn
- FAQ for Microsoft-provided SMS and voice retirement, Microsoft Learn
- MC1426371, Microsoft Entra passkeys by default and SMS and voice retirement
- Entra SMS and voice usage analyzer, Microsoft on GitHub
- Microsoft retiring Entra SMS authentication, Redmond Magazine
