SMS and Voice MFA Are Being Retired in Entra ID: A Scenario-Based Guide to What Replaces Them

Microsoft is retiring SMS and voice as multifactor authentication (MFA) methods in Microsoft Entra ID. Passkeys become the default authentication experience on 1 September 2026, and Microsoft-provided SMS and voice stop working as MFA methods entirely on 1 February 2027. That much is a fixed date on a calendar. What is not fixed — and where most tenants get this wrong — is treating "replace SMS" as a single decision with a single answer.

An office worker on a managed Windows laptop, a Global Administrator, a warehouse picker sharing one Android device across three shifts, and a new starter who has not registered anything yet all need MFA. None of them need the same MFA. Push everyone onto one method and you either lock out the frontline worker who cannot enrol a passkey on a shared device, or you let an admin account get away with a phishable method that a passkey policy for "everyone" quietly still permits.

The problem: one policy, four completely different populations

Here is the trap. You open the Microsoft Entra admin center, go to the Authentication Methods Policy, and every method — Passkey, WHfB, FIDO2, Authenticator, TAP, QR code — is a single tenant-wide toggle with a target group. It is tempting to enable passkeys for "All users" and call the SMS migration done. That decision breaks in at least three places:

• Frontline shared devices. A passkey lives on one device, tied to one platform authenticator or security key. A device three different people sign into per shift cannot register a personal passkey for each of them without a lot of friction and cost.
• Privileged accounts. A blanket "Passwordless MFA strength" Conditional Access policy is satisfied by a passkey in the Authenticator app synced across a phishable device — it is not the same guarantee as a hardware-bound, phishing-resistant credential. Admin accounts need a stronger bar than "passwordless," they need phishing-resistant.
• Day-zero access. Nobody has a passkey, WHfB credential or FIDO2 key on their first day. Something has to bootstrap that first registration without falling back to the thing you are trying to retire.

Why it happens: the Authentication Methods Policy is one object, Authentication Strength is the actual lever

The Authentication Methods Policy (AMP) controls which methods exist for a user to register — think of it as the ingredients list. It is a single tenant-wide policy object, and each method (Passkey, WHfB, FIDO2 security key, Temporary Access Pass, QR code) has its own enable/disable toggle and its own target group inside that one object.

What AMP does not do is decide which method is required at sign-in for which resource. That is Conditional Access authentication strength — a Conditional Access grant control that names a specific combination of methods a sign-in must satisfy. Microsoft ships three built-in strengths:

Built-in strengths cannot be edited, but you can also build a custom authentication strength from the same method catalogue if you need a combination the built-ins do not cover. The four-scenario framework below is really just: pick the right AMP methods to enable per population, then pin each population to the matching Conditional Access authentication strength.

How to verify: see what your tenant actually has registered right now, before you change anything

Before touching any policy, find out how exposed you actually are. Two checks, both read-only.

Check 1 — the tenant-wide Authentication Methods Policy state, via Microsoft Graph:

The response lists every method (Sms, Voice, Passkey, Fido2, WindowsHelloForBusiness, TemporaryAccessPass, QrCode, and so on) with a state of enabled or disabled. That tells you what is switched on tenant-wide — not who is actually using what.

Check 2 — who is still relying on SMS or Voice as their only method. This is the number that actually matters before 1 February 2027. It is what the companion script below reports.

The fix: four scenarios, four different configurations

1. Office users on managed Windows devices — passkeys and WHfB, Passwordless MFA strength

This is your default path and the one Microsoft's own auto-enable on 1 September 2026 already assumes. Configure it deliberately rather than letting the auto-enable do it for you:

1. Sign in to the Microsoft Entra admin center.
2. Go to Protection › Authentication methods › Policies.
3. Select Passkey (FIDO2) and Windows Hello for Business, set each to Enable, and target the group representing your standard office population — not "All users" if you are staging this by department.
4. Go to Protection › Conditional Access › Authentication strengths and confirm the built-in Passwordless MFA strength is available (it always is — built-ins cannot be deleted).
5. Create or edit a Conditional Access policy scoped to this population's target apps, set Grant › Require authentication strength › Passwordless MFA strength, and assign it to the office-users group.

On-premises AD only, no Entra Connect device write-back yet? WHfB still needs a device to be Entra-joined, hybrid-joined, or Entra-registered before it will provision — there is no Group Policy path that gets you WHfB or passkeys on a device Entra has never seen. If your device fleet is not yet Entra-joined in some form, that is the actual blocker, not the authentication method choice.

