Microsoft 365 SMS and Voice MFA Retirement: Passkey Changes Explained

What Microsoft is changing, and when

This applies to Microsoft Entra ID workforce tenants in the public cloud (Worldwide and GCC), which is where Microsoft 365 sign-in lives. Microsoft's reasoning is that SMS and voice codes can be phished, intercepted or redirected through a SIM swap, where an attacker gets a victim's phone number moved to a SIM they control. Passkeys avoid that because nothing secret is typed or sent over the phone network.

There are two moving parts. The first has already started: passkeys became the default experience from 1 September 2026, rolling out gradually. Users enabled for SMS or voice in the authentication methods policy (or in legacy MFA settings) were enabled for passkeys, and the registration campaign was set to Microsoft managed, targeting passkeys. At their next sign-in with MFA, those users are nudged to register one. By default they can snooze that nudge as often as they like. The second part is the retirement of Microsoft-delivered SMS and voice, which is what eventually forces the issue.

Microsoft revised the original announcement once (MC1426371, version 2 on 15 September 2026) and has since posted a reminder, so treat dates as current to 9 November 2026 and re-check before acting on them.

• 13 July 2026: change announced in the Microsoft 365 Message Center (MC1426371).
• From 1 September 2026: passkeys become the default. SMS and voice users are auto-enabled for passkeys and nudged to register. Rollout is gradual, so your tenant may or may not have changed yet.
• From 30 October 2026: tenants that need SMS or voice can configure a customer-managed telephony provider through Microsoft Security Store.
• 1 February 2027: Microsoft-provided SMS and voice retire for everyone except Global Administrators and external users. This includes internal guest users and self-service password reset. Microsoft expects the rollout to finish in early February 2027.
• 1 July 2027: Microsoft-provided SMS and voice retire for Global Administrators and external users.

Are passkeys mandatory?

Not as a blanket rule. Nothing in Microsoft's published plan says every user must sign in with a passkey. People already using Microsoft Authenticator, Windows Hello for Business or a security key are not asked to change, and Microsoft's reminder says users with another registered sign-in method keep using it.

What is mandatory is narrower. After the applicable date, a user whose only available MFA method is Microsoft-delivered SMS or voice gets a blocking prompt: register a passkey before you can sign in. Microsoft states there is no opt-out from that enforcement, and the temporary opt-out described later does not change it. So passkeys are the preferred method for everyone and the compulsory fallback for phone-only users, unless you pay for a telephony provider or those users move to another method first.

Microsoft's timeline also advises getting users onto a phishing-resistant method (passkey, Windows Hello for Business or FIDO2 security key) before the date to avoid disruption. We read that as the recommended target rather than a rule that bans other registered methods, but the wording is firmer than the reminder post, so plan accordingly.

Passkeys, MFA enforcement and retiring a method are three separate things

These get blurred together in conversation, and mixing them up leads to wrong conclusions such as 'we already enforce MFA, so we're fine'.

• A passkey is one sign-in method. It can satisfy MFA on its own because it combines the device with a fingerprint, face or PIN. Making passkeys the default is about which method users are steered towards.
• MFA enforcement decides whether a second step is required at all. For most users that is your Conditional Access policy or security defaults. Separately, Microsoft already requires MFA for the Azure portal, Microsoft Entra admin centre, Intune admin centre and Microsoft 365 admin centre, and any accepted method satisfies it. That requirement does not name SMS or passkeys.
• Method retirement is Microsoft ceasing to deliver one particular method. It does not switch MFA on or off. It changes which methods are still available to meet an MFA requirement you already have.

Who is affected

You are in scope if any users are enabled for Microsoft-provided SMS or voice, whether for MFA or self-service password reset (SSPR). If you do not use either, Microsoft's reminder says no action is needed. The people most likely to be caught out are those who set up phone MFA at the start and never added an app, plus any administrator or emergency access account still using a phone number. That last point is our judgement rather than a Microsoft statement.

