Ben Stegink
The authentication landscape for Microsoft Entra ID is shifting faster than many organizations realize, and the timeline is no longer abstract. Microsoft has confirmed that SMS and voice-based multifactor authentication are heading toward full retirement, with passkeys positioned as the default going forward. For IT teams still relying on legacy methods, the window to act is narrowing.
The Retirement Timeline You Need to Know
Microsoft’s official SMS and voice retirement documentation lays out a clear schedule, and it is worth reading the dates precisely because they do different things.
September 1, 2026 is the first date that changes behavior in your tenant. Passkeys become the default authentication experience, and any user currently enabled for SMS or voice in the authentication methods policy or in legacy per-user MFA settings is automatically enabled for passkeys. At the same time, your registration campaign settings are moved to a Microsoft managed state that brings those users into scope, so the next time they sign in and complete MFA they are nudged to register a passkey. The nudge is snoozable without limit at that stage, but it is a change your help desk will hear about if nobody told users it was coming.
September 18, 2026 is an information date rather than an enforcement one. That is when Microsoft publishes the options and terms for customer-managed telecom providers in the Microsoft Security Store, the path organizations will use if they need to keep an SMS or voice channel. October 30, 2026 is when you can actually select and configure one of those providers. Neither date forces a migration; together they define the window for standing up a carrier contract and piloting it before the deadline that does bite.
February 1, 2027 is the hard date. Microsoft-provided SMS and voice delivery retires completely across Entra ID, including self-service password reset. If a user’s only available MFA method is SMS or voice and you have not configured a customer-managed telecom provider, that user receives a blocking passkey registration prompt at sign-in. They are not locked out of the account, but they cannot skip the prompt either: registration has to be completed before they can continue. There is no opt out from that enforcement, and it applies to every tenant.
There is a temporary opt out for the September 1 changes, which is useful if you have a different plan in flight. Setting passkeyDynamicMigration to true in the optOutSettings of your authentication methods policy through Microsoft Graph excludes your tenant from automatic passkey enablement and the registration campaign rollout during the opt-out period. It buys time to configure a telecom provider or migrate users to a different method. It does not change anything about February 1.
One practical note on scoping the work: Microsoft publishes an SMS and voice usage analyzer script that reports which users in your tenant are still enabled for those methods. Any non-zero result means you are in scope, and that user list is the security group you will target with communications and a registration campaign.
Why Passkeys Are the Right Answer in Theory
From a security standpoint, the case for passkeys is compelling. SMS, voice calls, and even time-based one-time passwords are all vulnerable to phishing attacks, and AI-powered attacks are making those vulnerabilities increasingly dangerous. Tools capable of cloning voices from short audio clips already exist, and AI is dramatically improving the quality and targeting of phishing emails. Authenticator app push notifications with number matching raised the bar, but they still do not reach the phishing-resistant threshold that passkeys and FIDO2 hardware keys deliver. It is the same reason we recommend requiring the phishing-resistant authentication strength for privileged roles today rather than waiting for a deadline, one of several Entra ID settings worth reviewing in every tenant.
Microsoft has been working toward this goal for years. Personal Microsoft accounts gained the ability to go fully passwordless long before enterprise tenants, and the direction has always been clear. The deployment guidance for phishing-resistant passwordless authentication in Microsoft Entra ID outlines the path, with strong emphasis on device readiness across Windows 10, Windows 11, macOS, and mobile platforms.
Why the Reality Is More Complicated
Despite the strong security rationale, passkey deployment has a friction problem that organizations would be unwise to underestimate. As How-To Geek explored in a recent piece, passkeys are rolling out without the user education needed to make them stick. The fundamental issue is conceptual confusion: most users understood usernames and passwords intuitively. Passkeys, by contrast, raise immediate questions. Where is this stored? What happens when I replace my phone? What if my passkey is locked to a device I no longer have?
The storage question alone reveals real fragmentation. Passkeys can live in Microsoft Authenticator, in a third-party password manager like 1Password or Bitwarden, in a browser, or on a physical FIDO2 hardware key like a YubiKey. Microsoft draws the distinction between synced passkeys, which a platform credential manager such as iCloud Keychain or Google Password Manager replicates across a user’s devices, and device-bound passkeys that never leave the hardware they were created on. Both are supported, and they have meaningfully different recovery stories, which is exactly the kind of nuance that does not survive a single line in an onboarding email.
FIDO2 passkey configuration within Entra ID adds another layer: administrators can restrict which authenticator types are permitted by configuring Authenticator Attestation GUIDs, unique identifiers tied not just to device manufacturers but to specific models and firmware revisions. That control is genuinely useful when you have standardized on particular hardware, and it also has a sharp edge. An organization that carefully allowlists a set of YubiKey models can find that a newly purchased batch shipping with updated firmware reports an AAGUID that is not on the list, and those keys are refused at registration until someone updates the policy. Existing credentials keep working, but the procurement cycle and the authentication policy now have a dependency nobody documented.
The cross-device Bluetooth handshake that enables passkey authentication between a phone and a laptop is another source of practical frustration. The flow is not a conventional Bluetooth pairing; it uses proximity detection without establishing a persistent relationship between the two devices, which means there is nothing for a user to reconnect and nothing that stays configured from one sign-in to the next. When it works, it takes seconds. When it fails, users have no mental model for troubleshooting it, and the help desk ends up walking someone through Bluetooth radios, browser choice, and phone lock state on a Monday morning.
What This Means for Your Rollout
None of that is an argument for waiting. It is an argument for treating this as a change management project rather than a policy toggle, and for doing it on your calendar instead of Microsoft’s.
Start by finding out who is actually affected, using the usage analyzer script to build the list of SMS and voice users. In most tenants that list is smaller than people expect and concentrated in predictable places: shared accounts, field staff without corporate mobile devices, executives who set up MFA once in 2019 and never revisited it, and service-adjacent accounts that were never meant to have a human method at all.
Then decide deliberately where passkeys are the answer and where they are not. For most of the workforce, passkeys in Microsoft Authenticator or Windows Hello for Business will cover it, and device readiness is the gating factor. Organizations that have already moved endpoint configuration into modern management have an advantage here, because the same Intune estate that handles device configuration migrated off Group Policy is what gets Windows Hello for Business provisioned and compliance policies enforced ahead of the deadline. For privileged roles, hardware FIDO2 keys remain the right call, with the AAGUID caveat above handled by keeping the allowlist and the purchasing process in the same conversation. For the genuinely regulated or operationally stuck segments, evaluate a telecom provider in the Security Store once terms are published, and go in expecting per-message pricing that Microsoft was previously absorbing. Passkey migration, by contrast, carries no additional licensing cost.
Run your own registration campaign rather than inheriting the Microsoft managed one. You can enable a passkey campaign today, scoped to the security group of SMS and voice users, with snooze limits you control. The difference between a campaign you designed and one that arrives on September 1 is entirely in the communications, and Microsoft’s end-user communication templates give you a starting point for the awareness, action, and reminder phases.
Finally, invest in the education that the industry has largely skipped. Answer the three questions users will ask before they ask them: where the passkey lives, what happens when the phone is replaced, and who to call when the cross-device prompt does not appear. A Temporary Access Pass process for onboarding and recovery is the backstop that keeps those situations from turning into password resets over the phone, which is the failure mode this whole initiative exists to eliminate. If you already run phishing simulations as part of a broader security awareness program, the same muscle applies here, and the attack simulation training in the Defender portal is a reasonable place to reinforce why the change is happening at all.
Conclusion
The direction of travel is unambiguous: phishing-resistant, passwordless authentication is the destination, and the roadmap now has firm dates attached to it. The organizations that come through this well will not be the ones with the most elegant policy configuration. They will be the ones whose users understood what was changing, had a working method registered months before February 1, 2027, and knew what to do when something did not work. That is a communications and planning problem more than a technical one, and it is entirely solvable with the runway that is still available.
If you would like help scoping which users are affected, choosing the right mix of passkey methods for your environment, or building the rollout and communications plan, reach out and let’s talk.
