Passkeys became the Entra ID default on September 1, 2026

On September 1, 2026, Microsoft began making passkeys the default authentication experience in Microsoft Entra ID. Most coverage of this leads with the ending — Microsoft-provided SMS and voice authentication retires on February 1, 2027. That date matters, and we will get to it. But it is not what is happening in your tenant this month.

The event already underway is enrollment, and it reaches users before it reaches your project plan.

What Microsoft actually said

From the Microsoft Security Blog, written by Nadim Abdo, Corporate Vice President for Identity and Network Access Engineering:

“Beginning September 1, 2026, Microsoft will begin rolling out passkeys as the default authentication experience in Microsoft Entra ID.”

And the sentence that decides how your week goes:

“users enabled for SMS or voice authentication will automatically be enabled for passkeys, and the next time they perform multifactor authentication, they’ll be prompted to register a passkey.”

Read that as an operator. There is no announcement step in it. A user who has been receiving a code by text for four years signs in on Tuesday exactly as they always have, and is asked to register something they have not heard of. Some will do it. Some will call you. A few will assume it is phishing — which, given that we have spent a decade training them to be suspicious of unexpected authentication prompts, is arguably the correct instinct and the wrong outcome.

The first instinct is to block it, and that is the trap

The question being asked in MSP forums this week is how to stop new passkey registrations. It is an understandable reaction to an unannounced prompt, and it buys you a quiet week.

Here is what it does not buy. Microsoft’s own statement on the ending:

“on February 1, 2027, Microsoft will retire Microsoft-provided telecom delivery for SMS and voice authentication and will no longer offer SMS and voice as a native Microsoft Entra capability.”

And, directly: “There will be no opt-out option.”

So suppressing the prompt does not remove the work. It moves it — out of September, when a user who is confused can be walked through registration by someone who has time, and into February, when the same user cannot complete an authentication at all. You are choosing between a supported enrollment and an unsupported one. The prompt is not the problem. The prompt is the last cheap opportunity to do this deliberately.

If you need breathing room, use the control Microsoft built for it rather than an exclusion group. Microsoft documents that “a temporary opt-out is available for the September 1, 2026 through February 1, 2027 changes,” so you can “delay passkey and Registration Campaign enablement while you complete transition activities, such as configuring a telephony provider or migrating to other authentication methods.” It is set in the Microsoft Graph beta authentication methods policy (optOutSettings.passkeyDynamicMigration) and needs the Policy.ReadWrite.AuthenticationMethod permission. Read the end date as carefully as the start: “Beginning February 1, 2027, standard passkey migration and enforcement timelines apply regardless of this setting for users in scope of the February 1 retirement.” The opt-out buys time to do the work. It does not remove the work.

If SMS is genuinely load-bearing for you

Some organisations have a real reason to keep a telephony factor — a regulated workflow, a shared-device floor, a population without enrolled hardware. Microsoft’s own framing of who that is: “Use a telephony provider only for user populations that have a business, regulatory, or technical requirement for telephony-based authentication.” Otherwise, Microsoft “recommends phishing-resistant authentication methods, such as passkeys, instead of SMS or voice.”

Microsoft has now published the telephony-provider detail it said in July it would share later. It is a private preview, not a feature you can turn on today:

“Choose Your Own Telephony Provider isn’t available to configure yet. Information about the providers participating in the private preview is available now. The configuration experience becomes available beginning October 30, 2026.”

The initial providers are named, with more promised later:

“Soprano and Telesign are the initial telephony providers available during the private preview. More providers will become available by general availability.”

On cost, Microsoft Learn prints no figures — only variables, and a pointer to each provider’s Security Store offer: “Pricing varies by telephony provider and region. Costs depend on your usage, geographic distribution, selected provider, and offer.” Soprano’s own listed offer structure, per Microsoft, is a “per-user offer or per-transaction offer in Microsoft Security Store” — a billing model, not a price. If that describes you, put October 30 in the calendar as the date the configuration experience opens — and treat an actual quote, not this post, as the thing you still need before you can budget.

What we would do this week

• Find out who is still on SMS or voice. Not a headcount — a list. Those are the users who get the prompt, and they are the ones who will call. In most mid-market tenants this is a much larger group than anyone expects, because SMS was the fallback that quietly absorbed everyone who could not be made to work with the app.
• Tell them before Microsoft does. Two sentences in an email, sent in advance, turns an alarming prompt into an expected one. This is the single highest-leverage thing available and it costs nothing.
• Decide about your shared and frontline accounts on purpose. A passkey is bound to a device or a security key. Accounts that are used by shifts rather than by people are where this stops being a communications exercise and starts being an architecture decision.
• Do not let “we blocked it” become the plan of record. If registration is being suppressed, write down the date it gets unsuppressed and who owns that. A temporary measure with no expiry attached is how February arrives as a surprise.
• If telephony is genuinely required, read the provider detail before October 30. Soprano and Telesign are the named private-preview providers, and pricing depends on provider, region, usage, and offer — not a number you can budget without a quote.

