Microsoft has announced that passkeys will become the default authentication method for Entra ID from September 2026. AWS and Google both support passkeys already. The open question is whether either follows Microsoft in making them the default rather than the recommendation.
Either way the direction is now unambiguous. Passkeys are moving from an optional security upgrade towards something that will increasingly be expected as standard, and the interesting consequences are operational rather than cryptographic.
The default is the whole story
Support for a control and defaulting to a control are different products. Support means a motivated security team can turn it on for a pilot group and spend two years arguing about the rollout. A default means every tenant that has not made an explicit decision now has the control, and every helpdesk process built around the old assumption meets it at once.
Defaults move populations. They also move the attacker's attention, because once the authentication method itself is phishing-resistant, the profitable target is no longer the login. It is everything wrapped around the login: how a credential gets created, and how someone gets back in when they lose it.
The campaign already running
Okta's threat intelligence team has documented exactly that. A threat actor it tracks as O-UNC-066 is running a panel-controlled phishing kit aimed specifically at Microsoft 365 users, and the target is passkey enrolment.
The method is unglamorous and effective. The actor registers domains containing the word "passkey", then telephones users to talk them through registering a new one. Victims are directed to a kit that closely reproduces Microsoft's real passkey enrolment flow. While the user believes they are registering their own credential, the actor simultaneously registers a passkey it controls against the user's genuine Microsoft account. The user ends up with a working login. The attacker ends up with durable access that survives a password reset.
Note what is not happening here. Nobody has broken WebAuthn. The cryptography did exactly what it promised. The attacker went around it by inserting themselves into the process that issues credentials, using a phone call and a convincing form.
A phishing-resistant authentication method sitting on top of a persuadable enrolment process is not phishing-resistant.
Why enrolment and recovery keep being the gap
Most organisations designed their enrolment and recovery processes when the credential being enrolled was a password or a soft token, and the cost of getting it wrong was one resettable secret. Passkeys change that calculation. A passkey the attacker controls is not a secret you can rotate away, it is an authorised authenticator sitting in the account's credential list, and it will keep working until someone notices it is there and removes it.
That makes credential inventory an operational requirement rather than a nice-to-have. If nobody can answer "how many authenticators are registered to this account and when did each appear" in under a minute, the account has no meaningful audit trail.
It is also worth noticing that this pattern is not confined to one campaign. In the same fortnight, ReliaQuest published research on a group calling itself Helix which combines vishing, device-code phishing and MFA abuse to reach Microsoft 365 SharePoint data, and one of its first moves after gaining access is to register its own authenticator app. Two unrelated actors, same instinct: get a credential you own into the account as early as possible.
Have these four answered in writing
How does a new credential get registered? Name the exact paths, including the helpdesk-assisted one nobody documented.
What proofing is required? And is it proofing, or is it a caller who knew an employee ID?
Who is alerted when a new credential appears? The account holder, the security team, both, or in practice nobody.
What happens when someone is locked out? Recovery is the enrolment path with the guardrails removed, so it is the path that will be attacked.
What to do before September
The deadline is doing you a favour, because it gives the work a date. Three things worth finishing first:
Instrument credential registration as a security event. Not a directory change buried in an audit log, an alert with an owner. If a passkey is registered outside a known enrolment window, someone should be looking at it that day.
Rehearse the lockout path. Have someone who is not in the identity team attempt account recovery and write down every point where a persuasive caller would have succeeded. That document is your actual recovery policy, whatever the written one says.
Tell users what enrolment will never look like. The specific defence against this campaign is a workforce that knows IT will never ring them and walk them through registering a passkey. That is a one-paragraph internal comms job and it is cheaper than every technical control on this list.
The protocol work is heading the right way too. OpenID Connect Key Binding is in implementer's draft review until 23 August, and it addresses the adjacent problem of a valid credential being replayed somewhere it should not be. Worth a comment if this is your area.
None of this argues against passkeys. Passkeys are a substantial improvement and the default is the correct call. The point is narrower: strong authentication systems get undone by weak processes around them, and the process nobody owns is usually enrolment.
Sources
Microsoft Entra ID gets passkeys as the default authentication method, BleepingComputer
Vishing actors target Microsoft Entra passkey enrolment, Okta Threat Intelligence
Microsoft and Google push passkeys deeper into workplace authentication, Biometric Update