Entra ID passkeys become default as SMS/voice MFA retires

Microsoft is forcing Entra ID tenants off Microsoft-provided SMS and voice MFA delivery, with passkeys becoming the default sign-in path for users in scope. The change is scheduled to start on 1 September 2026 and block account access on 1 February 2027, so the real work is validating recovery, helpdesk and fallback paths before the old route disappears.

That matters because identity change is usually judged on the wrong metric. Vendors talk about stronger authentication and cleaner user journeys; operators need to know what will fail at the edges: shared devices, recovery flows, helpdesk processes, guest access, legacy line-of-business apps, and the people who still only have one usable MFA route. The real question is not whether passkeys are better in principle. It is whether your tenant can survive the retirement of a fallback path without creating a support incident disguised as a security improvement. (learn.microsoft.com)

What is actually changing

Microsoft is tying together two related but distinct moves. First, Entra ID will make passkeys the default authentication experience for users in scope. Second, Microsoft-provided telecom delivery for SMS and voice MFA will be retired. Microsoft’s documentation says that on 1 September 2026, users enabled for SMS or voice in the Entra Authentication Methods Policy, or legacy MFA settings, will be auto-enabled for passkeys in the Authentication Methods Policy. Then, from 1 February 2027, Microsoft-provided SMS and voice delivery will stop for tenants that have not configured a customer-managed telecom provider through the Microsoft Security Store. (learn.microsoft.com)

Microsoft also says this is a public-cloud timeline, and that B2B users and internal guest users are planned to be brought into passkey support by the end of calendar year 2026. That is worth treating as a planning note rather than a guarantee in your change calendar; Microsoft’s own wording is “planned”, not “available now”. (learn.microsoft.com)

The vendor’s security argument is straightforward enough. SMS and voice are weaker than phishing-resistant methods, and Microsoft now explicitly prefers passkeys, Windows Hello for Business and FIDO2-style methods over telecom-based MFA. Microsoft’s troubleshooting guidance for SMS and voice also concedes that external telecom delivery sits outside Microsoft’s direct visibility once a message leaves its provider. That is a useful line to read literally: if the message path becomes the problem, your support team may end up reconstructing events from scraps rather than from a clean platform log. (learn.microsoft.com)

How the exposure happens

The exposure is not only “users might not have a passkey yet”. It is that enterprises tend to accumulate identity dependencies in layers. A user may have one sign-in method registered, but the operational reality may also depend on:

• A legacy MFA settings page still being the source of truth for some accounts;
• A registration campaign that has not been tuned for the right groups;
• Helpdesk staff who still recover accounts by pushing SMS enrolment;
• Conditional access policies that assume a phone-based fallback exists;
• Service desks that use voice calls for out-of-band verification;
• Device scenarios where passkey registration is not available on the first useful device.

Microsoft’s own passkey guidance shows that registration can be done through Security info, that MFA is required to add a passkey, and that an Authentication Policy Administrator can issue a Temporary Access Pass to let a user strongly authenticate and then register a passkey. That is the correct design clue: if your recovery model does not already include a robust bootstrap path, the migration exposes it. (learn.microsoft.com)

There is also a policy-shape issue. Microsoft says that enabling passkey profiles causes existing global passkey settings to transfer to a Default passkey profile, and that attestation, key restriction and passkey type can be controlled in the profile. That gives operators more control, but it also creates more ways to misconfigure the rollout if the identity team and the endpoint team are not aligned on what devices, key types and sync models are actually allowed. (learn.microsoft.com)

Likely impact

That means you should treat the retirement as a live programme with checkpoints, not as a one-off setting change.

The first-order effect is obvious: some users will be nudged to register passkeys, and some will ignore the nudge until the process becomes blocking. Microsoft says users in scope will see registration campaign prompts, and that after 1 February 2027 users whose only available MFA method is SMS or voice will be forced to register a passkey before they can continue signing in. That is a hard stop, not a soft reminder. (learn.microsoft.com)

The second-order effect is more interesting for enterprise operators. If you have grown dependent on SMS or voice as a universal fallback, then the retirement forces a re-write of your account recovery story. Helpdesk scripts will need to distinguish between a user who cannot register a passkey because they lack a compatible device and a user who merely has not done it yet. Break-glass accounts, temporary access paths and privileged account recovery all need to be tested under realistic failure conditions, not just marked “documented”. (learn.microsoft.com)

