Passkeys by Default and the Retirement of Microsoft SMS and Voice MFA: The Entra Migration Playbook

Microsoft Entra ID is making passkeys the default sign-in experience and retiring Microsoft-provided SMS and voice authentication on two dates you need in your calendar now. On 1 September 2026, every user still enabled for SMS or voice is auto-enabled for passkeys and pulled into a Microsoft-managed registration campaign that nudges them to enrol. On 1 February 2027, Microsoft-provided telecom delivery for SMS and voice is retired for good — and after that date, any user whose only MFA method is SMS or voice gets a blocking passkey-registration prompt with no opt-out, for all tenants. This is the migration playbook: who is in scope, how to find your exposed users, how to move them to passkeys, when a customer-managed telecom provider is actually worth it, and how the whole thing plugs into your Conditional Access baseline. Every date and behaviour here is validated against Microsoft Learn as of August 2026.

If you want a fast read on your own exposure before you go any further, our free browser-based AuthMethods Readiness Analyzer turns a Microsoft Graph userRegistrationDetails export into an SMS/voice retirement worklist and a passkey-readiness view without sending anything to a server.

What is changing, and when?

Microsoft''s position is blunt: SMS and voice are among the weakest authentication methods available, offering far less protection against phishing, SIM-swap, and account-takeover than passkeys. So Entra ID is repositioning passkeys as the default and stepping out of the business of delivering one-time codes over the phone network itself. Note the precise scope of the word "retirement" — Microsoft is retiring the Microsoft-provided telecom delivery, not the SMS/voice method as an abstract concept. If you have a genuine need, you can keep SMS or voice by contracting a carrier through the new Microsoft Security Store.

Does SMS and voice MFA stop working on 1 September 2026?

No — and this is the most common misreading. 1 September 2026 is not a cut-off. On that date, users still on SMS or voice are auto-enabled for passkeys and start receiving a Microsoft-managed nudge to register one; by default that nudge has unlimited snoozes, so a user can keep dismissing it. SMS and voice continue to function as MFA methods right up until the retirement. The hard cutover is 1 February 2027. Treat September as the start of your migration window and February as the deadline, not the other way around.

If you would rather Microsoft did not touch your registration campaign or auto-enable passkeys for these users on 1 September, you have two clean options: remove SMS/voice from the relevant users before that date, or apply the temporary opt-out described later. Either way, the February enforcement still lands.

Who is in scope — and who is not?

Get the scope right before you plan anything, because a chunk of the estate is explicitly excluded:

• In scope: commercial Entra ID tenants in the public cloud. Government and other sovereign clouds follow on a later schedule with separate advance notice.
• SSPR is included. The retirement of native SMS and voice applies across Entra, self-service password reset included. Users can still use SMS/voice for SSPR only through a Security Store telecom provider. Microsoft has also said it is working on a way for passwordless users to change their password — more detail to come.
• B2B and guest users are in scope for the SMS/voice retirement, but passkey support for B2B and internal guests is only planned to land by the end of calendar year 2026 — factor that timing into any guest-heavy tenant.
• Azure AD B2C is out of scope and unaffected by this announcement.
• Microsoft Entra External ID gets this change next year, under a separate announcement — no change today.
• External / third-party MFA methods are not affected unless the same users are also enabled for SMS or voice. Only SMS/voice and legacy MFA policies are being retired.

Step 1: Find who still uses SMS or voice

You cannot size the migration you cannot see. Microsoft ships a PowerShell script for this at github.com/microsoft/entra-sms-voice-usage-analyzer; running it needs Global Reader, Authentication Policy Administrator, or Security Reader. Any non-zero result means your tenant is in scope.

The gotcha that catches teams out: the script reports against the modern Authentication Methods Policy. If your tenant''s methods migration is still in the "Not Started" state, Entra also honours legacy per-user MFA and older SSPR settings — so the script can cheerfully report "SMS/Voice disabled, no action required" while plenty of users are still authenticating with SMS through the legacy configuration. Before you trust any count, complete the migration under Protection > Authentication methods > Manage migration so Entra evaluates only the modern policy, and reconcile against actual registration data.