These are the PassportForWork CSP policy values that actually control whether WHfB/passkey provisioning proceeds on the device — all live under the same parent key, stated once here rather than in every row:

If a device shows the right CSP values but a user still cannot register a passkey or WHfB credential, the User Device Registration log tells you exactly where provisioning stopped — the log channel is stated once here rather than per row:

2. Admins — phishing-resistant only, no exceptions

Passwordless MFA strength is not enough for a privileged role. A synced passkey in Authenticator satisfies "passwordless" but is not immune to a sophisticated real-time phishing relay the way a hardware-bound credential is. Admins need the Phishing-resistant MFA strength built-in, which only accepts FIDO2 security keys, WHfB (including the platform credential variant), and certificate-based authentication.

1. In Authentication methods › Policies, enable FIDO2 security key and target it at your admin/privileged-access group specifically — do not rely on the office-users passkey rollout to cover admins.
2. Go to Protection › Conditional Access › Policies › New policy.
3. Under Users, target your privileged directory roles directly (Global Administrator, Privileged Role Administrator, and so on) rather than a static group — this way anyone activated into an eligible role through PIM is covered the moment they activate, not just standing admins.
4. Under Grant, select Require authentication strength and choose the built-in Phishing-resistant MFA strength.
5. Set Enable policy to On and save.

3. Frontline workers on shared mobile devices — QR code sign-in, tightly scoped

QR code authentication exists specifically for this population: workers who share one iOS/iPadOS or Android device across a shift pattern, where registering an individual passkey per person on a device they do not own is impractical. It is not available on Windows — this is a mobile-only, shared-device-mode method.

1. Confirm the device is already configured in Shared device mode (the Entra ID feature that lets multiple employees sign in and out of the same iOS/iPadOS/Android device without seeing each other's data).
2. In Authentication methods › Policies, select QR code.
3. Set the state to Enable and target it at a dedicated group — for example "Frontline – Warehouse Shift Workers" — not All users. Enabling QR code tenant-wide gives every desk worker a second sign-in method to manage for no reason.
4. Each targeted user gets a unique QR code plus a PIN; they scan and enter the PIN rather than typing a UPN and password on a shared kiosk.

4. Onboarding and account recovery — Temporary Access Pass, scoped and short-lived

Nobody has a passkey on day one, and account recovery cannot depend on the method someone just lost access to. Temporary Access Pass (TAP) is the bootstrap: a time-limited passcode used specifically to register a real passwordless method, not as a standing sign-in method itself.

1. In Authentication methods › Policies, select Temporary Access Pass and set it to Enable.
2. Set the tenant-wide Default lifetime and Maximum lifetime — TAP lifetime must be between 10 minutes and 43,200 minutes (30 days) inclusive. For onboarding, a short lifetime (60–480 minutes) that expires the same day is safer than the 30-day maximum.
3. Set the policy-level One-time use property. If you set this to Yes at the policy level, every TAP issued in the tenant is forced to one-time use, which is the right default for both onboarding and recovery — a TAP that is only good once cannot become a long-lived backdoor if it leaks.
4. Issue the TAP to the new starter or the user who has lost their device (via the admin center or Graph), have them sign in with it, and immediately register a real method — a passkey for an office user, WHfB during Autopilot enrolment, or a FIDO2 key for an admin.

Proof it worked: confirm the right strength is actually being enforced, not just configured

Configuring the policy is not the same as proving it is doing anything. Check the Entra ID sign-in logs for a user in each population and confirm the Authentication requirement and Authentication method columns show what you expect:

If an admin's sign-in shows Authentication method: Password, SMS satisfying an MFA requirement, your Phishing-resistant Conditional Access policy is either not targeting that user's role correctly, or a break-glass exclusion is silently covering them. Check both before assuming the config is done.

Deploy this as a companion audit: know who is still exposed before the deadline

The single most useful thing you can run right now is a read-only report of every user whose only registered method is SMS or Voice — the population that breaks outright on 1 February 2027 if nobody acts. This is a Microsoft Graph query, not a device-side script, since authentication method registration lives entirely in Entra ID.

This is a real, tested script — app-only, read-only, requires only UserAuthenticationMethod.Read.All. It is available in Daily-Tasks.

References

• Passkeys by default and retirement of Microsoft-provided SMS and voice authentication — Microsoft Learn
• FAQ for Microsoft-provided SMS and voice retirement — Microsoft Learn
• Overview of Conditional Access authentication strengths — Microsoft Learn
• QR code authentication method in Microsoft Entra ID — Microsoft Learn
• Configure a Temporary Access Pass in Microsoft Entra ID — Microsoft Learn