There may also be finance and procurement implications if you choose to keep telecom-based MFA. Microsoft says tenants that still need SMS or voice can continue through customer-managed telecom providers via the Microsoft Security Store, but pricing is provider-specific and typically per-message. In other words, if you retain telecom delivery as a business requirement, you are no longer relying on a free native Microsoft capability; you are buying an operational dependency and inheriting the cost model that comes with it. (learn.microsoft.com)

For a UK or Channel Islands operator, that should be read in the context of resilience rather than convenience. Any fallback that depends on telecom delivery has an availability profile, a fraud profile and a support profile. A passkey rollout does not eliminate those concerns entirely, but it does remove one of the weakest and most failure-prone routes from the default path. Microsoft’s own NIST mapping guidance also marks PSTN SMS/voice as not recommended, which is the clearest possible signal that the direction of travel is not in doubt. (learn.microsoft.com)

What good looks like

A decent rollout is not “we enabled passkeys”. It is a migration with proof attached. Microsoft’s documentation points to the pieces, but the enterprise job is to stitch them together into something testable:

• Inventory the blast radius. Find every user still enabled for SMS or voice, in both the Authentication Methods Policy and legacy MFA settings. Microsoft says any non-zero result means you are in scope. (learn.microsoft.com)
• Move the default path early. Passkeys should be enabled before the retirement window, not during it. Microsoft says passkeys can be registered with FIDO2 security keys, native or third-party passkey providers, or Microsoft Authenticator, and that no extra licence is required for Entra ID Free. (learn.microsoft.com)
• Build a recovery story. Temporary Access Pass, administrative recovery and support scripts need to be exercised before users are in trouble. Microsoft explicitly calls out Temporary Access Pass as a route to strongly authenticate and register a passkey. (learn.microsoft.com)
• Decide whether sync is acceptable. Microsoft supports both synced and device-bound passkeys. That is not a trivial policy choice; it affects portability, device control and the balance between user convenience and managed-device assurance. (learn.microsoft.com)
• Tune registration campaigns. Microsoft says the registration campaign settings will be placed into Microsoft Managed state for in-scope users. That should be treated as a prompt to verify who is targeted, when nudges happen and whether your comms team is ready for the change. (learn.microsoft.com)

If you want a helpful internal analogue from our own coverage, the same principle applies as with storage or backup changes: the change itself is not the hard part, the runbook is. We have recently argued the point in relation to Azure managed disks snapshots and Azure SQL long-term retention, both of which look tidy in the portal until you ask what the recovery process really depends on. Identity migrations are no different. The user-facing switch is the easy bit; proving the edge cases is where the work lives. (learn.microsoft.com)

Priority actions before the clock runs out

If this is on your roadmap, the order matters. The wrong order creates avoidable support noise.

One useful point of discipline: do not frame this as a binary choice between “passkeys” and “security”. Passkeys are the stronger default, but the enterprise question is whether you have removed the old method cleanly enough that the stronger method does not become the new single point of failure. Microsoft’s documentation gives you the control points; it does not do the migration for you. (learn.microsoft.com)

Residual risk

Even if you do everything right, there is still residual risk. Passkeys reduce phishing exposure, but they do not fix every account problem. Device loss, user error, unmanaged endpoints, poor communications and incomplete guest-user planning can all still bite. Microsoft’s current wording also leaves some scope questions in motion, including guest and B2B support timing. That means you should treat the retirement as a live programme with checkpoints, not as a one-off setting change. (learn.microsoft.com)

The most important judgment is therefore not whether Microsoft is right to retire SMS and voice. On security grounds, it plainly is. The judgment is whether your organisation can prove that identity resilience survives the loss of a weak but familiar fallback. If you cannot demonstrate that today, then the problem is not Microsoft’s timetable. It is your dependency map. (learn.microsoft.com)

For administrators, the sensible response is to test the ugly cases early: the user with one old phone, the contractor with no managed device, the executive who refuses helpdesk enrolment, the recovery flow that still depends on voice, and the service desk queue that has never had to answer the question “what do we do if SMS is gone?” If your answers are clean, the passkey default becomes a security gain. If they are not, the retirement simply exposes a weakness that was already there. (learn.microsoft.com)