Microsoft has handed you two dates, and neither waits. On 1 September 2026 Entra ID starts defaulting users to passkeys, and on 1 February 2027 Microsoft switches off its own SMS and voice delivery for MFA (timeline). If your tenant still leans on phishable codes, you have a decision to make. This article covers what the opt-out postpones, which cohorts move first, and why workforce identity belongs on your existing Entra ID platform — one decision inside the authentication roadmap.
Passkeys vs SMS/OTP MFA: which should enterprises standardise on?
Standardise on passkeys and treat SMS and voice one-time codes as legacy fallback at best. A passkey signs a challenge on your device and binds it to the site you are visiting, while an SMS code is a shared secret an attacker can relay in real time.
Security: not all MFA is equal
Adversary-in-the-middle (AiTM) proxies intercept the password and the code and replay both against the real service. One Microsoft Defender Research campaign targeted more than 35,000 users across 13,000 organisations by proxying sessions. Passkeys break that relay: the private key never leaves the device and the signature only works for the legitimate origin. NIST SP 800-63B deprecated SMS for high-assurance use in 2017.
Usability and recovery trade-offs
Passkeys also win on usability. Microsoft reports synced passkeys reach a 99 per cent registration rate, sign in 14 times faster than password plus traditional MFA, and succeed at sign-in three times the legacy rate. Recovery is where the gap narrows, and it plays out differently for the two passkey types (more in the cohort section below). If recovery falls back to an SMS code, you have reintroduced the phishable channel. For the mechanics, see the real security difference between passkeys and passwords.
Admin overhead and total cost
Cost shifts: SMS carries per-message telecom charges and reset tickets, while passkeys move the spend into registration and lifecycle management. Default to phishing-resistant passkeys, keep an authenticator app as an interim fallback, and stop deploying new SMS.
Once the answer is passkeys, the next question is timing, and whether Microsoft’s opt-out changes it.
Migrate now or use the opt-out: how to evaluate?
The opt-out is runway for sequencing a migration, and nothing more. Microsoft’s optOutSettings.passkeyDynamicMigration property pauses automatic passkey enablement and the Microsoft-managed registration campaign, but it does not extend Microsoft-provided SMS and voice past 1 February 2027. There is no opt-out from that date.
It lives in Microsoft Graph, not as a portal toggle. The migrate-now or wait call rests on five things: what you are moving from, whether your device and BYOD posture takes synced passkeys, how many users still rely on SMS or voice, how much change your help desk absorbs in a week, and how close you are to 1 February 2027. Forrester reads the announcement as a reason to act now and recommends a phased migration.
Start with the baseline. Microsoft’s entra-sms-voice-usage-analyzer script, run with read-only directory roles, inventories who still relies on SMS or voice. Any non-zero result puts you in scope, and that number sizes the rollout.
The only reason to keep SMS is a documented regulated or operational need, met through a customer-managed telecom provider. Providers and pricing are published on 18 September 2026, with configuration from 30 October 2026 through the Microsoft Security Store. Document the requirement and default everyone else to passkeys. For the two hard dates, revisit why SMS authentication is being retired.
Once the estate is sized and the opt-out is confirmed as runway only, the next decision is who moves first.
Which user cohorts should move to phishing-resistant authentication first?
Order the migration by attacker attractiveness and compromise impact, then by ease of rollout. Privileged administrators go first, then executives, finance, HR and developers, then knowledge workers, with constrained and legacy cohorts last on a transitional fallback. That sequence follows blast radius.
The logic is blunt: attackers go where the blast radius is largest. Put device-bound passkeys and FIDO2 security keys on admins and privileged roles, paired with Privileged Identity Management activation so elevation is itself phishing-resistant. Microsoft’s guidance pushes phishing-resistant MFA for every administrator role, from Global through Conditional Access Administrator. You get most of the risk reduction by moving privileged and high-risk accounts first.
Executives, finance, HR and developers come next. They hold approvals, money, personal data and, in the case of developers, access to code and production systems, making them high-value targets with wide compromise impact even without admin rights. Knowledge workers then get synced passkeys for low-friction adoption, since synced passkeys follow the user across their own devices. See the difference between synced and device-bound credentials for how that maps to each persona.
Constrained and legacy cohorts (shared kiosks, older devices, systems that still demand SMS) run an authenticator app fallback until a device-bound path is workable. Treat those as documented exceptions so SMS does not linger across the estate. A synced passkey restores from the platform account when a phone is replaced, so the general workforce moves without a hardware purchase.
That sequencing presumes a platform you already run, which raises the build-versus-buy question.
Build vs buy identity infrastructure for a 50 to 500 person company?
For workforce identity, buy. Passkeys, Conditional Access and registration campaigns are configuration inside Entra ID, with no code for your team to write, because the platform does the work. The build question belongs to product-user authentication, and even there it is a cost and control trade-off.
Treat the workforce IdP as a bought control plane. Most mid-sized organisations already own Entra ID, so the passkey migration is a roadmap and execution problem, solved within the platform you already license. Weigh engineering time, maintenance, compliance such as the Essential Eight, key storage, recovery and help-desk load before committing to any build. For workforce sign-in, those costs almost never beat buying.
Product-user authentication is where build may win. Customer identity has different scale, control and compliance needs, so weigh a custom build against managed options on the same cost and risk axes. The same logic extends to non-human identities, where machine credentials outnumber employees and need governance rather than bespoke code. That sits inside the wider identity estate, covered in our piece on non-human identity governance.
Conclusion
The opt-out gives you runway and nothing more. Once you accept that an SMS code can be phished, the defensible path runs one direction: standardise on phishing-resistant passkeys, sequence privileged cohorts first, and buy the IdP. Keep build decisions for product-user and machine identity, where the calculus differs. The two hard dates still stand, so use the runway to sequence the work — one step in the full post-password picture.
Frequently Asked Questions
Is it true that passkeys can’t be phished?
No, but they resist the attacks that defeat SMS. Passkeys bind the credential to the origin, so a fake sign-in page or an adversary-in-the-middle proxy cannot replay them the way an SMS code can be relayed in real time. The residual risk sits in registration phishing and account recovery, so treat passkeys as phishing-resistant rather than unbreakable.
What happens if an employee loses the device that holds their passkey?
It depends on the passkey type. A synced passkey is restored from the user’s platform account when they sign in on a new device, so the credential is not lost with the phone. A device-bound passkey needs a planned recovery path, usually a second credential or an admin reset, which is why recovery design comes before rollout rather than after.
Are synced passkeys safe enough for everyday staff?
Yes, for most knowledge workers. Synced passkeys keep the private key inside the platform’s secure storage and follow the user across their own devices, which removes the friction that stalls adoption. They are slightly less tightly controlled than device-bound credentials, so keep those for privileged roles and give the general workforce the lower-friction synced option.
Do I need to buy security keys for every employee?
No. Hardware security keys are the right call for admins and other privileged users, where device-bound control matters most, but they are not required across the whole organisation. Most employees can use synced passkeys on devices they already carry, which keeps cost and help-desk overhead down without weakening phishing resistance.
Is an authenticator app code phishing-resistant like a passkey?
No. A time-based code from an authenticator app is stronger than SMS because nothing travels over the phone network, but the code can still be relayed in real time and phished. That makes TOTP a sensible interim fallback for constrained cohorts while you migrate, not a long-term substitute for a passkey.
Does going passwordless mean users never type a password again?
Not quite. Passkeys replace the password at primary sign-in, but users will still meet passwords in edge cases such as account recovery, legacy applications, or first-run enrolment on a new device. Plan for those touch points up front, or “passwordless” quietly becomes the same password reset workload wearing a new name.
When does the 1 September 2026 change actually affect my current SMS users?
It does not disable SMS for existing users immediately. Microsoft begins defaulting new registrations and eligible tenants to passkeys on 1 September 2026, while Microsoft-provided SMS and voice delivery is retired on 1 February 2027. Current SMS users keep working until that retirement date or until your migration moves them, which is why the baseline inventory comes first.
Can I run passkeys and SMS side by side while I migrate?
Yes, and you should. A phased migration runs both methods concurrently, with passkeys rolling out cohort by cohort while SMS remains for users who have not yet moved. The discipline is to treat SMS as shrinking legacy inventory rather than a permanent channel, and to switch it off for each cohort as soon as passkey enrolment is confirmed.
Do passkeys cost extra in Microsoft Entra ID?
The headline difference is operational, not per-message. Passkeys ship as a built-in Entra ID feature, so the spend is the registration campaign, lifecycle management, and help-desk effort your team puts in. SMS carries ongoing per-message telecom charges plus reset tickets. Check your Entra ID licence tier for feature coverage, but do not let a licence comparison hide the SMS ticket load.
How do I handle vendors or systems that still force SMS OTP?
Treat them as exceptions, not a reason to keep SMS across the board. Where a third-party system genuinely requires SMS, move that traffic to a customer-managed telecom provider after you assess the regulatory or operational need, and isolate those users from the broader estate. Everything else should shift to phishing-resistant methods without waiting on the vendor.
How long should a passkey rollout take for a 50 to 500 person company?
There is no single number, but a phased rollout for a mid-sized company is usually measured in weeks to a few months, not a weekend. The variables are device posture, help-desk capacity, and how many users still depend on SMS. Sequence privileged cohorts first, then the general workforce, and let the 1 February 2027 retirement set your hard ceiling.
Do passkeys work on shared or kiosk computers?
Yes, but they need thought. A device-bound passkey on a hardware key suits shared machines well because the credential stays with the person, not the device. Synced passkeys are a poorer fit where many people share one profile, so put shared and kiosk scenarios in the constrained cohort with a planned, tightly controlled rollout path.
