Microsoft is retiring SMS and voice MFA — what to do before September 1
Microsoft Entra ID retires Microsoft-provided SMS and voice authentication on February 1, 2027, and begins auto-enabling passkeys on September 1, 2026. The timeline, who it affects, and why a $29 security key is the right answer for the accounts that matter.
- Microsoft 365
- Entra ID
- MFA
- Passkeys
- YubiKey
- Identity
Microsoft has notified every Microsoft Entra ID tenant that text-message and phone-call multi-factor authentication is being retired. Passkeys become the default sign-in experience, and Microsoft-provided SMS and voice delivery ends on February 1, 2027.
The date to actually put in your calendar is the earlier one. On September 1, 2026 — about two weeks from now — Microsoft begins automatically enabling passkeys for every user currently set up for SMS or voice, switching your registration campaign settings to Microsoft-managed, and prompting those users to register a passkey the next time they complete MFA.
That is not a deadline you can miss. It is the point at which the change starts happening to your users whether or not you have told them it is coming.
The short version for management
- Text-message and phone-call MFA are going away. Microsoft is ending them because they are the weakest authentication methods still in common use.
- Two dates matter. September 1, 2026: your users start getting prompted to register a passkey. February 1, 2027: SMS and voice stop working, and affected users are blocked at sign-in until they register a passkey.
- The migration itself costs nothing in licensing. Moving users to passkeys carries no additional Microsoft cost. Keeping SMS through a third-party telecom provider does cost money, per message.
- The real cost is preparation. Help desk time, user communication, and hardware security keys at $29 each — one per user, plus a couple locked in a safe for emergency access accounts.
- Doing this deliberately in the next four months is cheap. Being forced through it next February is not. The failure mode is a queue of locked-out users on a Monday morning and a help desk performing identity verification under pressure, which is exactly the condition attackers look for.
What is actually changing
Three separate things, and it helps to keep them apart:
Passkeys become the default. Users enabled for SMS or voice — in the Authentication Methods policy or in legacy per-user MFA settings — are automatically enabled for passkeys and nudged to register one. Microsoft’s documentation notes these users get unlimited snoozes of that prompt by default, which sounds generous and is in fact the problem: a promptable, snoozable nudge that nobody acts on until it becomes blocking.
Microsoft-provided telecom delivery retires. This is Microsoft sending the message. If you contract a telecom provider yourself through the Microsoft Security Store, SMS and voice keep working for the users you scope to it.
After February 1, 2027, enforcement is hard. A user whose only available MFA method is SMS or voice gets a blocking prompt to register a passkey before they can finish signing in. Microsoft has stated plainly that there is no opt out from this and it applies to all tenants.
Note what is not on that list. The Microsoft Authenticator app is not being retired. Neither are hardware security keys, Windows Hello for Business, or certificate-based authentication. If your users already approve sign-ins in Authenticator, this change does not break them. The people affected are the ones still receiving a six-digit code by text or a robocall.
One more scope note that matters if you work in defense or government: the timeline above applies to public cloud tenants only. Microsoft has said other cloud environments — the government clouds among them — follow on a later schedule with separate notice. Azure AD B2C is out of scope entirely, and Microsoft Entra External ID gets its own announcement next year.
Why Microsoft is doing this
Because SMS was never a good second factor. It was a convenient one, and it was better than nothing, which is a much lower bar than most organizations realize they were clearing.
Three attacks defeat it, and none of them are exotic:
- SIM swap. An attacker persuades a mobile carrier — often just a retail store employee — to move the target’s number to a SIM they control. Every code then arrives on the attacker’s phone. This requires no technical skill whatsoever.
- Real-time phishing. A proxy site collects the password and the texted code at the same moment and replays both against the genuine Microsoft sign-in page inside the code’s validity window. Off-the-shelf kits do this. The user sees a convincing login page, enters a legitimate code, and never knows.
- Vishing. Someone calls claiming to be IT and asks the user to read out the code that just arrived. This works far more often than security teams like to admit.
Every one of these depends on the same weakness: the second factor is a shared secret that a human can be talked into handing over.
A passkey removes that. The credential is a private key that never leaves the device, and it is cryptographically bound to the site it was registered for. There is nothing to read aloud, nothing to relay, and a phishing proxy cannot satisfy the origin check no matter how convincing its page is. That is what phishing-resistant means in practice — not that your users become harder to fool, but that fooling them is no longer sufficient.
The dates
| Date | What happens |
|---|---|
| September 1, 2026 | Users enabled for SMS or voice are auto-enabled for passkeys, your registration campaign flips to Microsoft-managed, and those users are nudged to register at their next MFA prompt. To prevent this, move them out of SMS and voice in the Authentication Methods policy first — or take the temporary opt-out below. |
| September 18, 2026 | Microsoft Security Store begins publishing third-party telecom provider options, terms, and pricing. |
| October 30, 2026 | Customer-managed telecom provider configuration becomes available. |
| February 1, 2027 | Microsoft-provided SMS and voice are fully retired, including for self-service password reset. |
| After February 1, 2027 | Users with no method other than SMS or voice are blocked at sign-in until they register a passkey. No opt out, all tenants. |
Step one: find out whether this affects you
In the Microsoft Entra admin center, go to Entra ID → Authentication methods → Policies and check whether SMS and Voice call are enabled, and for which groups. If both are disabled tenant-wide and you have no legacy per-user MFA settings in play, you are finished — the rest of this does not apply to you.
If they are enabled, the policy alone will not tell you who is actually using them. Microsoft has published a PowerShell script for exactly this — the entra-sms-voice-usage-analyzer — which you run with Global Reader, Authentication Policy Administrator, or Security Reader. Any non-zero result means you are in scope. Cross-check it against Authentication methods → User registration details, which lists the methods each user has registered.
Put the results in a security group. Everything downstream — the registration campaign, your user communications, the hardware key order — targets that group.
The choice you are actually making
Microsoft supports two kinds of passkey, and the difference is not a technical footnote. It determines who controls the credential.
Synced passkeys live in a platform credential manager — iCloud Keychain, Google Password Manager — and sync across the user’s devices. They are free, they are fast to deploy, and they are genuinely phishing-resistant. They also mean your corporate sign-in credential is stored in an employee’s personal Apple or Google account, replicated to devices you do not manage, and leaving with them when they resign.
Device-bound passkeys are created on and never leave a specific piece of hardware: Windows Hello for Business on a managed PC, a passkey in Microsoft Authenticator, or a FIDO2 security key.
For most organizations the sensible answer is a mix — and the mix should be deliberate, not accidental.
Why we steer clients toward hardware keys
For the general office population on managed Windows devices, Windows Hello for Business and passkeys in Authenticator do the job at no hardware cost, and we deploy them.
For everyone else, and for every account that matters, we recommend YubiKeys. The reasons are practical, not brand loyalty:
They do not depend on a phone. Every organization has people the phone-based plan silently fails: manufacturing and warehouse floors where personal phones are not allowed or not carried, shared clinical and point-of-sale workstations, field crews with no signal, and the perennially awkward conversation with the employee who declines to install a company app on a personal device they paid for. A security key hanging on a lanyard has none of these problems. It also works with no cell signal and no battery.
They survive the device lifecycle. A passkey in Authenticator is gone when the phone is lost, stolen, replaced, wiped, or the employee upgrades and does not migrate it. Every one of those events becomes a help desk ticket. A YubiKey moves from laptop to laptop with the person for years.
You can enforce exactly which models are allowed. In the passkey policy you can turn on Enforce attestation and restrict registration by AAGUID — the identifier for a specific authenticator model. That lets you say “only these approved YubiKey models may be registered in this tenant” and have Entra enforce it, rather than hoping. You cannot do this with a passkey sitting in an employee’s personal cloud account.
The credential stays inside your organization. The private key is generated on the key and cannot be extracted, synced, backed up, or copied to a personal device. When someone leaves, you collect the hardware.
They cover the accounts you cannot afford to get wrong. Global Administrators, break-glass emergency access accounts, anyone touching finance or payroll, and anyone with access to regulated data. If you buy hardware keys for nobody else, buy them for these.
They are the defensible answer in regulated environments. For organizations working toward CMMC readiness, or answering a cyber insurance questionnaire that has moved on from “do you have MFA” to “what kind,” a device-bound hardware credential with attestation enforced is a straightforward thing to evidence.
The $29 key is the one you want
This is the part that surprises people who priced out security keys a few years ago and put the idea down.
Entra passkey sign-in needs exactly one protocol: FIDO2/WebAuthn. Yubico sells a line built for precisely that and nothing else — the Security Key Series, at $29 per key, in both USB-A and USB-C with NFC. It is not a cut-down or second-tier product for this purpose. For signing in to Microsoft 365 it does the identical cryptographic job as the key costing twice as much.
| Model | Price | What it does | Buy it for |
|---|---|---|---|
| Security Key NFC / Security Key C NFC | $29 | FIDO2/WebAuthn and U2F only | Everyone. This is the default. |
| YubiKey 5 Series | From $58 | Adds smart card (PIV), OTP, and OpenPGP | Users who also need certificate-based auth, or one key across many systems |
| YubiKey 5 FIPS Series | From $88 | Multi-protocol, FIPS 140-2 or 140-3 validated | Only where FIPS validation is a stated contractual or regulatory requirement |
The honest tradeoff on the $29 key is that it is FIDO-only. No smart card, no PIV certificates, no OTP, no OpenPGP. If you have a roadmap toward certificate-based authentication, or you want one key that also unlocks a workstation and signs code, you need the 5 Series. For moving a user off SMS and onto a phishing-resistant passkey — which is the problem in front of you — the $29 key is complete.
And it does not cost you the enforcement benefit. The Security Key models appear in Microsoft’s FIDO2 attestation table with their own AAGUIDs, so you can enforce attestation and restrict registration to those approved models on the cheap keys just as readily as on the expensive ones.
Budget one key per user
You will find advice telling you to issue every user a primary and a backup key. For most organizations that is a waste of half your hardware budget.
One key per user is the realistic number, administrators included. When someone loses a key, your IT staff issue a Temporary Access Pass, the user enrolls a replacement, and you revoke the old credential. That is a ten-minute task on a process you have to build anyway. Buying a second key for every employee to avoid a procedure you already own is paying twice for the same insurance.
The exception is break-glass emergency access accounts. Give those their own FIDO2 keys, store them in a physical safe, and exclude those accounts from your Conditional Access policies — so that a misconfigured policy, an expired certificate, or a federation outage can never lock you out of your own tenant. That is two or three keys total, not one per head.
So the honest budget for a 50-person company is 50 keys plus two or three for the safe — roughly $1,500 at $29 each, once, for a credential that survives phone upgrades and lasts years. Add a small buffer of spares on the shelf for losses and new hires, which is stock management rather than a per-user line item.
One caveat worth naming: this only works if the re-enrollment path genuinely exists. A single key per user is the right call because you have built the Temporary Access Pass process and trained the help desk on identity verification. Skip that work and issue one key per user anyway, and the first lost key becomes an outage instead of a ticket.
Order the right connector — USB-A or USB-C — for the machines your people actually use, and check whether Yubico will ship directly to individual home addresses for your remote staff. Distribution logistics, not budget, is what usually stalls these rollouts.
The migration plan
1. Enable passkeys and decide your populations. Split your users into groups: general office staff on managed devices (Windows Hello for Business plus Authenticator), everyone the phone plan does not fit (hardware keys), and privileged and break-glass accounts (hardware keys, no exceptions).
2. Order hardware now. Lead times, connector types, and the reality of getting a physical object into the hands of a remote employee are the long pole in this project. Everything else is configuration.
3. Run a registration campaign, not an announcement. Under Entra ID → Authentication methods → Registration campaign, set the state and target the security group you built in step one. Prompting users during sign-in works; an email asking them to visit a portal on their own time does not. Start it before September 1 so your users see the prompt in a context you have prepared them for rather than as an unexplained surprise.
4. Fix the recovery path before you remove SMS. This is the step people skip and the one that generates every difficult phone call. Today, when someone loses their phone, a text to a backup number is usually the fallback. Take that away with nothing behind it and every lost or broken device becomes a ticket that ends in an identity verification your staff are not trained to perform. Microsoft’s mechanism is Temporary Access Pass — a time-limited code an administrator issues so a user can register a new method. Turn it on, and write the verification procedure your help desk will follow before issuing one. Make sure that procedure is stronger than “the caller knew the employee’s start date.” Help desk social engineering is how several of the past few years’ most expensive breaches began, and it gets easier for the attacker during exactly the kind of disruption a badly run migration produces.
5. Deal with the accounts that do not fit the pattern. Break-glass emergency access accounts — check what methods they hold right now, make sure none of them is about to be retired, move them onto dedicated FIDO2 keys in a safe, and confirm those accounts are still excluded from your Conditional Access policies. Service accounts and anything non-human — these belong on managed identities or certificate-based authentication, not on a user MFA method, and this is a reasonable moment to fix that if they are not. Guest and B2B users are in scope for the retirement, though Microsoft says passkey support for them arrives by the end of this year.
6. Communicate it as an operational change, not a security lecture. Tell people what will look different, when, and what they need to do. A passkey registration prompt appearing without warning looks exactly like a phishing attempt — and the security-aware users you trained best are the ones most likely to refuse it and call you. Microsoft publishes end-user templates at aka.ms/mfatemplates that are a reasonable starting point.
7. Only evaluate a telecom provider if you genuinely need one. If a specific regulation or operational scenario forces you to keep SMS or voice, you can contract a provider through the Microsoft Security Store once configuration opens on October 30, 2026. Treat it as a documented exception for a named population with the requirement written down — not as a way to defer the migration. SMS does not become less interceptable because a different carrier delivers it, and now you are paying per message for the privilege.
If you need more time
There is a temporary opt-out, and it is worth knowing about even if you do not use it. Setting passkeyDynamicMigration to true on the authentication methods policy via Microsoft Graph excludes your tenant from the automatic passkey enablement and the registration campaign between September 1, 2026 and February 1, 2027.
PATCH https://graph.microsoft.com/beta/policies/authenticationmethodspolicy
Content-Type: application/json
{
"optOutSettings": {
"passkeyDynamicMigration": true
}
}
Use this if you have a real plan on a different schedule — a hardware key rollout mid-flight, or a telecom provider you are standing up. Do not use it to avoid thinking about the problem. The February 1, 2027 enforcement applies regardless of this setting, and all it buys you is a quieter autumn followed by the same deadline with less runway.
The part that actually matters
The technical work here is a policy change and a registration campaign. Neither is hard, and neither is what determines the outcome.
What determines the outcome is the account recovery process you build to replace SMS, and whether your users understand what is happening before their sign-in changes underneath them. Get those two right and February 2027 passes without anyone noticing. Get them wrong and you will spend that week verifying identities over the phone, under pressure, for a queue of locked-out people — which is the single best environment an attacker calling your help desk could ask for.
Run the usage analyzer this week. You cannot plan the work, order the hardware, or budget the help desk time until you know how many people this touches.
If you want help scoping or running the migration, get in touch. We do this work directly for organizations and for other MSPs under their own brand.
Sources: Passkeys by default and retirement of Microsoft-provided SMS and voice authentication · SMS and voice retirement FAQ · Microsoft Entra ID attestation for FIDO2 security key vendors · Microsoft Security Blog announcement
Need this built rather than read?
We do this work for MSPs under their brand and directly for businesses. Call (912) 225-0483 or send the details.

