Every so often Microsoft ships a change that isn’t a new feature you can choose to adopt — it’s a new default that arrives whether you plan for it or not. Message center post MC1426371 is one of those. Microsoft Entra is making passkeys the default sign-in experience and retiring its own SMS and voice authentication delivery, and the announcement comes with dates attached. That last part is what turns it from interesting reading into a project. When a change has a calendar, the only question left is whether you meet it deliberately or get met by it.

What’s Actually Being Announced

Two things are happening at once, and it helps to separate them.

The first is a posture shift: passkeys become the default authentication experience for Microsoft Entra ID. Microsoft’s framing is blunt — as the industry moves to phishing-resistant authentication, SMS and voice are “no longer positioned as secure authentication methods.” They’re the credentials most exposed to phishing, SIM-swap, and interception, and Microsoft is done presenting them as a front-line option.

The second is a retirement: Microsoft will stop providing the native telecom delivery behind SMS and voice MFA. This is the part that can actually break a sign-in. If a user’s only MFA method is a text or a phone call, and nothing changes on your side, that method eventually stops working.

Here’s the calendar that matters:

  • September 1, 2026 — Passkeys are automatically enabled for users currently enabled for SMS or voice. Registration campaigns begin nudging those users toward passkeys during sign-in.
  • September 18, 2026 — Information on customer-managed telecom providers becomes available to review in the Microsoft Security Store.
  • October 30, 2026 — Customers who genuinely still need SMS or voice can select and configure a third-party telecom provider through the Security Store.
  • February 1, 2027 — Microsoft-provided SMS and voice delivery is retired. Tenants that haven’t stood up a customer-managed provider can no longer use those methods for MFA.

One reassurance worth stating plainly, because it’s the first question a client asks: passkeys carry no additional cost. They’re available in every Microsoft Entra ID edition, including Free, with no extra licensing. The thing Microsoft is pushing you toward is the thing that’s already included.

The Part That Changes Without You

The word “default” is doing heavy lifting in that announcement, and it’s worth being precise about what moves on its own versus what waits for you.

On September 1, users who are enabled for SMS or voice in the Authentication Methods Policy get auto-enrolled into a passkey profile that allows all passkey types — synced and device-bound both. At the same time, your Registration Campaign is switched to Microsoft-managed state, targeting passkeys, and those users are pulled into scope automatically. The next time they sign in and clear MFA, they get nudged to register a passkey.

Read that carefully, because there’s a sharp edge in it. Under Microsoft-managed state, the default snooze behavior is unlimited — users can dismiss the nudge indefinitely. So the automatic path gets your users prompted, but it does not get them migrated. A tenant that does nothing but let September 1 happen will have a lot of users who saw a passkey prompt, clicked “skip,” and are still sitting on SMS the morning of February 1. The auto-enablement solves the awareness problem and leaves the completion problem entirely on the table.

That gap — nudged but not moved — is the whole reason this needs an owner rather than a calendar reminder.

The Two Decisions Every MSP Has to Make

Strip the announcement down and each tenant you manage needs two calls made about it.

Decision one: who, if anyone, genuinely still needs telephony? Microsoft’s recommended answer for almost everyone is “nobody — move them to passkeys.” But there are real exceptions: a regulated industry with a compliance regime that mandates an out-of-band SMS channel, or a workflow where no other method is workable. For those specific, documented segments, the path is a customer-managed telecom provider from the Security Store — which means a carrier contract, per-message costs, and a pilot before you trust it. For every other user, the answer is passkeys, and the sooner you commit to that, the less telecom you’re paying to keep alive. The discipline here is to make this a deliberate, per-segment decision with the regulation or reason written down, not a reflex to preserve SMS because it’s familiar.

Decision two: do you drive the migration, or let Microsoft-managed drive it? This is the one I’d push a colleague hardest on. Leaving the Registration Campaign in Microsoft-managed state means the targeting and snooze behavior on a client tenant can shift as Microsoft rolls changes out — no change window, no notice you control. For an MSP managing many tenants, that’s exactly the kind of silent drift that turns into a support surprise. Setting the campaign to Enabled and configuring it yourself — targeted method, snooze duration, a real snooze limit so users actually complete registration — trades a little setup for predictability. You decide when the pressure ramps and when registration becomes mandatory, instead of finding out after the fact.

The Gotcha Hiding in the Admin Accounts

There’s a trap in this rollout that catches precisely the people who did the responsible thing, and it deserves calling out on its own.

If you’ve hardened your admins’ passkey profile — device-bound only, attestation enforced, or an AAGUID allow-list restricting them to approved security-key models — then under Microsoft-managed mode those users don’t get the passkey nudge at all. The registration campaign silently skips anyone whose profile carries those restrictions. So the exact accounts you most want on phishing-resistant credentials — the privileged ones — are the accounts the automatic path quietly leaves behind.

The fix isn’t to weaken the admin profile. It’s to recognize that the nudge was never going to be the mechanism for those users, and drive them a different way: issue Temporary Access Passes to bootstrap registration and enforce phishing-resistant sign-in with a Conditional Access authentication strength. Hardened profiles and the auto-campaign don’t cooperate — so admins get a deliberate, TAP-plus-Conditional-Access rollout while general staff ride the campaign. Two populations, two mechanisms, one outcome.

Why I Already Had the Runbook Written

The reason MC1426371 didn’t send me scrambling is that the mechanics underneath it — passkey profiles, the device-bound versus synced distinction, the registration campaign and its snooze logic, the attestation and AAGUID interactions, the TAP bootstrap for accounts with no credential to start from — were already written down before the announcement landed. A message center post tells you what is changing and when. It doesn’t hand you the click-by-click, the Graph payloads, or the two-profile pattern that keeps admins hardened while everyone else migrates. That’s the difference between reading the news and being ready for it.

So the deep version — every prerequisite, the portal and Microsoft Graph method for each step, the profile design that separates admins from staff, the snooze behavior in detail, and the Conditional Access enforcement that turns a nudge into a requirement — lives in my knowledge base as a runbook I can execute against a client tenant instead of rebuilding from memory under a deadline:

→ Microsoft Entra: Passkey (FIDO2) Policy and Registration Campaign — part of my open MSP Microsoft 365 knowledge base on GitHub.

The announcement is the alarm; the runbook is the plan. And the plan comes down to something simple enough to hold in your head: passkeys are free and arriving by default, the nudge alone won’t finish the job, and February 1, 2027 is the date the safety net under SMS and voice gets pulled. The tenants that sail through it are the ones whose MSP treated September 1 as the start of a migration they were driving — not the day the migration started happening to them.