TL;DR (for those of us short on time)
The essentials before we get into it:
- From 1 September 2026, passkeys become the default sign-in method in Microsoft Entra ID. If you already have users with SMS or voice call enabled, they get enrolled automatically.
- On 1 February 2027, Microsoft completely shuts down the SMS and voice service it delivers natively. A firm date, not a product suggestion.
- From that date, anyone with SMS or voice as their only MFA method hits a blocking prompt to register a passkey during sign-in. It cannot be disabled and applies to every tenant, no exceptions.
- If you have a genuine regulatory reason to keep using SMS or voice, the door stays open: contract a customer-managed telecom provider through the Microsoft Security Store, available from 30 October 2026.
- There is a temporary opt-out (passkeyDynamicMigration) to buy some room, but it does not exempt you from the February 2027 cutoff: it only delays it.
Below you'll find the full timeline, who it affects, and the steps Microsoft recommends so you don't get caught unprepared. 👇
The headline, no detours
Microsoft has put an expiry date on SMS and voice call as a second authentication factor in Microsoft Entra ID. It's published as an official retirement, with a closed timeline, and the notable part is that the change kicks in on its own even if your organisation touches nothing.
The replacement is passkeys, the phishing-resistant credential Microsoft has been pushing across its whole ecosystem for a while now: Windows, Microsoft Authenticator, personal accounts and now, by force, Entra ID.
Two dates to mark on the calendar right now, because everything else in this article revolves around them:
- 1 September 2026: passkeys become the default sign-in experience.
- 1 February 2027: the SMS and voice delivery service Microsoft provides is retired completely.
In between there are nuances that matter: what exactly gets retired, who can legitimately keep using SMS, and what happens if you do nothing.
What actually gets retired (and what doesn't)
«Microsoft kills SMS» is the easy headline, but it oversimplifies. There are two things here that sound alike and work differently.
The delivery service Microsoft provides
The SMS code or automated call that Entra ID itself sends when a user picks that method for their second factor. Built in, at no extra cost, nothing to contract. That shuts down on 1 February 2027.
An SMS or voice channel run by a third party
If you have a genuine regulatory or operational need, you can contract a telecom provider through the Microsoft Security Store and keep running that channel. Microsoft no longer delivers it, and it's no longer the default for anyone.
Microsoft isn't banning SMS as a concept: it's stopping giving it away built into Entra ID and stopping presenting it as a safe default option. If you still want it, from now on you pay for it and configure it separately, and only for the user segments that genuinely need it.
For everyone else — which will be the vast majority of any organisation — the default becomes passkeys, without anyone having to ask for it.
The full timeline, date by date
This is the table worth keeping handy:
| Date | What happens |
|---|---|
| 1 September 2026 | Passkeys become the default method. Users with SMS or voice enabled are automatically enrolled into a passkey profile and start seeing prompts to register when they complete MFA. |
| 18 September 2026 | Microsoft publishes information about customer-managed telecom providers available in the Microsoft Security Store. |
| 30 October 2026 | Tenants that need to keep using SMS or voice can now select and configure a telecom provider from the Security Store. |
| 1 February 2027 | The SMS and voice service Microsoft provides natively in Entra ID is retired completely. |
| After 1 February 2027 | Users whose only MFA method is SMS or voice get a blocking prompt to register a passkey during sign-in. It cannot be disabled. |
The nuance in the last row is worth catching: the account doesn't just lock out of nowhere. Sign-in itself demands a passkey registration right there to continue. For a user who wasn't expecting anything, that's real friction on an ordinary Monday. Better they handle it on their own terms in September than by force in February.
Why Microsoft is doing this now
The official justification ties this to AI adoption at scale: the more agents, copilots and automations operate under corporate identities, the more expensive an interceptable authentication method becomes, and the more urgent it is for the front door to hold.
The underlying technical reason is older and better known: SMS and voice call were never a particularly strong second factor. SIM swapping, real-time relaying of the code to a phishing site, social engineering against the phone carrier... they've been on the «better than nothing, but the bare minimum» list of any serious security recommendation for years, NIS2's own guidance included.
SMS had been the de facto standard for over a decade, not because it was secure, but because it was the easiest to roll out to an entire workforce. That's exactly what Microsoft is no longer propping up.
Passkeys use public-key cryptography instead of a shared secret travelling over a telecom network. There's no code to intercept and no carrier to trick: either the site requesting authentication is the legitimate one, or the passkey simply doesn't respond. That's what «phishing-resistant» means, and it's the real reason behind the push.
Who it affects and how to find out
It affects you if your organisation uses Microsoft Entra ID and has any user with SMS or voice call enabled, whether in the Authentication Methods Policy (AMP) or in legacy MFA settings. In practice, that includes a considerable share of organisations that have been on Microsoft 365 for several years: SMS has long been the easiest method to switch on and the one that generated the least friction when rolling out MFA at scale.
Microsoft has published a PowerShell script to identify exactly who has them active in your tenant. You need the Global Reader, Authentication Policy Administrator or Security Reader role to run it. It's the real first step, before touching anything: without that list, you're going in blind.
One detail that's easy to miss: if you do nothing before 1 September 2026, those users don't lose MFA. They get automatically enrolled into a passkey profile with every passkey type allowed and start receiving the registration prompt the next time they complete MFA. By default, that prompt can be snoozed an unlimited number of times — in practice, plenty of people are going to snooze it indefinitely. If you'd rather control the pace yourself, the only way is to move those users off SMS or voice in the policy before that date.
How to prepare: the steps that actually matter
Microsoft proposes a five-step plan. It makes sense and doesn't require buying anything new, so here it is, with real dates attached:
-
Right now
Find out who uses SMS or voice
Run the identification script, put them in a security group and decide whether you want to control the pace of the migration yourself or let the 1 September automatic enablement take over.
-
Before 1 September 2026
Enable passkeys and launch the campaign
Turn on the passkey (FIDO2) method in the policy. Launch a registration campaign in Microsoft Managed mode targeted only at the SMS and voice group: it's the most effective way to move people without flooding the help desk.
-
September–October 2026
Communicate in phases, not all at once
Inform people of the change and why it's happening, then walk them through registering a passkey for their device type, and finally remind whoever still hasn't done it. Microsoft has ready-made templates for email, Teams and intranet.
-
If applicable: from 18 September
Assess whether you need a telecom provider
Only for segments with a documented regulatory or operational need. For everyone else, the destination is passkeys, full stop.
-
Before 1 February 2027
Confirm nobody depends solely on SMS or voice
Check the authentication methods activity report. The goal is simple: make sure no user reaches that date with SMS or voice as their only available method.
If you genuinely need to keep using SMS or voice
There are regulated sectors with a legitimate need for an out-of-band channel, or user scenarios where no other method is viable — shared devices, staff without a corporate smartphone, field workforces. Microsoft hasn't closed that door completely, it's moved it.
The route is contracting a customer-managed telecom provider through the Microsoft Security Store: from 18 September 2026 you can review the available options, and from 30 October 2026 you can select, configure and test the provider with a pilot group before rolling it out to everyone.
The underlying difference from today's model: it used to be a free checkbox inside Entra ID; now it's an external provider that you contract, configure and maintain yourself, and only for the user segment that genuinely justifies it. Document the reason properly — which regulation, which specific scenario — because that's the first thing you'll be asked to justify if it ever comes up.
Can you delay it? The passkeyDynamicMigration switch
Yes, there's a pause button, and it's worth understanding exactly what it pauses and what it doesn't.
By updating the authentication methods policy via Microsoft Graph and setting the passkeyDynamicMigration property to true inside optOutSettings, your tenant is excluded from automatic passkey enablement and from the registration campaign rollout during the transition window, from 1 September 2026 to 1 February 2027.
What it actually does is buy you room to get organised before that date, nothing more. 1 February 2027 arrives regardless of whether the switch is on, and no tenant can be excluded from it.
If you still have users on Microsoft-managed SMS or voice that day and haven't configured a provider of your own, they're left unable to complete MFA with that method. The opt-out buys time, it doesn't buy a way around the date.
The mistakes I already see coming
Letting automation run on its own
It works, but without control: users get enrolled, see a prompt they can snooze indefinitely, and a considerable share of them will snooze it all the way to February 2027, when it stops being optional and becomes friction on an ordinary working day.
Confusing «I can never use SMS again» with reality
The customer-managed provider route exists. Before launching an express migration project for everyone, work out whether you actually have a regulated segment that needs it, and treat it separately from the rest.
Treating it as a simple MFA method swap
This is the chance to raise the organisation's overall authentication bar, not just replace one method with another. Privileged roles should end up on hardware-bound passkeys or Windows Hello for Business, not on whatever synced passkey happens to come up first.
In summary
1 September 2026 is when the real change begins; 1 February 2027 is when the door closes. In between there's plenty of room to do it right: identify users, enable passkeys, communicate properly and decide with a clear head whether you genuinely need to keep a telecom channel.
What doesn't pay off is waiting: the sooner you switch on the registration campaign at your own pace, the fewer people will reach February 2027 with the blocking prompt as their first notice of the change.
This ties in directly with the ten families of measures under Article 21 of NIS2, where phishing-resistant multi-factor authentication already appears as an expected control. If you're building your compliance checklist, this migration slots straight into it.
Any questions, I am here. No smoke.
Retirement of Microsoft-provided SMS and voice authentication — Microsoft Learn · SMS and voice retirement FAQ — Microsoft Learn · Passkeys (FIDO2) in Microsoft Entra ID — Microsoft Learn · Plan a passkey deployment — Microsoft Learn · entra-sms-voice-usage-analyzer — GitHub.
This timeline last verified: August 2026. Microsoft has been adding detail to this announcement in several waves; always confirm the exact date against the official source before planning anything on a tight margin.