Passkeys on 1 September: the cases that do not fit

On 25 July we published the timeline for the retirement of SMS and voice in Entra ID, when the announcement was twelve days old. Five days after that post Microsoft published a FAQ that did not exist at the time, and the day after tomorrow the first of the two dates arrives. So this is not the same article again: it is what remains unresolved forty-eight hours before 1 September, and it is almost all edge cases.

Conflict of interest up front: we administer customers' Microsoft 365 tenants and we sell managed workplace, so it makes us money if this worries you. Which is why everything below carries its source, and the source is Microsoft's public documentation. Go and check it yourself.

What happens the day after tomorrow, in one sentence

No session goes down. What changes on 1 September is your tenant's configuration: users enabled for SMS or voice in the Authentication Methods Policy — or in legacy MFA settings — are auto-enabled for passkeys, in a profile allowing all types, and your registration campaign moves to the "Microsoft Managed" state targeting passkeys, with those users already in scope. Next time they complete MFA they get the nudge, and by default they can snooze it indefinitely.

The registration campaign is your policy: you administer it from Entra ID > Authentication methods > Registration campaign. The documentation leaves the only supported way out written in one dry sentence: "If you do not want this to occur, move users out of SMS or Voice in AMP before September 1st". Which is to say, the way to stop the vendor touching your policy is for you to do, within forty-eight hours, the very thing the policy pushes towards. The design makes sense, and we still do not like the mechanism.

The article's milestone table has three rows, not two: 1 September, 1 February 2027 — when Microsoft-provided SMS and voice delivery is retired — and a third describing what happens after that date. Five months between the first and the second. That is the whole runway, and it starts the day after tomorrow.

The bring-your-own-carrier exit has dates of its own

It is worth repeating the qualifier the headline swallows, because it decides what you have to do: what is being retired is the SMS Microsoft delivers. The page title carries the adjective right there in front, Microsoft-provided, and the FAQ confirms that tenants configuring their own carrier "can continue using SMS or voice according to their organization's policies".

What has changed since July is the terms, which now have dates. Information about the carriers is not published until 18 September 2026, and the ability to select and configure one does not arrive until 30 October 2026. The FAQ is honest and vague at the same time about price: yes there is a cost, it varies by provider and region, and it is typically per message depending on volume and geography. Migrating to passkeys, it says, carries no additional cost.

Our reading, flagged as a reading rather than a published fact: this is not a comfortable alternative, it is a narrow fire exit. You are being asked to decide now about an option whose price you will not know for another three weeks and which you cannot contract until late October, with the door closing on 1 February. If your plan is "we will sign up a carrier at some point", between the day contracting opens and the cut-off there is a little over three months to choose a provider, sign and pilot.

The FAQ's "No", and what it says three lines below

The FAQ carries a question titled, literally, "Are customers going to get locked out of their accounts on February 1, 2027?". The answer opens with a "No" and continues like this: they will receive a blocking registration prompt, they will no longer be able to skip it, and they will need to complete passkey registration before they can continue to sign in. The main article repeats it in the same words and adds, in bold and three times across the page, that there is no opt out from that behaviour and that it applies to all tenants.

Technically the "No" is correct: the account is not closed. But for the user, the distinction between "locked out" and "you do not get through until you do one thing" only exists if that thing can be done where they are and with what they are carrying. The salesperson at the airport, the warehouse operator with a company phone that has no biometrics set up, the admin who signs in from a shared machine: for those three, on 1 February a "No" in the FAQ is worth exactly the same as a yes.

Where the work lands: password reset

The retirement is not only about the second factor. The FAQ answers it in one line: the retirement of native SMS and voice "applies across Entra, including SSPR". And it adds the back door in the very next sentence, which is worth not cutting: users can still use SMS and voice if you contract your own carrier through the Security Store. Without one, SSPR by SMS goes with everything else.

It is a short and fairly ugly chain. Anyone who forgot their password and recovered it with an SMS code alone can no longer do so. That user does not call security: they call whoever picks up the phone, on a Monday morning, at the same time as twenty others. And the FAQ itself admits the piece that would close that gap does not exist yet: Microsoft says it is planning to introduce support for password change for users who sign in passwordless, and closes with "more details to come". When a vendor's documentation says that five months before the cut-off, it is not a feature: it is an intention.

Who is not in this, and the guest gap

It is also worth saying who this does not affect, because there are plenty of people worried for no reason. The timeline covers public cloud only; other cloud environments follow later and Microsoft says it will give advance notice. Azure AD B2C is out of scope and unaffected. Microsoft Entra External ID gets its own announcement next year. And external MFA methods are not in scope, unless the user is also enabled for SMS or voice.

And then there are the guests, who in the FAQ take up two consecutive sentences worth reading together. One: passkey support for B2B users and internal guest users "is planned to be available by the end of calendar year 2026". Two, immediately afterwards: "these users are included in the scope of the retirement". The replacement is planned for December and the door closes in February. If your business runs on collaborating with outsiders — accountancies, engineering firms, anyone with a folder shared with suppliers — that is the box we would look at first, and this week. It is in line with what we wrote about the directory with more records than employees: the problem is almost never your employees, it is the people who are not.

The only urgent thing this week is a number

Everything above is opinion until you know how many users in your tenant are still enabled for SMS or voice. With that number in front of you the decision makes itself: if it is four, this is an afternoon; if it is a hundred and forty, it is a project with user comms and a reinforced support window.

