Passkeys became the default on 1 September, and your snooze button does not move the deadline
Entra ID auto-enabled SMS and voice users for passkeys. The registration prompt can be snoozed indefinitely, but on 1 February 2027 it turns blocking, and internal guests are not covered by the July extension.
Microsoft Entra ID is making passkeys the default sign-in experience and is retiring Microsoft-provided SMS and voice authentication. Microsoft no longer positions SMS and voice as secure authentication methods.
The timeline
| Date | What happens |
|---|---|
| 1 September 2026 | Users who were enabled for SMS or voice are automatically enabled for passkeys and nudged to register one at sign-in. |
| 18 September 2026 | Information about customer-managed telecom providers becomes available. |
| 30 October 2026 | From this date you can select and configure a telecom provider through the Microsoft Security Store. |
| 1 February 2027 | Microsoft-provided SMS and voice is retired for all users except Global Administrators and external users. |
| 1 July 2027 | Microsoft-provided SMS and voice is retired for Global Administrators and external users as well. |
What already happened on 1 September
Users who were enabled for SMS or voice in the authentication methods policy or in legacy MFA settings were placed into a passkey profile that allows every type of passkey.
At the same time the registration campaign was set to Microsoft Managed with passkeys as the target, which automatically brought those users into scope. At their next sign-in with MFA they are prompted to register a passkey.
By default users may snooze that prompt an unlimited number of times. If you did not want this, those users had to be moved out of SMS or voice in the policy before 1 September.
What happens after the retirement date
If a user's only MFA method after their applicable retirement date is SMS or voice, the registration prompt becomes blocking. They cannot sign in without registering a passkey first.
The documentation is explicit about this: there is no opt out from that behaviour.
Watch out for internal guests
The 1 July 2027 date applies to Global Administrators and external users.
Internal guest users are explicitly not included in that group. For them 1 February 2027 applies, the same as for ordinary users.
The temporary opt-out and what it does not do
A temporary opt-out exists for the period from 1 September 2026 to 1 February
2027. It requires the Graph permission Policy.ReadWrite.AuthenticationMethod:
PATCH https://graph.microsoft.com/beta/policies/authenticationmethodspolicy
Content-Type: application/json
{
"optOutSettings": {
"passkeyDynamicMigration": true
}
}
This excludes your tenant from the automatic passkey enablement and from the registration campaign. From 1 February 2027 the standard timelines apply again regardless of this setting. For enforcement itself there is no opt out.
What to do now
Start by counting. Microsoft provides a PowerShell script to find which users are enabled for SMS or voice, and you need the global reader, Authentication policy administrator or Security reader role to run it.
Put those users in a security group and point your communications and your registration campaign at it. Then run the same count separately for your guest users, because they fall under the early date.
If you have a demonstrable regulatory or operational reason to keep a telecom channel, document which regulation and which scenario it covers, and treat 30 October as the start date for selecting a provider.
Should you care?
- Yes if: You have users doing MFA with SMS or a phone call
- Yes if: You have B2B guests in your tenant
- Yes if: You operate in a sector that mandates an out-of-band telecom channel
- Yes if: You manage the authentication methods policy
- Skip it if: Everyone in your tenant is already on passkeys, Windows Hello for Business or FIDO2
- Skip it if: You have already removed SMS and voice from the authentication methods policy
Architecture areas
Security/Identity and access/Administration
Recommended action
PrepareStart by counting how many users are still on SMS or voice, because that number decides whether this is a communications exercise or a project. If you are in a regulated sector that mandates a telecom channel, put 30 October 2026 in your calendar: you cannot configure a provider before then.
The uncomfortable thing about this change is that it has already happened. On 1 September 2026, users who were enabled for SMS or voice in the authentication methods policy or in legacy MFA settings were automatically enabled for passkeys, in a profile that permits every type of passkey, and the registration campaign was set to Microsoft Managed with passkeys as the target. That was three weeks ago. If you did not notice, that is not negligence but precisely the design: by default the prompt users receive can be dismissed an unlimited number of times. That is where the trap sits. A change that breaks nothing and a prompt you are always allowed to ignore together produce exactly zero signal. Your monitoring shows no disruption, your service desk gets no tickets, and your adoption figure barely moves, because the path of least resistance is to dismiss and carry on. Until 1 February 2027 that is entirely true, and from 1 February 2027 it stops being true all at once: anyone left with only SMS or voice gets a blocking registration prompt and cannot get past it without a passkey. The curve of this problem is flat and then vertical, and flat curves are bad at attracting attention. Then the opt-out, which I think will be misread most often. There is a temporary escape through Graph where you set passkeyDynamicMigration to true. It removes your tenant from the automatic passkey enablement and from the registration campaign. What it does not do is postpone the retirement. From 1 February 2027 the normal timelines apply regardless of that setting, and the documentation says it in capital clarity: there is no opt out for enforcement. The property name suggests control over a migration, but what you buy with it is quiet, not time. Anyone switching it on to make room for a careful rollout is doing something sensible; anyone switching it on because this is inconvenient right now has disabled their only warning signal and still owns the deadline. The detail that will cause the most damage sits in a subordinate clause about guests. The deferred date of 1 July 2027 applies to Global Administrators and external users. Internal guest users are explicitly not part of that group and fall under 1 February 2027. Anyone reading quickly files guests under external users, because that is how we talk about them. That is exactly the wrong direction: B2B guests are often the population most likely to be on SMS, because they were never issued a company phone with Authenticator, and at the same time the population your communications campaign reaches worst, because they do not read your intranet and may not even be in your distribution lists. If there is one group where this goes quietly wrong and surfaces as partners who cannot reach your portal on a Monday morning, it is this one. And finally the escape route for anyone who genuinely must keep SMS. It exists, through a telecom provider from the Microsoft Security Store, but you cannot select and configure one until 30 October 2026. Between that date and 1 February 2027 sit three months in which you have to select a vendor, sign a contract and run a pilot. For an organisation that has to tender a carrier through procurement, that is not a generous schedule. So the date that belongs in your calendar is not February but October.