Attackers Can't Steal Passkeys, So They're Enrolling Their Own

Passkeys cannot be phished the way passwords can, so attackers have changed targets. A vishing campaign documented by Okta Threat Intelligence talks employees through a fake Microsoft Entra sign-in page. Meanwhile, the attacker uses what the victim types to sign in to the real account and register a passkey of their own. The weak point is no longer sign-in. It is enrollment and recovery.

Key facts

• The group: Okta tracks the cluster as O-UNC-066. Palo Alto Networks Unit 42 tracks it as CL-CRI-1147. Okta says it has been active since April 2026, and its motive is primarily data extortion.
• The pretext: a phone call telling the employee they must register a new passkey.
• The trick: a live operator steers the victim through a branded fake page, captures the password and MFA code, and enrolls the attacker's passkey on the real account.
• Who was targeted: Okta observed targeting in food and beverage, technology, healthcare, automotive, construction and aviation.
• Why the call sounds real: Okta notes that since May 2026, Microsoft administrators can run passkey registration campaigns that prompt users at sign-in, and in some circumstances those prompts are on by default.
• The report: Okta published it on July 5, 2026. It is not new, but it describes the attack every passkey rollout now has to plan for.

Passkeys are winning at sign-in

Start with why attackers bothered. The FIDO Alliance Passkey Index, October 2026, draws on data from 15 large consumer services, including Amazon, Google, Microsoft, PayPal and TikTok. Across those participants, more than one in three successful sign-ins now use a passkey (36%), up from 26% in 2025. Passkey sign-ins succeed 93% of the time, against 78% for passwords and traditional MFA.

A passkey is bound to the real website. A lookalike domain gets nothing it can replay. That is the property that makes passkeys phishing-resistant, and it is why the attackers in Okta's report do not try to steal one. They add one instead.

I covered the gap between how well passkeys work and how few accounts use them in an earlier post on the enrollment gap. This campaign is the dark side of the same gap. Every account still on a password and a one-time code is an account where someone else can do the enrolling.

How the attack works

Okta's report walks through the phishing kit page by page. In plain terms:

1. The setup. The group registers domains built around the word "passkey," with names that suggest setting up, adding or deploying one. Each target organization gets its own subdomain. I am not listing the domains here; defenders can take them from Okta's report.
2. The call. A caller tells the employee they must register a new passkey and walks them to the page.
3. The fake page. Okta says the pages are "customized using each victim organization's legitimate branding," with generic Microsoft styling loaded from Microsoft's own content delivery network.
4. A live operator. Okta stresses that the kit "is not a transparent Adversary-in-the-Middle (AitM) proxy." An operator watches a control panel that polls the victim's browser every second and chooses which page to show next.
5. Credential capture. The victim enters a username and password, which go straight to the operator. A "processing" page holds the victim while the operator checks which second factor the real account asks for.
6. MFA capture. The operator then serves the matching page: an SMS code, an authenticator app code, or a push approval with number matching, where the victim types a number the operator supplies.
7. The fake enrollment. The victim is asked to "create a passkey," but no passkey is created on their device. The real enrollment happens on the attacker's side, directly with Microsoft.
8. The distraction. The victim is shown a "recovery key" phrase and asked to confirm a word from it. Okta found no direct use for this step in Entra and assumes it keeps the victim busy.

The only real signal the victim may get is the legitimate Microsoft email saying a new passkey was registered. Okta notes the attacker can give that passkey a harmless-sounding name.

Okta is careful about the limits of its evidence. The kit does not handle federation to third-party identity providers, and Okta says it has not directly observed compromised Microsoft accounts. The technique still generalizes. It works on any platform where a user can add an authenticator after signing in with weaker factors.

Why this matters beyond one campaign

This attack does not break passkeys. It exploits the gap between two security levels on the same account.

Look at how Microsoft's registration campaign is documented. A user is nudged to set up a passkey after an interactive sign-in with MFA, and for passkey campaigns the user "completes MFA by using any method." That is a sensible default for adoption. It also means a password plus an SMS code is enough to reach the enrollment screen.

If that is true for your accounts, their real security level is password plus SMS, not passkey. The passkey guards the front door while the side door stays open.

Attackers take the weakest path that leads to the same place. For most organizations, that path now runs through three places:

