Entra SMS and voice MFA retirement: move users to passkeys before 2027

Microsoft is retiring the SMS and voice call MFA it delivers itself in Microsoft Entra ID: on 1 February 2027 for all users except Global Administrators and external users, and on 1 July 2027 for those two groups. After their date, users whose only MFA method is SMS or voice must register a passkey during sign-in before they can continue, with no opt-out. To avoid a wave of blocked sign-ins and help desk calls, find the users who depend on phone methods now, move them to passkeys with a registration campaign, and then remove SMS and voice from your authentication policies.

Who this is for and what you will have at the end

This guide is for identity administrators in tenants where users still sign in or reset passwords with text messages or phone calls. That includes tenants that enabled SMS years ago as a fallback and never revisited it.

At the end you will have:

• A clear view of the timeline and which user groups it hits on which date.
• A list of users who depend on SMS or voice, produced with Microsoft Graph PowerShell.
• Passkeys enabled and a registration campaign moving those users.
• A plan for admins, guests, shared-device workers and password reset.
• SMS and voice removed from the Authentication methods policy and the legacy MFA and SSPR settings.

What changes and when

Points that matter when you scope the work:

• SSPR is in scope. The retirement applies across Microsoft Entra, including self-service password reset by text or call.
• External MFA is not. Users who complete MFA through an external authentication method provider aren't affected unless they are also enabled for SMS or voice.
• Other Microsoft methods continue. Users who already sign in with passkeys, Windows Hello for Business or another phishing-resistant method can keep using them.
• Public cloud only. Other clouds follow later. Azure AD B2C is out of scope, and Microsoft Entra External ID tenants get a separate announcement.
• The opt-out is temporary. Setting passkeyDynamicMigration to true delays the September 2026 automatic passkey enablement and campaign, but not the 2027 retirement.

Prerequisites

• Authentication Policy Administrator to change the Authentication methods policy, passkey settings and registration campaign.
• Reports Reader, Security Reader, Global Reader or Security Administrator to read registration details through Graph.
• Microsoft Entra ID P1 or P2 for the Usage and insights reports in Authentication methods activity. The registration details API used below points to the same licence requirements.
• The Microsoft Graph PowerShell SDK, with Microsoft.Graph.Reports for the user report.

Step 1: Find out who depends on SMS and voice

Use three views, because each answers a different question.

Which policies still allow SMS and voice

Microsoft publishes a read-only scanner, Get-SmsVoicePolicyUsers.ps1, in the microsoft/entra-sms-voice-usage-analyzer repository on GitHub. It reports the registration campaign state, the SMS and Voice policy state and targets, and your authentication methods migration state, and writes the policy targets to a CSV. It needs Global Reader, Authentication Policy Administrator or Security Reader.

.\Get-SmsVoicePolicyUsers.ps1 -TenantId "contoso.onmicrosoft.com"

It doesn't expand groups, count users or read registered methods, so treat it as a scope check, not a user list.

Which users have phone methods registered

The userRegistrationDetails report lists registered methods for every enabled user. This script finds users with a phone method and flags those with nothing else that can satisfy MFA:

Connect-MgGraph -Scopes 'AuditLog.Read.All'
 
$phoneMethods = @('mobilePhone', 'alternateMobilePhone', 'officePhone')
$notMfa       = @('email')
 
$all = Get-MgReportAuthenticationMethodUserRegistrationDetail -All
 
$report = foreach ($u in $all) {
    $methods = @($u.MethodsRegistered)
    $phone   = @($methods | Where-Object { $_ -in $phoneMethods })
    if ($phone.Count -eq 0) { continue }
 
    $other = @($methods | Where-Object { $_ -notin ($phoneMethods + $notMfa) })
 
    [pscustomobject]@{
        UserPrincipalName = $u.UserPrincipalName
        UserType          = $u.UserType
        IsAdmin           = $u.IsAdmin
        PhoneOnly         = ($other.Count -eq 0)
        PreferredMethod   = $u.UserPreferredMethodForSecondaryAuthentication
        Methods           = ($methods -join ';')
    }
}
 
$report | Export-Csv .\phone-mfa-users.csv -NoTypeInformation
$report | Group-Object PhoneOnly, IsAdmin, UserType | Select-Object Count, Name

PhoneOnly users are the ones who will hit the blocking prompt. PreferredMethod values sms, voiceMobile, voiceAlternateMobile and voiceOffice show users who default to a phone method even though they have alternatives. The report skips disabled and soft-deleted users and can lag by up to 36 hours.

