Microsoft is retiring its own SMS and voice delivery for multifactor authentication in Entra ID. From 1 February 2027, any user whose only MFA method is a text message or phone call will hit a blocking prompt to register a passkey before they can sign in, and there is no opt-out. Global Administrators and external users get until 1 July 2027. Self-service password reset (SSPR) loses Microsoft-provided SMS and voice on the same schedule.
That leaves roughly twelve weeks from the time of writing (6 November 2026), with the holiday period in the middle. This guide is the plan I’d follow for a small or mid-size Microsoft 365 tenant: find the people who are actually exposed (the official script won’t tell you), move them to passkeys or Authenticator, fix the SSPR gap most guides skip, check VPN and Conditional Access, and only then switch SMS off yourself. There’s a PowerShell report and a week-by-week checklist below.
What is changing, and when
The details come from Microsoft’s passkeys by default and SMS/voice retirement article, its FAQ (updated 4 November 2026), and two Message Center posts: MC1426371 (the main announcement) and MC1536049 (the SSPR follow-up, published 3 November 2026).
| Date | What happens |
|---|---|
| 1 Sep 2026 | Users enabled for SMS or voice were auto-enabled for passkeys, and the registration campaign was switched to Microsoft managed. Users get a snoozable passkey nudge after MFA. |
| 30 Oct 2026 | Customer-managed telephony (Microsoft calls it CYOT, “choose your own telephony”) became configurable through Microsoft Security Store. |
| ~4 Jan 2027 | Microsoft recommends finishing any telephony provider setup at least four weeks before 1 February (per MC1426371). |
| 1 Feb 2027 | Microsoft-provided SMS and voice retired for everyone except Global Administrators and external users. Internal guests are in this group. SSPR starts a 50-day transition per user group as the rollout reaches your tenant. |
| 1 Jul 2027 | Same retirement for users with an active Global Administrator role and for external users. |
A few details matter more than they look:
- PIM-eligible Global Admins are regular users. The FAQ is explicit: if you’re only eligible for Global Administrator through PIM and haven’t activated it, the 1 February date applies to you. The July date only covers the role while it’s active.
- The temporary opt-out only delays the nudges. Setting
passkeyDynamicMigrationtotruepauses the automatic passkey enablement and registration campaign until 1 February. It does nothing to the retirement itself. - TOTP codes survive. Authenticator verification codes and other OATH TOTP apps keep working after 1 February, and users who have one registered won’t get the blocking prompt. They’re not phishing-resistant, but they’re a valid fallback.
- Passkeys don’t satisfy SSPR. MC1536049 says so directly. A user who moves from SMS to a passkey alone can sign in fine and still be unable to reset a forgotten password.
- Scope: public cloud including GCC. Azure AD B2C is out of scope, and Entra External ID tenants get a separate announcement.
Microsoft’s stated reason is partly AI adoption: phishable methods are a weak base when agents and copilots act with a user’s identity. I agree with the direction. I wrote about the identity side of that problem in the hidden security issues with AI agents.
Step 1: Find who depends on SMS or voice
Microsoft points you to a script, Get-SmsVoicePolicyUsers.ps1. Run it, but understand what it does: it reads your SMS and Voice policy scope (which groups are targeted, registration campaign state, migration state). It doesn’t expand groups, look at registered methods, or read sign-in logs. If SMS is enabled for “All users”, it tells you that and nothing more.
What you actually need is a list of people, split into three buckets:
- Phone-only MFA: they’ll get the blocking passkey prompt on 1 February.
- Phone-dependent SSPR: they can sign in with something else but can’t reset a password without SMS or voice.
- Admins and guests: different dates, different constraints.
The userRegistrationDetails report in Microsoft Graph has everything needed. You need the AuditLog.Read.All scope and a role such as Reports Reader, Security Reader or Global Reader. Microsoft documents an Entra ID P1 or P2 requirement for the authentication methods reports, which Business Premium includes.
Install-Module Microsoft.Graph.Reports -Scope CurrentUser
Connect-MgGraph -Scopes "AuditLog.Read.All" -NoWelcome
$phone = 'mobilePhone','alternateMobilePhone','officePhone'
$notMfa = 'email','securityQuestion','temporaryAccessPass'
$ssprSafe = 'email','microsoftAuthenticatorPush','softwareOneTimePasscode','hardwareOneTimePasscode'
$report = Get-MgReportAuthenticationMethodUserRegistrationDetail -All
$results = foreach ($u in $report) {
$m = @($u.MethodsRegistered)
if (-not ($m | Where-Object { $_ -in $phone })) { continue }
$otherMfa = @($m | Where-Object { $_ -notin ($phone + $notMfa) })
$ssprLeft = @($m | Where-Object { $_ -in $ssprSafe })
[pscustomobject]@{
UPN = $u.UserPrincipalName
UserType = $u.UserType
IsAdmin = $u.IsAdmin
PhoneOnlyMfa = ($otherMfa.Count -eq 0)
SsprAtRisk = ($u.IsSsprEnabled -and $ssprLeft.Count -eq 0)
DefaultMethod = $u.UserPreferredMethodForSecondaryAuthentication
Methods = ($m -join ';')
}
}
$results | Sort-Object PhoneOnlyMfa, SsprAtRisk -Descending |
Export-Csv .\sms-voice-exposure.csv -NoTypeInformation -Encoding UTF8
$results | Group-Object PhoneOnlyMfa | Select-Object Name, CountWhat you should see: a CSV with one row per user who has any phone method registered, and a small summary such as True 14 / False 61 for the phone-only split. Check the Methods column against a few users you know. The method strings above come from Microsoft’s examples (mobilePhone, microsoftAuthenticatorPush, softwareOneTimePasscode, email), but Microsoft doesn’t publish an exhaustive list, so confirm anything unusual in your own output before you trust the flags.
Three caveats. The report can lag by up to 36 hours. Disabled users aren’t included. And SsprAtRisk is a rough check: it ignores the admin two-gate rule and your policy’s method count, which I cover below.
Also worth checking: DefaultMethod. People with Authenticator registered but SMS set as their default (sms or voiceMobile) aren’t blocked, but they’re used to typing a texted code. Tell them in advance, or they’ll call the helpdesk when the text stops coming.
The same data is in the portal under Entra ID > Authentication methods > Activity > Registration (at the time of writing), with a User registration details list you can filter by method. Fine for a quick look. The script is easier to repeat each week and compare.
Step 2: Decide what each group moves to
| Who | Move to | Why |
|---|---|---|
| Staff with a company or personal smartphone | Passkey in Microsoft Authenticator, plus Authenticator push/code | Phishing-resistant sign-in, and Authenticator still counts for SSPR |
| Mac/iPhone or Android-heavy users | Synced passkey (iCloud Keychain, Google Password Manager) if your passkey profile allows synced | Least friction, but no attestation |
| Admins, finance, anyone with privileged access | Device-bound passkey on a FIDO2 security key, attestation enforced | Strongest option, survives phone loss |
| Users who refuse or can’t use a smartphone app | FIDO2 security key, or hardware OATH token | No phone dependency |
| Regions where mobile passkeys are unreliable (Microsoft calls out Android in China) | FIDO2 key or TOTP codes | Microsoft’s own FAQ suggests both |
| Genuine regulatory need for SMS | Customer-managed telephony (CYOT) | Only where documented; it costs money and you run it |
Passkeys are included in every Entra ID edition, including Free, at no extra cost. Security keys are the only hardware spend. For a company of under 100 people, a pair of keys for each admin plus a small pool for the no-smartphone crowd is usually all you need.
Step 3: Configure passkeys deliberately
If you did nothing in September, Microsoft already turned passkeys on for your SMS and voice users with a profile that allows every passkey type. That works, but I’d rather set it up on purpose. Following Microsoft’s passkey guide:
- Go to Entra ID > Authentication methods > Policies > Passkey (FIDO2) as an Authentication Policy Administrator. Opt in to passkey profiles from the banner. You can’t opt out afterwards, and your current settings become the Default passkey profile.
- On Configure, make sure Allow self-service set up is Yes. If it’s No, users can’t register in Security info even when passkeys are enabled.
- Create two profiles (you get up to three including the default): one for admins with Passkey types = Device-bound and Enforce attestation = Yes, and one for everyone else allowing Device-bound and Synced.
- Under Enable and Target, assign the admin profile to an admin group and the general profile to All users.
- Under Authentication methods > Registration campaign, keep it Microsoft managed or set it to Enabled, targeting the SMS/voice users from step 1. While you’re there, consider limiting snoozes so it isn’t dismissed forever.
Two practical points. Users must have completed MFA in the last five minutes to register a passkey, so for new starters, people who lost their phone, or anyone who only had SMS, issue a Temporary Access Pass and let them register with that. And if a profile allows both passkey types and targets Authenticator, users need at least Authenticator 6.8.37 on iOS or 6.2507.4749 on Android. Push an app update through Intune before the campaign, not after.
Step 4: Close the SSPR gap
This is the part most guides miss, and the one that will fill your ticket queue in March.
The methods that count for SSPR are Authenticator push, software and hardware OATH tokens, SMS, voice and email OTP (security questions are also an option, though reportedly retiring as well). Remove SMS and voice and you’re left with Authenticator/OATH and email. Microsoft’s SSPR deep dive adds a catch: Authenticator, software OATH and hardware OATH together count as one method. So:
- Policy requires one method: Authenticator or an alternate email is enough.
- Policy requires two methods: each user needs Authenticator (or OATH) and email. If they had Authenticator plus SMS, they drop to one method and can’t reset.
- Admins: a fixed two-gate policy applies to every admin role, including Helpdesk, Exchange, Intune and User Administrators. It needs two pieces of authentication data and prohibits security questions. With phone gone, that’s effectively Authenticator plus email for every admin account.
The email for SSPR should be something the user can read while locked out of Microsoft 365, usually a personal address. Their work mailbox is useless when they’ve forgotten the password that opens it.
Separately, Microsoft is also ending SSPR’s use of unregistered directory attributes (the mobilePhone, businessPhones and otherMails values you or Entra Connect populated) under MC1325414. The Message Center post last said early November 2026. The Learn page on prepopulating SSPR contact data, updated 5 November, now says February 2027. Either way, the fix is the same: an email typed into a user’s profile no longer counts unless they registered it. Make sure people register it themselves in Security info.
There’s a newer option for passwordless users: Allow password change after secure sign-in. Once a user signs in with a passkey, certificate-based authentication or Authenticator passwordless sign-in, they can set a new password in Security info without knowing the old one. It’s separate from SSPR, applies tenant-wide (no group targeting), needs P1 or P2, and is under Entra ID > Authentication methods > Policies > Password > Configure. Microsoft says rollout runs from late October to the end of November 2026, so it may not be in your tenant yet. It doesn’t replace SSPR for someone who has lost their passkey device, but it covers the common “I forgot the password I never use” case.
Step 5: Check the things that aren’t the browser
VPN and RADIUS through the NPS extension
If your FortiGate, Cisco or other VPN uses RADIUS with the Entra MFA NPS extension, look at it before anything else. The NPS extension sends the user’s default method. Passkeys can’t travel over RADIUS, so a user who moves from SMS to passkey-only will start failing VPN logins. Microsoft’s retirement pages don’t mention the NPS extension specifically, so I’m working from how RADIUS behaves rather than from a statement. VPN users need Authenticator push or a TOTP code registered and, ideally, set as their default. If you’re replacing the VPN with SAML or Entra-integrated sign-in anyway, this is a good reason to bring it forward.
Conditional Access and authentication strengths
Open Authentication methods > Authentication strengths and look at any custom strengths that include “Password + SMS” or “Password + Voice”. After retirement those combinations can’t be satisfied with Microsoft delivery, so a policy that relies on them for a particular group or app can quietly block access. When the migration is done, this is also a good time to add a policy requiring the built-in Phishing-resistant MFA strength for admin roles.
Break-glass accounts
If an emergency access account still has a phone number as its only MFA method, fix it now with FIDO2 keys stored separately. Don’t wait for the July Global Admin date; an account that’s never used is exactly the one you’ll discover broken on the day you need it.
Guests
Internal guests follow 1 February; external (B2B) users follow 1 July. Passkey registration isn’t supported for guests at the time of writing, and Microsoft says B2B passkey support is planned by the end of 2026. For B2B users from another Entra tenant, the cleanest answer is a cross-tenant access setting that trusts MFA from their home tenant, so their own organisation’s methods apply.
Step 6: Only if you must keep SMS: customer-managed telephony
CYOT keeps SMS and voice working by routing delivery through a provider you contract with. Entra still generates and checks the code. In between sits an Azure Function deployed in your subscription. At the time of writing, the Security Store lists Soprano, Telesign and Infobip.
Be honest about what that means: a telecom bill, Azure hosting costs, fraud controls you configure (SMS pumping is real), and a function that becomes part of your sign-in path. If it goes down, so does SMS MFA. If you go this way, monitor the endpoint like any other production service (my Uptime Kuma setup is one cheap option), document the regulatory reason, and scope it to the smallest group you can. Microsoft’s guided setup lets you evaluate while Microsoft still delivers messages, then shift traffic gradually. Aim to finish by early January.
The 12-week SMS and voice MFA retirement checklist
Dates assume you start the week of 9 November 2026. Shift them if you’re starting later, but keep the order.
Weeks 1-2 (9-22 November): inventory and decisions
- Run Get-SmsVoicePolicyUsers.ps1 and the registration report above; save both CSVs as your baseline.
- Check whether you set the
passkeyDynamicMigrationopt-out, and whether you still want it. - List break-glass accounts, PIM-eligible Global Admins, guests and VPN/RADIUS users.
- Decide the target method per group (table in step 2). Order security keys now; delivery can be slow before the holidays.
- Decide yes or no on CYOT, with a written reason if yes.
Weeks 3-5 (23 November – 13 December): configure and pilot
- Enable passkey profiles, create admin and general profiles, target groups.
- Push the current Authenticator app via Intune.
- Enroll IT and admins first, including break-glass keys. Test sign-in from Windows, macOS, iOS and Android.
- Review the SSPR policy: methods enabled, number required. Have every admin register Authenticator plus a personal email.
- Test VPN sign-in for a user with no SMS method.
- Enable Allow password change after secure sign-in if it has reached your tenant.
Weeks 6-9 (14 December – 10 January): roll out to everyone
- Send the awareness email (Microsoft has templates), then the action email with device-specific steps.
- Turn on the registration campaign for the SMS/voice group with limited snoozes.
- Run walk-up or Teams “passkey clinics”, one per office or time zone if you’re multi-country.
- Hand out security keys and TAPs to the no-smartphone group.
- If using CYOT, finish setup and evaluation by about 4 January.
- Rerun the report weekly and chase the names that haven’t moved.
Weeks 10-12 (11-31 January): cut over on your terms
- Remove migrated users from the SMS and Voice call method policies (or exclude a “migrated” group). This stops the nudges and proves they can live without it.
- Fix any custom authentication strengths that still rely on SMS or voice.
- Brief the helpdesk: what the blocking prompt looks like, how to issue a TAP, how to verify identity before doing so.
- Final reminder to anyone still showing
PhoneOnlyMfa = True. - Put 1 July 2027 in the calendar for Global Admins and external users.
How to verify you’re ready
- The registration report returns zero rows with
PhoneOnlyMfa = True, except users you’ve deliberately put on CYOT. SsprAtRiskis zero, and a test non-admin user with no phone method can complete a reset at aka.ms/sspr. Test as a non-admin; admins get the two-gate policy, so your own account isn’t a fair test.- In sign-in logs, filter on authentication details for the last week and confirm SMS and voice usage is trending to zero.
- A pilot user excluded from the SMS and Voice policies can sign in to Microsoft 365, the VPN and every SAML app you care about.
- Break-glass accounts sign in with their keys. Test it, log it, store the keys again.
To confirm the SMS method policy state from PowerShell (needs Policy.Read.All):
Connect-MgGraph -Scopes "Policy.Read.All" -NoWelcome
'Sms','Voice','Fido2' | ForEach-Object {
Get-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
-AuthenticationMethodConfigurationId $_ |
Select-Object Id, State
}Common problems
“I don’t see the passkey prompt.” The campaign only fires after an MFA sign-in, and users can snooze it. Check the user is in the campaign’s target group and the Passkey (FIDO2) policy, and that Allow self-service set up is Yes.
Passkey registration fails with an attestation error. The user is in a profile with attestation enforced and is trying a synced passkey or an unlisted key. Either move them to the general profile or give them an approved device-bound option.
User has a passkey but SSPR says “contact your administrator”. Expected: passkeys don’t count for SSPR. Add Authenticator or a registered email, or enable password change after secure sign-in.
Report numbers don’t match what users just did. Up to 36 hours of lag. Rerun the next day before chasing anyone.
Passkey stopped working after a UPN change. It’s a known limitation. The user deletes the old passkey in Security info and registers a new one.
VPN logins fail but web sign-in works. The NPS extension is trying a method the user no longer has. Register Authenticator push or a TOTP code and make it their default.
Next steps
Once SMS is gone, the obvious next move is a Conditional Access policy requiring phishing-resistant MFA for admins, then for everyone on the apps that matter most. If you’re still running a mix of on-premises directory and Entra ID and wondering where identity should live long-term, my FreeIPA vs Active Directory comparison covers the on-prem side of that decision.
Dates in this area have moved several times this year, so check the Learn pages below before you commit to a cutover day.
Sources and further reading
- 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: How to enable passkeys (FIDO2) in Microsoft Entra ID
- Microsoft Learn: Self-service password reset deep dive
- Microsoft Learn: SSPR policies (administrator two-gate policy)
- Microsoft Learn: Choose your own telephony provider
- Microsoft Graph: List userRegistrationDetails
- GitHub: microsoft/entra-sms-voice-usage-analyzer
- MC1426371: Passkeys by default and SMS/voice retirement and MC1536049: SMS and voice retirement for SSPR
Comments
No comments yet. If something here helped or didn’t work for you, say so below.