That reconciliation is exactly the niche our AuthMethods Readiness Analyzer fills. Export userRegistrationDetails from Graph (or the Entra portal registration report CSV), drop it into the tool in your browser — nothing is uploaded — and you get an SMS/voice retirement worklist, a phishing-resistant coverage view for all users and admins separately, passkey-readiness and migration targets, and an SSPR registered-versus-capable reconciliation. It also supports a baseline-compare mode so you can load an earlier export and watch the SMS/voice population shrink week over week. It is the fast, no-install way to turn the raw export into the worklist you will actually work from.

Step 2: Turn on passkeys and move users across

Passkeys are the default phishing-resistant credential in Entra ID: cryptographic key pairs tied to a device or a synced credential store, resistant to phishing, SIM-swap, and replay because there is no shared secret to steal. Entra supports two shapes, and most organisations will use both:

• Synced passkeys — saved to a platform credential manager (iCloud Keychain, Google Password Manager) and synced across a user''s devices. Best for people who already live in a platform ecosystem.
• Device-bound passkeys — created and stored on a single device: Passkey in Microsoft Authenticator, Entra Passkey on Windows, or a FIDO2 hardware security key. Best for shared-device, high-assurance, or BYO-restricted scenarios.

The mechanics: enable Passkey (FIDO2) as an authentication method, make sure your SMS/voice users are inside a passkey-enabled Authentication Methods Policy, then drive enrolment with a registration campaign — before Microsoft turns one on for you on 1 September. Under Entra ID > Authentication methods > Registration campaign, set State to Microsoft Managed (or scope it explicitly to a security group of your SMS/voice users) and target passkeys. A proactively run campaign is the single most effective way to move people off SMS and voice at scale without flooding the service desk, because it meets users in the sign-in flow they are already completing.

For the full rollout mechanics, Microsoft''s passkey deployment guide and the "Enable passkeys (FIDO2) for your organization" article are the canonical references. Pair the enrolment push with our Conditional Access baseline so that as users gain phishing-resistant credentials, your policies actually require them.

Step 3: Decide whether you need a customer-managed telecom provider

For the overwhelming majority of users the answer is: you do not — move them to passkeys and be done. Microsoft is explicit that passkeys are the primary migration path, and migrating SMS/voice users to passkeys carries no additional cost. A customer-managed telecom provider exists for the genuine exceptions: a regulated industry that mandates an out-of-band SMS channel, or an operational scenario where no other method is workable.

If that is you, the flow is: document the specific requirement (which regulation, which user segment, which scenario); from 18 September 2026 review the providers and terms in the Microsoft Security Store; from 30 October 2026 select and configure a provider; then stand up the carrier contract and pilot it before broad rollout. Pricing is per-message and varies by provider, volume, and region, so you are taking on a real, ongoing cost — scope it to the smallest population that truly needs it, and default everyone else to passkeys.

Step 4: Communicate before you enforce

Microsoft calls coordinated communication the single biggest predictor of a smooth passkey rollout, and it is right — a blocking prompt that arrives unannounced becomes a P1 to your service desk. Run a phased plan aligned to the timeline:

• Awareness — announce that SMS and voice are retiring, explain why, and tell users which method they are moving to.
• Action — direct users to register a passkey, with device-specific steps for Windows Hello, iOS, and Android.
• Reminder — chase the users who have not yet registered a phishing-resistant method.

Microsoft provides ready-made end-user templates for email, Teams, and comms portals at aka.ms/mfatemplates. Scope your messaging to the security group of SMS/voice users you built in Step 1 so only the people who need to act hear from you.

The temporary opt-out (and its hard limit)

If you need breathing room — because you are configuring a telecom provider or migrating to a different method on your own schedule — there is a temporary opt-out covering the 1 September 2026 to 1 February 2027 window. It suppresses the automatic passkey enablement and the Registration Campaign rollout during that period. You need the Microsoft Graph Policy.ReadWrite.AuthenticationMethod permission, then patch the authentication methods policy:

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

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