The script treats every registered method other than phone and email as an alternative, which overstates readiness for users whose only other method can't satisfy MFA, such as security questions. Before you rely on PhoneOnly, list the distinct values in the Methods column of your export, add any that can't be used for MFA to $notMfa, and rerun. The alternateMobilePhone and officePhone names follow the values Graph uses for default MFA methods; check a few users against their Authentication methods page in the portal as well.

Put the PhoneOnly users in a security group, for example SMS-Voice-Migration. You will target it with the campaign and your communications.

Who actually uses them

In the Microsoft Entra admin center, go to Entra ID > Authentication methods > Activity. The Registration tab shows users registered by method, and the Usage tab shows sign-ins and password resets by method. A drop in SMS and voice usage is your progress metric.

Step 2: Choose the target method for each group

Microsoft recommends passkeys as the primary migration path and documents recommended credentials by persona:

Passkeys are available in all Microsoft Entra ID editions, including Free, at no extra cost. Devices need current operating systems: Microsoft lists iOS 17, Android 14, macOS 13 and Windows 10 22H2 or Windows 11 22H2 as minimums for native passkey support. Users on older phones need a security key.

When a telephony provider makes sense

If a regulation or a scenario genuinely requires an out-of-band SMS or call, Microsoft Security Store offers contracted telephony providers. Soprano and Telesign are the private-preview providers, more are expected by general availability, and pricing depends on provider, region and usage. Limit this to the documented user segments that need it, test with a pilot group, and finish setup well before the retirement date. Users you move to a configured provider don't get the blocking passkey prompt.

Step 3: Enable passkeys and run the registration campaign

The full configuration, including passkey profiles and Windows Hello, is in the passkey deployment guide. The minimum for this migration:

1. Go to Entra ID > Authentication methods > Policies and select Passkey (FIDO2).
2. On Configure, set Allow self-service set up to Yes; without it, users can't register passkeys in Security info.
3. Make sure the passkey profile that applies to your migration group allows the passkey types you chose. A profile with attestation enforced blocks synced passkeys.
4. On Enable and target, include the migration group.

Then configure the campaign under Entra ID > Authentication methods > Registration campaign:

Since 1 September 2026 your campaign is probably already Microsoft managed, which nudges but never forces. To make registration mandatory before the deadline, switch to Enabled, target Passkey, include the migration group, and turn on Limited number of snoozes. Users are prompted after they complete MFA, so phone-only users can still get through the first sign-in with SMS and register a passkey in the same session.

Users with no usable method

New hires, users who lost their phone, and people without any registered method need a Temporary Access Pass. Enable the Temporary Access Pass method for the relevant group, then issue a pass from the user's Authentication methods page or with PowerShell:

$properties = @{}
$properties.isUsableOnce = $true
$propertiesJSON = $properties | ConvertTo-Json
 
New-MgUserAuthenticationTemporaryAccessPassMethod -UserId adele@contoso.com -BodyParameter $propertiesJSON

By default a pass is valid for one hour, and the policy's maximum lifetime is eight hours; both are configurable. With a one-time pass, the user must finish registering the passkey within 10 minutes of signing in.

The temporary opt-out

If you need time before automatic passkey enablement touches your users, for example while a telephony provider is set up, Microsoft documents a Graph beta request that needs Policy.ReadWrite.AuthenticationMethod:

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

Send it as PATCH https://graph.microsoft.com/beta/policies/authenticationmethodspolicy. It only delays the automatic changes; the February and July 2027 retirements still apply.

Step 4: Handle the special groups

Global Administrators. Their retirement date is later, but they are the accounts attackers want most. Move admins to FIDO2 security keys first, not last. Emergency access accounts should already use passkeys or certificate-based authentication to satisfy mandatory MFA.

External users and guests. External users follow 1 July 2027. Internal guest accounts (UserType Guest with methods registered in your tenant) follow 1 February 2027. Passkey registration isn't currently supported for guest users; Microsoft plans passkey support for B2B and internal guests by the end of 2026, and passkey registration campaigns don't nudge guests. Track this population separately and re-check the documentation before each date.

Shared-device and frontline workers. Windows Hello for Business supports up to 10 users per device and isn't suitable for shared kiosk accounts. Give these users FIDO2 security keys or Microsoft Entra passkey on Windows.

Password reset. Users who reset passwords by text need another SSPR method. Check the SSPR Capable column in the registration details report after you remove phone methods.

Step 5: Communicate with users