Update — September 2026: the rollout is now the pretext

Four days after we published this post, Microsoft’s own security researchers described a live social-engineering campaign that uses exactly the story a passkey rollout makes believable. From the Microsoft Security Blog, September 9, 2026:

“The attack often begins with a seemingly routine call or message on a user’s personal phone number from someone claiming to be from the organization’s IT helpdesk. The caller creates a sense of urgency, explaining that a passkey, multifactor authentication (MFA), or single sign-on (SSO) configuration must be updated immediately to avoid disruption.”

Microsoft ties the initial-access activity to named threat actors:

“Microsoft Threat Intelligence assesses that the initial access activity observed in this campaign is used by a range of threat actors, including Storm-3121, Storm-3032, and others. Storm-3121 conducts initial access activity leading to ShinyHunters and Falcon extortion.”

And it assesses the pattern behind the calls as automated, not one-off:

“Microsoft Security Research assesses that this sequence is consistent with automated collection from compromised cloud identities using proxy-associated infrastructure, the activity has been observed since May 2026.”

The domains Microsoft lists as observed in the campaign read like the legitimate prompt this post opened with: passkeyhelpdesk[.]com, add-passkey[.]com, setupmypasskey[.]com.

To be precise about what Microsoft did and did not say: its report does not attribute this campaign to the Entra passkey default rollout, and does not name the rollout as a cause. The activity has reportedly been observed since May 2026 — months before the September 1 default took effect. What follows is our read, not Microsoft’s finding: a tenant mid-rollout is a more believable target than one that isn’t, because a “your passkey configuration needs to be updated” call lands differently on a user who received a real Microsoft passkey prompt at their last sign-in than on one who has never heard the word. The rollout does not create the attack. It removes the one thing that used to make the pretext implausible.

The downgrade point: why a live SMS fallback keeps this attack path open

This connects directly to the retirement date already in this post. CloudSEK research, as reported by BleepingComputer on September 7, 2026, describes a phishing kit built to defeat passkeys rather than impersonate them:

“A phishing-as-a-service framework called BigBear 2.0 has been used to bypass multi-factor authentication at 258 organizations and steal more than 5,000 Microsoft 365 credentials.”

“CloudSEK has also found that BigBear uses custom JavaScript that interferes with FIDO2/WebAuthn authentication, disabling the browser functionality that accommodates it to force targets toward weaker authentication methods.”

Read those together and the design goal is plain: do not beat the passkey, break the browser’s ability to offer one, and push the user toward whatever weaker method is still available — a password, a code, a push approval. That only works if a weaker method is still enrolled. Every account still on SMS or voice — the population this post opened with — is the population that downgrade has somewhere to land. BleepingComputer’s write-up recommends:

“It is also advisable to enforce phishing-resistant FIDO2/WebAuthn and use Conditional Access policies that require managed devices rather than relying on geo-location signals.”

A second visible sign-in change this month: system-preferred authentication

One more moving part is worth naming, because it produces its own round of “my sign-in changed” tickets, separate from the registration prompt. Microsoft Learn’s documentation on system-preferred authentication (dated September 1, 2026, updated September 2) describes a Microsoft-managed default rolling out on the same timeline:

“The Microsoft managed state behavior affects both first-factor and multifactor authentication and is being gradually deployed to tenants through September 2026.”

What it does:

“Microsoft managed - System-preferred authentication applies to both first-factor and second-factor authentication. The system evaluates which credentials are registered for the user and selects the highest-ranked method…”

And concretely, once a user has registered a passkey:

“…prompts the user to sign in with the passkey instead of the password. The user can still choose to sign in by using another method, but they’re first prompted to try the most secure method they registered.”

The practical implication is ours, not Microsoft’s: once a user completes the registration prompt this post already covers, their sign-in screen itself can change — from a password box to a passkey prompt — on any tenant left on the Microsoft-managed default. That is a second visible change landing on the same users in the same window. It has nothing to do with the helpdesk-impersonation risk above, but it will generate its own tickets in the same week. If you would rather control the timing, Microsoft documents the lever:

“If you don’t want to enable system-preferred authentication, change the state from Microsoft managed to Disabled, or exclude users and groups from the policy.”

Update — September 26, 2026: telephony providers named, second retirement date added

Three things have changed since this post’s original FAQ said Microsoft’s telephony-provider detail “is not published yet.” The telephony-provider detail and a second retirement date are below; the third is Microsoft’s documented temporary opt-out, covered in the section on blocking above. All three affect how you plan the transition, not whether it happens.

Choose Your Own Telephony Provider is named — and it is a private preview, not a live feature

Microsoft Learn’s dedicated page on the topic, updated September 23, 2026, replaces the earlier placeholder with specifics:

“Choose Your Own Telephony Provider isn’t available to configure yet. Information about the providers participating in the private preview is available now. The configuration experience becomes available beginning October 30, 2026.”

The initial providers, per the same page:

“Soprano and Telesign are the initial telephony providers available during the private preview. More providers will become available by general availability.”

Soprano’s listed offer structure is a billing model, not a price: “Per-user offer or per-transaction offer in Microsoft Security Store.” On cost generally, Microsoft’s FAQ page (also updated September 23, 2026) now reads: “Pricing varies by telephony provider and region. Costs depend on your usage, geographic distribution, selected provider, and offer.” No figures are published for either provider. Treat October 30 as the date the configuration experience opens — not the date you have a number to budget.

Microsoft’s own framing of who should bother configuring one at all has not changed: “Use a telephony provider only for user populations that have a business, regulatory, or technical requirement for telephony-based authentication.” For everyone else, Microsoft still recommends passkeys.

Global Administrators and external users get a later retirement date

Microsoft’s SMS and voice retirement pages, also updated September 23, 2026, add a second date this post did not previously carry:

“Global Administrators and external users follow a later retirement date of July 1, 2027. Internal guest users aren’t included in that July 1 group and still follow the February 1, 2027 retirement date.”

February 1, 2027 remains the retirement date for your general user population — everything earlier in this post about that date stands. The July 1 date is narrower: it applies only to Global Administrators and external users; internal guest users stay on the February date. If your admin accounts or your B2B guest population are still on SMS or voice, that is five extra months on the calendar for those two groups specifically, not for the tenant as a whole.

What your helpdesk should never do — and never be asked to do

This is a generic checklist, not a Pro IT NW product claim. It holds regardless of who runs your helpdesk.

• Never register or re-register an authenticator from a link sent during a call or chat. A legitimate registration happens inside Entra ID’s own flow, started by the user — not pushed to them mid-conversation.
• Never read a verification code back to someone who called or messaged first. A code exists to prove the person on the authenticating device is who they say they are; reading it out defeats the entire mechanism.
• Never approve a sign-in prompt the user didn’t start. An MFA push that appears unprompted is a signal to deny and report, not to approve because someone on the phone says it is expected.
• Tell users, in advance and in writing, that IT will not call about passkeys. Removing the pretext before a user hears it from an attacker is the cheapest defense available.
• Give users a way to verify inbound “IT” contact — a callback number they already have, a ticket number they can check — rather than trusting caller ID or a name.
• Know where Temporary Access Pass issuance sits in your process. A TAP is a legitimate, time-boxed way to get a locked-out or newly-enrolling user back in — and it is also exactly what a convincing impersonation call is trying to get issued on its behalf. It belongs behind the same verification step as everything else on this list, not treated as a routine unlock.

Why this one is worth the attention

Most lifecycle items on this blog are dated, quiet and reach you through an admin centre. This one is different in a specific way: it reaches your users first, on Microsoft’s schedule, during an action they were already taking. The retirement in February is the headline, and it is the part every vendor newsletter will cover in January. The enrollment happening right now is the part that generates tickets, and it is happening whether or not it is on anyone’s roadmap.

That is the whole argument for spending an hour on it in September rather than a week on it in February.

Related reading

• The other Entra ID deadline this quarter: Entra Connect sync stops Sept 30: the version trap.
• Why identity changes get Tier-0 treatment: AD Tier-0 in 90 days: mid-market edition.
• Service detail: Entra ID and hybrid identity.

Sources

Quotations in the original post come from the Microsoft Security Blog post “Microsoft Entra ID security updates: Passkeys are the default authentication method in Entra ID”, published July 13, 2026 by Nadim Abdo, Corporate Vice President, Identity and Network Access Engineering — read it in full. Dates and wording are as published on that page. The original post noted that the announcement described no tenant delay mechanism; Microsoft Learn has since documented a temporary opt-out, covered above.

The September 2026 update above draws on three further sources, quoted as published:

• Microsoft Security Blog — “Passkey-themed social engineering leads to identity and cloud compromise” (September 9, 2026)
• Microsoft Learn — System-preferred authentication for Microsoft Entra authentication methods (dated September 1, 2026; updated September 2, 2026)
• BleepingComputer, reporting CloudSEK research — “BigBear Microsoft 365 phishing service bypassed MFA at 258 organizations” (September 7, 2026)

The September 26, 2026 update above draws on three Microsoft Learn pages, quoted as published, each updated September 23, 2026:

• Microsoft Learn — SMS and voice retirement FAQ (updated September 23, 2026)
• Microsoft Learn — Microsoft-managed SMS and voice retirement (updated September 23, 2026)
• Microsoft Learn — Choose a telephony provider for SMS and voice authentication (updated September 23, 2026)

If you would rather have the affected-user list, the advance communication and the shared-account decision handled as a bounded piece of work, scope it with us.