• Regular users and internal guests: 1 February 2027.
• Global Administrators and external users: 1 July 2027. The later date applies only while the Global Administrator role is active. Someone who is merely eligible through Privileged Identity Management is treated as a regular user and follows 1 February.
• Users who also have another method registered: no passkey prompt. Authenticator verification codes (TOTP) remain supported after 1 February 2027, and users registered for them do not get the blocking prompt.
• Not in scope: Azure AD B2C. Microsoft Entra External ID follows later with its own announcement. External MFA methods are unaffected unless the same users are also enabled for SMS or voice. Other cloud environments follow a later schedule.
• Guests deserve a second look. Internal guests are in the February group, yet Microsoft's passkey documentation lists passkey registration for guest users as unsupported, with B2B and internal guest support planned by the end of calendar 2026. Check where that stands before February if you have guests who rely on SMS.

What to check in Microsoft Entra now

These checks are read-only. They need at least Authentication Policy Administrator rights, or Global Reader or Security Reader for viewing only. Work in this order, because the first two tell you whether Microsoft's September rollout has already touched your tenant.

1. Sign in to the Microsoft Entra admin centre and go to Entra ID, then Authentication methods, then Policies. Open SMS and Voice call and note who is enabled and which groups are excluded. Then open Passkey (FIDO2) and check whether it is now enabled for those same users, whether passkey profiles have been switched on (Microsoft says that opt-in cannot be undone) and whether attestation is enforced. If attestation is on, only device-bound passkeys are allowed, so staff relying on iCloud Keychain or Google Password Manager passkeys would be excluded.
2. Open Registration campaign under Authentication methods. See whether the state is Microsoft managed and which users or groups it targets. In that state users get one prompt per day, with unlimited snoozes by default, and only users in an eligible passkey profile are nudged.
3. Run Microsoft's scanner for a tenant-wide view of policy scope. It is described by Microsoft as read-only and requests only Policy.Read.All and Group.Read.All through the Microsoft Graph PowerShell modules. Download Get-SmsVoicePolicyUsers.ps1 from Microsoft's entra-sms-voice-usage-analyzer repository, read it, then run it from a PowerShell session. Replace YOUR_TENANT_NAME with your own domain. It writes a CSV of policy targets, but it does not list individual users, expand group membership or read sign-in activity, so an AllUsers row means everyone is targeted rather than naming anyone.
   powershellCopy

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

4. To find the actual people, go to Authentication methods, then Activity, then the Registration tab, and open the user registration details. Look for users whose registered methods are only phone-based (mobile phone, alternate mobile phone or office phone) with no Authenticator app, FIDO2 security key, Windows Hello for Business or software or hardware OATH token. This report needs Microsoft Entra ID P1 or P2, can lag by up to 36 hours and does not list disabled users, so treat it as a close picture rather than a signed-off inventory. Add those users to a security group; you will use it for the campaign and for communications.
5. Check your Conditional Access policies and authentication strengths. If any policy demands a phishing-resistant strength, TOTP codes will not satisfy it, so moving users to the Authenticator code route will not be enough for them. Also look at who holds Global Administrator and which methods each of those accounts uses, including emergency access accounts. Microsoft recommends a passkey (FIDO2) or certificate-based authentication for break-glass accounts.

Preparing users without disrupting access

The default Microsoft managed campaign is gentle to the point of being easy to ignore. Unlimited snoozes mean it will not finish the migration for you. If you want a firm timetable, switch the campaign to Enabled, target the phone-only group and choose the snooze settings yourself: Days allowed to snooze can be 0 to 14, and with Limited number of snoozes on, users can skip three times before registration is required. Only one method can be targeted at a time, so the campaign can nudge to passkeys or to Authenticator, not both.

Sequence matters more than speed. A passkey registration needs MFA within the previous five minutes, so phone-only users can register comfortably while their SMS or voice code still works. After the retirement date the same user meets a blocking prompt at sign-in instead of a friendly nudge. Far better that they register on a quiet Tuesday than at 8.55am on 2 February.

