Entra ID’s move from SMS/voice MFA to passkeys: what breaks

Microsoft Entra ID is steering away from SMS and voice MFA and toward passkeys based on FIDO2/WebAuthn—phasing out reliance on weaker, phone-number-based authentication methods. The challenge isn’t just toggling MFA settings; it can change recovery options, the authentication strength required for Conditional Access authentication strength, how legacy app sign-in paths behave, and the downstream helpdesk workload. Plan before enforcement.

What actually changes

Conceptually, SMS and voice MFA are phone-number factors. They can work, but they are weakly bound to the person and weakly bound to the device. Passkeys are different: Microsoft Entra ID describes them as phishing-resistant credentials that use FIDO2/WebAuthn, can act as MFA when paired with a biometric or PIN, and verify that the authenticator only releases secrets to the site it was registered with. In plain English, the credential is tied to the relying party and the user has to unlock it locally. That is a much better fit for modern phishing-resistant identity design. (learn.microsoft.com)

For admins, the important shift is that authentication policy becomes more than a tick-box list of allowed methods. Entra ID now distinguishes between allowed methods, registered methods, and the authentication strength a Conditional Access policy requires. If you require phishing-resistant MFA, the user must satisfy that strength at sign-in, not merely have some other MFA method in their profile. Microsoft also recommends using authentication strengths to enforce passkeys for sensitive resources. (learn.microsoft.com)

Why Microsoft is pushing this direction

The case is a familiar one, but the reasons are more concrete than the marketing shorthand usually suggests. Microsoft’s own guidance says passwords remain a primary attack vector, and that phishing-resistant passwordless methods are both more secure and less friction-heavy than password-plus-MFA flows. It also claims passkeys are generally faster than passwords in consumer sign-in scenarios, with synced passkeys the quickest of the lot. That speed claim is secondary; the security claim is the real one. (learn.microsoft.com)

There is also a fraud and reliability angle. SMS can be delayed, intercepted, or undermined by SIM-swap style attacks and telecom dependency. Voice can be unavailable for mundane reasons: coverage, line quality, roaming, call-blocking, PBX oddities, and plain user inconvenience. Microsoft’s retirement notice makes clear it wants organisations off Microsoft-provided SMS and voice, and onto passkeys or customer-managed telecom arrangements if they insist on those routes. That is less a punishment than an acknowledgement that phone-based MFA is a brittle layer for enterprise identity. (learn.microsoft.com)

Where projects go wrong

The first trap is thinking passkeys are a one-time enablement. They are not. They create a new lifecycle to manage: enrolment, recovery, device change, revocation, offboarding, and audit. Microsoft says admins can track passkey creation and usage in audit logs, sign-in logs and user notifications, and that there is currently no automatic expiration for passkeys, which means lifecycle hygiene matters rather more than many teams will expect. (learn.microsoft.com)

The second trap is recovery. If a user loses the device that holds their only usable passkey, what is the supported path back in? Microsoft recommends Temporary Access Pass for registering passwordless methods and warns that enforcing phishing-resistant MFA before the population is ready can lock you out of your own tenant. That warning should be read literally. Break-glass accounts are not an optional extra; Microsoft advises creating at least two emergency access accounts and using them only for genuine emergency scenarios. (learn.microsoft.com)

The third trap is assuming every app honours the same sign-in journey. Conditional Access can require authentication strength, but legacy protocols, hybrid authentication paths, and oddball line-of-business applications can still break the model. Microsoft’s own documentation shows that multiple policies are evaluated together, and that the user must satisfy them all. If one policy demands phishing-resistant MFA and another blocks something the app relies on, the result is a refusal, not a helpful compromise. (learn.microsoft.com)

The fourth trap is reporting confidence. Microsoft’s authentication methods activity dashboard is useful, but it is not real-time; it can lag by up to 36 hours. Sign-in logs can also mislead if you only glance at the authentication requirement field, because previous MFA claims may have been accepted. If you are measuring success, you need to look at method usage, registration, failures, and the full sign-in context rather than a single status flag. (learn.microsoft.com)