Microsoft publishes a script to pull it, entra-sms-voice-usage-analyzer, in its GitHub organisation. It needs one of three roles active: global reader, authentication policy administrator or security reader. The FAQ boils the scoping test down to one line that works nicely in an internal email: any non-zero result means you are in scope.

The exit switch exists, it lives on /beta, and we do not recommend it

There is a temporary opt-out for the stretch between 1 September and 1 February. It is not in the portal: you apply it with a Microsoft Graph call, with the Policy.ReadWrite.AuthenticationMethod permission, setting the passkeyDynamicMigration property to true inside optOutSettings on the authentication methods policy. The endpoint Microsoft documents for that call is /beta.

Two things about that. The first is a matter of craft: writing to /beta means the shape of that call can change without anyone telling you, so if you apply it, record it with a date and an owner and set yourself a reminder to review it in January. The second is our own judgement: use it in two cases only. One, you have already decided, with a date, that you are contracting your own carrier and you just need to reach 30 October. Two, 1 September catches you in the middle of another migration and you cannot add noise to sign-in. Outside those it buys you five months you will not use, and 1 February arrives all the same — except that by then the prompt can no longer be snoozed.

What the documentation does not say and does decide your Monday

We read both pages end to end and there is one thing that appears in neither: break-glass accounts. Those couple of global administrator accounts almost everyone keeps aside for the day conditional access or the identity provider falls over. If any of them has an SMS to a company number as its second factor, that is the first one to move — and we say that as our own judgement, not as a quote: we would rather not discover in February that the account reserved for when nothing works depends on precisely the thing that has just been retired. It is the same idea we wrote about treating the identity provider as infrastructure rather than as one more application.

The other piece missing from the date table is the inventory of who can register a passkey and who cannot. Microsoft supports two families: synced passkeys, which live in a platform credential manager such as iCloud Keychain or Google Password Manager and travel across the user's devices, and device-bound ones, which include the passkey in Authenticator, Entra Passkey on Windows and physical FIDO2 keys. That distinction decides whether the worker on the shop floor needs a hardware key or whether the phone they already carry will do, and also where the credential ends up living: if that second part interests you, we went through what a synced passkey is actually made of at the time. No script is going to build that inventory for you.

Where we stand

On the substance we agree with Microsoft. Their argument is that SMS and voice are "among the most vulnerable authentication methods available today" and protect considerably worse than a passkey against phishing and account compromise; ours is more down to earth and comes from cleaning up incidents: a code that travels to a phone number can be requested down another path, and a second factor that can be requested down another path is not a second factor, it is a formality. We saw it already with the token that never asks for MFA again: what breaks an account is almost never the password.

What does not convince us is the choreography. A date on which the vendor changes a policy in your tenant, an alternative whose pricing is published seventeen days after that date, a contracting flow that does not open until 30 October, a declared gap for guests, and a hard cut-off with no opt-out. All of it is defensible on its own and fairly uncomfortable together, especially for a thirty-person company with nobody working on identity full time. It is the usual asymmetry: the calendar is set by whoever will not be answering Monday's calls.

If you take away one thing from all this: pull the number this week. It is the only thing that cannot wait, and it is also the only thing that turns this conversation into a plan.

Sources (consulted on 30 August 2026): every date, behaviour, property and quoted sentence comes from two pages of Microsoft's official documentation: Passkeys by default and retirement of Microsoft-provided SMS and voice authentication (Microsoft Learn, updated 10 August 2026) and its FAQ (dated 30 July and updated 3 August 2026 — that is, published after our 25 July post). Specifically, from the main article: the milestone table with its three rows — 1 September 2026, 1 February 2027 and the behaviour after that date — the blocking prompt and the three bold statements that there is no opt out; the auto-enablement in the AMP, the profile allowing all passkey types, the registration campaign moving to "Microsoft Managed", the unlimited snoozes and the sentence about moving users out of SMS or voice before 1 September, in the "Important" box; the Entra ID > Authentication methods > Registration campaign path, in step 2; 18 September 2026 for publication of telecom provider information and 30 October 2026 for being able to select and configure one, in step 3; the temporary opt-out with passkeyDynamicMigration, the Policy.ReadWrite.AuthenticationMethod permission and the /beta endpoint, in the temporary opt-out section; the entra-sms-voice-usage-analyzer script with its three roles, in step 1; and the description of the two passkey families. From the FAQ: the "among the most vulnerable authentication methods available today" quote; the per-message cost of a customer-managed provider and the fact that migrating to passkeys adds no cost; the scope across all of Entra including SSPR, together with the sentence immediately after it stating that users can still use SMS and voice through a telecoms provider contracted in the Security Store; the "more details to come" on password change for passwordless sign-in; the public-cloud-only scope; the Azure AD B2C exclusion and the separate External ID announcement; passkey support for B2B planned by the end of 2026 together with the fact that those users are in scope of the retirement; that external MFA methods are not in scope unless the user is also enabled for SMS or voice; the test that any non-zero result means being in scope; and the account lockout question with its "No" answer. These are ours, and we flag them as judgement rather than published fact: that the customer-managed carrier route is narrow because of the order of its own dates; that the real cost of this lands on the service desk by way of SSPR; that the guest gap is the box to check first if you work with outsiders; the recommendation not to use the opt-out outside the two cases named; the warning about writing to a /beta endpoint; and the note on break-glass accounts, which the documentation does not mention on either page.