• Enrollment: adding a new authenticator after signing in with weaker factors.
• Recovery: resetting access through email, SMS or a support call. I argued in account recovery design that this flow sets your real security ceiling.
• The help desk: persuading a person to reset or add a factor, the pattern behind the attacks in your help desk is the new perimeter.

As more sign-ins move to passkeys, more attacks will move to these three places.

How to lock down passkey enrollment

These steps combine Okta's recommendations with standard identity practice. Where a step comes from Okta, I say so.

1. Require a strong factor to add a strong factor

Adding a passkey should require an existing phishing-resistant credential, a managed device, or high-assurance identity proofing. A password and an SMS code should not be enough to register a new passkey.

2. Restrict where enrollment can happen

Okta recommends policies that limit adding or changing authenticators based on network context, device status and the authenticators already enrolled. In Entra, Microsoft's documentation notes that Conditional Access policies on security information registration apply before the passkey nudge. A policy that allows registration only from trusted networks or devices closes much of this path.

3. Alert on every authenticator change

Okta recommends end-user notifications for every authenticator lifecycle event. Send them to the security team as well. The notice should say what was added, from which device and location, and what to do if it was not the user.

4. Treat enrollment right after a new-context sign-in as suspicious

A passkey registered minutes after a sign-in from an unfamiliar device, network or hosting provider is a strong signal. Flag it by default and require a second look.

5. Tell employees what IT will never do

Publish one rule: IT will never call you to set up a passkey or approve a sign-in. Announce rollouts through official internal channels, and have users start enrollment themselves from a known company portal. Okta also recommends establishing and communicating how users can verify the identity of help desk staff who contact them.

6. Retire weak factors once a passkey exists

Remove SMS and other phishable factors as ways to sign in or recover. Otherwise the account stays only as strong as its weakest factor. The MFA Without Fatigue chapter of my passwordless playbook ranks factors by phishing resistance and shows where to step up.

7. Deny access from places you do not operate

Okta suggests network zones that deny access by country, network or IP range where your organization has no presence. Okta also lists the hosting providers and indicator domains it observed.

What this means for passkey rollouts

None of this is a reason to slow down. Passkeys remain the strongest widely available sign-in method, and they remove whole categories of attack.

It is a reason to finish the rollout. A passkey rollout is not done when users have passkeys. It is done when:

• enrollment requires strong verification,
• recovery cannot be completed with weaker factors,
• phishable factors are removed, and
• every authenticator change is visible to the user and the security team.

The login screen and recovery chapter of the same playbook has ready-to-use copy for new-device notices and a support script that cannot be talked around. For the customer-facing side of the trade-off, see my brand guide to login without friction.

My read (analysis): the identity attacks of 2027 will mostly target the processes around strong authentication, not the authentication itself. Enrollment, recovery, help desks, and the agents and service accounts that hold credentials of their own. I make that case in my identity and AI security predictions for 2027.

The bottom line

Passkeys solved phishing at sign-in. Attackers responded by phishing the step before it.

If an attacker can register a passkey with your password and a text-message code, your account is only as strong as that password and code. Lock down enrollment, harden recovery, retire weak factors, and make every change visible.

FAQ

Can passkeys be phished?

The passkey itself resists phishing because it only works on the real website. Attackers instead target enrollment. In the campaign Okta documented, victims enter their password and MFA code on a fake page. The attacker uses them on the real account to register a passkey of their own.

Who is behind the Microsoft Entra passkey vishing campaign?

Okta Threat Intelligence tracks the cluster as O-UNC-066, and Palo Alto Networks Unit 42 tracks it as CL-CRI-1147. Okta says it has been active since April 2026, is motivated mainly by data extortion, and has targeted several industries.

How do I protect passkey enrollment?

Require a phishing-resistant credential, managed device or high-assurance check to add a passkey. Restrict enrollment by device and network, and alert on every authenticator change. Tell employees IT will never call to set up a passkey, and remove SMS once a passkey exists.

Should we slow down our passkey rollout because of enrollment attacks?

No. Passkeys remain the strongest widely available sign-in method. The lesson is to finish the rollout: secure enrollment and recovery, retire weaker factors, and monitor authenticator changes, so the account is as strong as the passkey.