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 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 has said third-party telecom providers will be supported, but the operative detail is not published:

“On September 18, 2026, we’ll share information on supported providers, deployment guidance, and technical documentation with pricing and commercial terms available through the Microsoft Security Store.”

Note what that sentence is and is not. September 18 is a date for information, not a date something is available to deploy. It also names pricing and commercial terms, which means a capability that is free today becomes a line item at some point between then and February. If that describes you, put September 18 in the calendar and read it the same day — because everything downstream of it, including whether you need a budget conversation, starts there.

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.
• Read September 18 if telephony is genuinely required, and treat commercial terms as part of the answer rather than a detail.

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.”

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.

Sources

Every quotation above comes 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. Where we have characterised something as absent — a documented tenant delay mechanism — that means absent from that announcement, which is not the same as ruled out.

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)

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.