• Start with a pilot group covering the devices you actually have: Windows, iPhone, Android and any shared or older machines. The passkey nudge checks each device and browser combination, so someone can be prompted on a laptop even though they registered on their phone. Linux users are not nudged at all.
• Pick the passkey type deliberately. Synced passkeys (iCloud Keychain, Google Password Manager) suit most staff. Microsoft suggests security keys or Authenticator passkeys for privileged or highly regulated users. If a profile allows both types and targets Authenticator, users need Authenticator for iOS 6.8.37 or Android 6.2507.4749 or later.
• Tell people and the helpdesk what is coming before the prompt appears. Microsoft provides end-user email and Teams templates at aka.ms/mfatemplates. Describe what the prompt looks like so a genuine one is not dismissed as suspicious.
• Do not remove people from the SMS and Voice policy until they have registered and tested a replacement. Once they have, remove them from the SMS and Voice scope so they stop getting further nudges.
• Keep a way back in for people who lose or replace phones. Make sure your helpdesk process and your administrators' own accounts do not depend on a phone number that is about to stop working.

Supported alternatives and exceptions

Passkeys are the route Microsoft recommends, but they are not the only one. These are the supported alternatives, with the catches stated.

• Authenticator or another TOTP app: still supported for new and existing registrations after 1 February 2027, and independent of SMS delivery. It is not phishing-resistant, so it fails any Conditional Access policy that requires a phishing-resistant strength. Microsoft points to it as an option where mobile passkeys are unavailable, for example on some Android devices in China.
• FIDO2 security keys, Windows Hello for Business or the Entra passkey on Windows: phishing-resistant options for people who cannot or will not use a phone, and Microsoft's suggested choice for administrators.
• Customer-managed telephony provider: if you have a business, regulatory or technical need for phone codes, you can contract a provider through Microsoft Security Store, with configuration available from 30 October 2026. Entra still generates and checks the code; the provider only delivers it. Microsoft's provider page lists Soprano, Telesign and Infobip offers, while other Microsoft pages describe the initial providers as being in private preview, so check each listing's current status. You deploy an integration (an Azure Function) in your own Azure subscription and run it, and you pay both the provider and Azure hosting costs. Microsoft recommends finishing setup at least four weeks before 1 February 2027. Our view: for a typical small tenant that is more moving parts than helping people register a passkey, so keep it for the groups that truly cannot move.
• Temporary opt-out: from 1 September 2026 to 1 February 2027 you can delay the automatic passkey enablement and the campaign by setting passkeyDynamicMigration to true under optOutSettings in the authentication methods policy, using Microsoft Graph (the beta endpoint, with the Policy.ReadWrite.AuthenticationMethod permission). It buys time to configure a provider or move users elsewhere. It does not delay the 1 February retirement, and your tenant is subject to the standard timeline from that date regardless.
• Choosing a provider before the date means affected users will not get the blocking passkey prompt. Users who stay enabled for Microsoft-provided SMS or voice still do.

Preparation checklist

Use this as an outcome list to tick off. The detail sits in the sections above.

• Before the end of 2026: you know which users are phone-only, and which of them are regular users, internal guests, Global Administrators or external users.
• Before the end of 2026: each phone-only group has a decision recorded (passkey, another method or telephony provider) and a pilot group has registered successfully on each device type you support.
• At least four weeks before 1 February 2027: if you are using a telephony provider, it is contracted, deployed and tested. Registration campaign settings match your timetable.
• Before 1 February 2027: users and helpdesk have been told; no regular user or internal guest is left with only SMS or voice unless a provider covers them.
• Before 1 July 2027, and sooner if you can: every Global Administrator and emergency access account uses a passkey, security key or other non-phone method, and external users who rely on SMS or voice have been dealt with.
• From February 2027: review registration details for anyone still phone-only, and tidy the SMS and Voice policy scope once users have moved.

What is still uncertain

Microsoft says the September changes deploy gradually, so you cannot assume your tenant matches the description until you check the policies yourself. Dates have already been revised once, and Microsoft's own pages differ slightly in emphasis on whether users with another registered method are expected to add a passkey. Guest passkey support and the schedule for other cloud environments are described as planned rather than delivered. Microsoft also says changing a password for users who sign in passwordless is planned, with details to follow. Until those details arrive, check the Learn pages listed below for changes rather than relying on a summary.