Microsoft Entra Passkeys: Preparing for the Move Away From SMS

Microsoft's passkey transition in Entra ID is more than a new sign-in option. It is a scheduled change in the default authentication experience and a clear signal that SMS and voice no longer meet Microsoft's preferred security model.

Beginning September 1, 2026, Microsoft says users enabled for SMS or voice in affected public-cloud Entra tenants will be automatically enabled and prompted to register passkeys. Microsoft-provided SMS and voice delivery is scheduled to retire on February 1, 2027. Organizations with a genuine need for telecom authentication will be able to use supported customer-managed providers, but the recommended migration path is phishing-resistant authentication.

Those dates should trigger preparation, not a tenant-wide switch made the week before the deadline.

Why Microsoft is moving away from SMS and voice

SMS and voice helped make multifactor authentication widely available. Their weakness is that they depend on phishable workflows and telecommunications channels that can be redirected, socially engineered, or intercepted. A user can also be persuaded to relay a one-time code to a convincing fake sign-in page.

Passkeys use public-key cryptography and bind authentication to the legitimate service origin. The private key remains with the user's authenticator; the service stores a public key. A fake site cannot simply collect a reusable password or code and replay it to Entra ID.

This does not make every account automatically safe. Registration, recovery, device management, session security, and administrator roles still matter. It does remove a common class of shared-secret and relay attacks from the normal sign-in path.

What a passkey actually is

A passkey is a FIDO credential. The authenticator creates a key pair for a particular relying party. The private key is protected by the device or security key, while the public key is registered with the service. Signing in requires the authenticator to prove possession of the private key, usually after local user verification such as a biometric or PIN.

The local PIN is not sent to Microsoft. It unlocks the authenticator on the device. This distinction is useful during user education because a passkey prompt can otherwise look like “another password.”

Synced and device-bound passkeys

Entra supports both synced and device-bound passkey scenarios. A synced passkey can be available across devices through a supported credential provider. That improves recovery and usability, but it also means the organization must understand the provider, platform, account-recovery path, and policy controls involved.

A device-bound passkey stays with a particular authenticator, such as a hardware security key or a platform-bound credential. It can offer a more controlled assurance model, but replacement, enrollment, and break-glass processes require more deliberate operations.

The right choice depends on user population and risk. A broad workforce may benefit from managed synced passkeys. Privileged administrators, regulated roles, shared workstations, or constrained environments may justify device-bound authenticators.

Passkeys and Windows Hello for Business

Windows Hello for Business is already a phishing-resistant sign-in method built around a device-bound key and local gesture. It remains relevant. Entra passkeys broaden the authentication choices and can support cross-device or security-key scenarios, while Windows Hello remains closely integrated with managed Windows devices.

Migration planning should therefore inventory working phishing-resistant methods rather than assume every user must abandon Windows Hello. Microsoft's own timeline says users already using passkeys, Windows Hello for Business, or another phishing-resistant method can continue using them.

Where FIDO2 security keys still matter

Hardware security keys remain useful where phones are unavailable, personal credential sync is inappropriate, roaming is required, or administrators need a separately controlled authenticator. They can also provide redundancy: losing one device should not turn account recovery into an insecure help-desk exception.

The operational work includes approved key models, initial issuance, spare-key handling, lost-key revocation, and a verified recovery procedure. Buying keys is the easy part. Maintaining trustworthy enrollment is the real system.

Compatibility IT teams need to test

A passkey rollout crosses more than the Entra portal. Test:

• supported operating systems, browsers, and authenticator providers;
• managed and unmanaged devices;
• mobile and desktop cross-device flows;
• shared or kiosk devices;
• privileged administrator workstations;
• virtual desktop and remote-access scenarios;
• account bootstrap and device replacement;
• accessibility and alternative verification needs; and
• legacy applications that do not use modern authentication.

Conditional Access should be reviewed as part of the same design. A policy can require an authentication strength, but the combined policy set, exclusions, target resources, and session behavior still determine the outcome. Passkeys are an authentication method, not a replacement for access policy.

A migration checklist before September 2026

1. Use Entra authentication-method reporting to identify active SMS and voice users.
2. Classify users by device, role, application, and recovery requirements.
3. Confirm that passkeys and other approved phishing-resistant methods are enabled for pilot groups.
4. Test registration and sign-in on representative platforms.
5. Design secure recovery before removing the old method.
6. Communicate what users will see and why the prompt is legitimate.
7. Pilot with support staff and a limited population.
8. Monitor registration, failures, and help-desk patterns.
9. Expand in stages, prioritizing privileged and high-risk accounts.
10. Document any justified telecom exception and its replacement provider plan.

Microsoft documents a temporary opt-out from the automatic enablement period, but not from the February 2027 enforcement path. Treat that option as transition time, not a permanent architecture.

What not to do

Do not enable a new method everywhere without testing recovery and application compatibility. Do not leave administrators with a single authenticator. Do not replace SMS with weaker security questions or an easily manipulated help-desk process. And do not describe passkeys as infallible: compromised endpoints, malicious enrollment, stolen sessions, and excessive authorization remain separate risks.

The durable outcome is not “passkeys turned on.” It is a tenant in which users have a tested phishing-resistant sign-in method, recovery does not undermine it, access policies recognize the right assurance, and SMS retirement does not produce an emergency migration.