Be clear about what this does and does not buy you. It delays the September behaviour only. There is no opt-out for the 1 February 2027 enforcement — the standard migration and enforcement timelines apply to every tenant regardless of this setting. Use the opt-out to control when you migrate, never as a way to avoid migrating.

What happens on 1 February 2027 if you do nothing?

Nobody is instantly locked out — but the experience is deliberately disruptive by design. From that date, users whose only available MFA method is SMS or voice, in a tenant with no configured telecom provider, receive a blocking passkey-registration prompt at sign-in. They can no longer snooze it; they must register a passkey before they can continue into their account. The same logic applies to SSPR. In practice that means: if you have not driven your SMS/voice-only population to zero, 1 February 2027 is the day your service desk finds out how many you missed. The entire point of the September-to-February window is to make that number zero on your terms rather than Microsoft''s.

How this fits your Conditional Access and identity baseline

This retirement is a forcing function for something you should be doing anyway. As users gain passkeys, tighten the screws around them: require phishing-resistant MFA for administrators first, then extend it, and use Privileged Identity Management so standing admin access is not sitting behind a phone call in the first place. Wire the requirement into policy with your Conditional Access baseline — a Conditional Access authentication-strength grant for phishing-resistant MFA is how you make "passkeys by default" mean "passkeys required" for the sessions that matter. Migration gets users the credential; Conditional Access makes the credential mandatory.

Frequently asked questions

Are my users going to be locked out on 1 February 2027?

No. Users who still rely on SMS or voice will receive a blocking prompt to register a passkey — they cannot skip it, but registering one lets them straight back in. Nobody is permanently locked out. If you have a legitimate need, configuring a customer-managed telecom provider through the Microsoft Security Store before that date lets those users keep using SMS or voice.

Will Microsoft migrate my users automatically, or do I have to?

On 1 September 2026, users enabled for SMS or voice in the Authentication Methods Policy (or legacy MFA settings) are auto-enabled for passkeys, and your Registration Campaign is set to Microsoft Managed to nudge them. But auto-enabling the method is not the same as users actually registering one — by default the nudge has unlimited snoozes. You still own driving real enrolment before the February deadline.

Does this affect self-service password reset (SSPR)?

Yes. The native SMS and voice retirement applies across Entra, including SSPR. After retirement, users can only keep SMS/voice for SSPR via a Security Store telecom provider. Watch out for a known SSPR registration trap: if you require two methods and a user only has Authenticator, they often cannot add Email OTP during the interrupted sign-in and can get stuck — stage the requirement (one method first, add the second later) rather than enforcing two at once.

What is the difference between 1 September 2026 and 1 February 2027?

September is the start of the migration window: passkeys are auto-enabled and the nudge campaign begins, but SMS and voice keep working. February is the hard cutover: Microsoft-provided SMS/voice delivery is retired, and SMS/voice-only users then hit a non-dismissible passkey-registration prompt. Plan to be finished by February, not starting.

Can I keep SMS or voice if I genuinely need it?

Yes, but not from Microsoft directly. From 30 October 2026 you can configure a customer-managed telecom provider through the Microsoft Security Store, with provider and terms visible from 18 September 2026. It is a per-message, region-dependent cost, so reserve it for the specific regulated or operational segments that truly require an out-of-band telecom channel and move everyone else to passkeys, which is free.

Is Azure AD B2C or Entra External ID affected?

Azure AD B2C is out of scope and unaffected. Microsoft Entra External ID gets this change next year under a separate announcement, so there is no change for External ID tenants today. This timeline applies to public-cloud commercial tenants; other cloud environments follow later with their own notice.

How do I find out how exposed my tenant is right now?

Run Microsoft's entra-sms-voice-usage-analyzer PowerShell script for the policy-level answer, and reconcile it against real registration data — remembering that a "Not Started" methods-migration state can hide legacy SMS usage. To turn a userRegistrationDetails export into an actionable worklist without writing PowerShell, use our browser-based AuthMethods Readiness Analyzer: it produces the SMS/voice retirement worklist, phishing-resistant coverage for users and admins, and passkey-readiness targets entirely client-side.