Microsoft recommends a three-stage plan aligned to the dates: awareness (what is retiring and why), action (how to register a passkey on their device) and reminders for those who haven't. Scope messages to the migration group so the right people hear them, and use Microsoft's templates at https://aka.ms/mfatemplates. Tell the help desk in advance what the blocking prompt looks like and how to issue a Temporary Access Pass.

Step 6: Remove SMS and voice from every policy

Once usage has dropped, take phone methods out so nobody registers them again. Settings aren't synchronized between policies, and a user enabled for a method in any policy can still use it, so two changes are needed:

1. Authentication methods policy: Entra ID > Authentication methods > Policies. Disable SMS and Voice call, or narrow their targets to the users served by a telephony provider.
2. Legacy policies: the legacy MFA settings (Additional cloud-based multifactor authentication settings) and the legacy SSPR methods (Entra ID > Password reset > Authentication methods) can still allow calls and texts, and since 30 September 2025 methods can't be managed there any more. Open Manage migration on the Authentication methods policy page and select Migration Complete, so only the Authentication methods policy is used for sign-in and password reset and legacy settings are ignored.

Before you complete the migration, enable every method you still want in the Authentication methods policy. Security questions can only be enabled in the legacy SSPR policy, so keep them there if you use them.

Verify

• Rerun the PowerShell report: the PhoneOnly count should trend to zero before 1 February 2027, with admins and external users done well before 1 July 2027.
• Rerun Microsoft's scanner and confirm the SMS and Voice policy state and that the migration state is migrationComplete.
• In Authentication methods > Activity > Usage, sign-ins and password resets by SMS and voice should fall away.
• Spot-check users in the portal: passkey listed under Authentication methods and MFA Capable in the registration details.

Troubleshooting

Users still get texts after you disabled SMS in the Authentication methods policy. They're enabled through the legacy MFA policy or Mobile phone in the legacy SSPR policy, which also permits voice calls for reset. Set the migration state to Migration Complete so the legacy settings are ignored.

Users aren't nudged to register a passkey. Common causes: a Conditional Access policy blocks access to Register security information where they are; they signed in with SSO and didn't perform MFA; they already have a local passkey for that OS and browser; they're on Linux; or they're guests. In the Microsoft managed state, users are only nudged if they're in at least one eligible passkey profile.

Passkey registration fails or loops in Authenticator. A Conditional Access policy requiring phishing-resistant MFA for All resources also applies to Authenticator itself. Target specific applications with a filter, or use separate mobile and desktop policies with a Temporary Access Pass allowed on mobile. Registration also fails if a policy requires approved client apps or app protection policies, which Authenticator doesn't support.

Registration fails because of recent MFA. Users must have completed MFA within the past five minutes to register a passkey. Ask them to sign out and back in to Security info.

Temporary Access Pass sign in was blocked due to User Credential Policy. The user isn't in the TAP policy scope, the one-time pass was already used, or the pass is multi-use while the policy requires one-time use.

You can't save changes to the Authentication methods policy. The policy is limited to 20 KB. Consolidate the groups you target into fewer groups.

Checklist

• Timeline understood: 1 February 2027 for most users and internal guests, 1 July 2027 for Global Administrators and external users.
• Scanner run and policy scope recorded.
• Phone-dependent users exported and placed in a migration group.
• Passkeys enabled with Allow self-service set up on and a suitable passkey profile.
• Registration campaign set to Enabled for passkeys with limited snoozes for the migration group.
• Temporary Access Pass enabled for recovery and onboarding.
• Admins on security keys; guests and shared-device users tracked separately.
• SSPR methods replaced for users who reset by phone.
• SMS and Voice disabled in the Authentication methods policy; migration set to Migration Complete.
• Telephony provider configured only where a documented requirement exists.

The same work fits into a broader hardening effort, covered in a Microsoft 365 tenant security baseline you can apply in a day.

References

• Passkeys by default and retirement of Microsoft-provided SMS and voice authentication
• FAQ for Microsoft-provided SMS and voice retirement
• Entra SMS/Voice usage analyzer (GitHub)
• userRegistrationDetails resource type
• List userRegistrationDetails
• Get-MgReportAuthenticationMethodUserRegistrationDetail
• Authentication methods activity
• Manage authentication methods
• Run a registration campaign to set up a passkey or Microsoft Authenticator
• Plan a phishing-resistant passwordless authentication deployment
• Enable passkeys (FIDO2) in Microsoft Entra ID
• Configure a Temporary Access Pass
• Enable and support passkeys in Authenticator