Rollout playbook: discovery before enforcement

Start with inventory, not policy. Microsoft’s guidance for phishing-resistant passwordless deployment begins with understanding the methods already in use and the users who can be moved safely. That is the right order. You want to know who uses SMS, who uses voice, who already has FIDO2 or Authenticator-based methods, and which roles have the strictest security requirements. (learn.microsoft.com)

1. Map your current methods. Use the Authentication Methods Activity report, sign-in logs, and—if you script—Graph or PowerShell reporting to establish who is registered for what, and what is actually being used. (learn.microsoft.com)
2. Identify your blast radius. Separate admins, privileged users, contractors, external users, frontline staff, and anyone with shared or hardened devices. Different groups will need different passkey models and different recovery assumptions. Microsoft explicitly distinguishes between device-bound and synced passkeys depending on control requirements. (learn.microsoft.com)
3. Pilot by group, not by optimism. Start with a controlled cohort that can tolerate a failure without derailing the business. Privileged users are often the right starting point for enforcement, but only after they have registered a usable recovery path. (learn.microsoft.com)
4. Set a fallback path. Define what happens if passkey registration fails, the device is lost, or the browser cannot complete the flow. Temporary Access Pass, a second enrolled method, or helpdesk-mediated recovery should be explicit, not improvised. (learn.microsoft.com)
5. Prove end-to-end access. Test not only registration but also re-authentication after token expiry, cross-device sign-in, risk-based prompts, and access to the actual apps users need. If you rely on Conditional Access authentication strengths, test those policies in report-only mode first. (learn.microsoft.com)

Questions worth asking before you switch on enforcement

• Which users still rely on SMS or voice as their only MFA method?
• Do we have at least two emergency access accounts, and are they excluded from everyday Conditional Access policy chains? (learn.microsoft.com)
• What is our approved recovery method for lost devices or failed enrolments?
• Which apps, browsers, and managed device states can actually complete a passkey flow?
• Do our helpdesk and security teams know how to distinguish a method registration failure from a Conditional Access failure?
• How will we revoke a passkey during offboarding or compromise response? Microsoft says admins can delete a passkey via the per-user authentication methods UX or API. (learn.microsoft.com)

Test cases that matter in the real world

Governance: treat passkeys like credentials, not convenience features

Once passkeys are live, governance becomes a standing discipline. That means defining ownership for lifecycle events, setting expectations for device changes, and deciding how quickly a passkey should be removed when a device is lost or a user leaves. It also means being honest about the difference between device-bound and synced passkeys. Microsoft says synced passkeys remain phishing-resistant, but if strict device boundary control is a hard requirement, device-bound passkeys are the recommended option. That distinction matters for regulated teams and privileged users. (learn.microsoft.com)

Service accounts deserve a separate sentence, because they are often where good identity programmes go to die. Do not shoehorn human passkey workflows into accounts that should be using a different control model altogether. If a process depends on a shared sign-in, a script, or unattended access, it needs its own governance, not a borrowed passkey policy.

For incident response, the key question is not just “was the account compromised?” but “which methods were registered, which were used, and which recovery routes remain live?”. Microsoft’s logging and audit tooling can help, but only if you have baseline expectations for normal usage and a clean offboarding process. (learn.microsoft.com)

How to know you are ready

You are probably ready to tighten enforcement when three things are true: most users have a registered passkey or other phishing-resistant method; break-glass and recovery paths have been tested, not merely documented; and your sign-in telemetry shows you can distinguish healthy adoption from silent failure. If you cannot answer those three questions confidently, you are not ready to remove the safety net, no matter how tidy the policy page looks.

Do: inventory methods, pilot by group, test recovery, watch logs, and treat break-glass accounts as governance items rather than relics. Don’t: enforce phishing-resistant MFA before your registration and recovery story is complete, assume a passkey works everywhere by default, or trust a single dashboard number as proof of success. Microsoft’s direction is sensible; the hard part is making the transition operationally boring. That is where most security programmes either earn their keep or create a support queue.