Can passkeys be phished? Here's what attackers are doing instead

Microsoft has announced that on September 1, 2026, passkeys become the default sign-in experience in Microsoft Entra. If your users are set up for SMS or voice codes today, they will be enabled for passkeys automatically and prompted to register one the next time they hit an MFA check.  

On February 1, 2027, Microsoft will retire its own SMS and voice delivery. Organizations that still require those methods will need a customer-managed telecom provider. A temporary opt-out can delay the passkey rollout between those dates, but not the February retirement.

So a very large number of people are about to be walked through passkey enrollment on a schedule somebody else picked.  

Attackers noticed. They started working that angle back in April.

Passkeys are a real improvement. But a large, scheduled rollout gives attackers a believable reason to ask users to enroll one.

What is a passkey?

A passkey is a pair of keys. One private, one public. The private key stays with the authenticator, the device or passkey provider that creates and protects it, rather than being sent to the service. The public key goes to the service you are signing into. When you log in, the service sends over a one-time puzzle, your device signs it with the private key, and the signature goes back.

Two things fall out of that, and they are why everyone is excited. There is no passkey secret on the server that an attacker can steal and reuse, because a breach gets them a pile of public keys, which are public by definition. And the signature is tied to the site that asked for it and only works once, so capturing it leaves you holding a used ticket to a show you cannot get into.

Passkey vs. password

A password is a secret you and the service both know, and that is the whole problem. Phish it, buy it off a dump, or watch somebody type it, and you can use it from anywhere until someone changes it.

A passkey never gets shared with anybody. Not with the service, not with a phishing site, not really with you. You could not tell me your passkey if I asked nicely.

Passkey vs. SMS codes and one-time passwords

Codes beat passwords. They are still short-lived secrets that a person types into a box, and a person can be talked into typing that box into the wrong website.

One note on the phone number. It is not credential material the way a password hash or a TOTP seed is, but it is a delivery channel, and delivery channels get hijacked. Ask anyone who has been through a SIM swap.

Two of those columns do most of the work. “Works on a lookalike domain” means the user can hand the credential to a site that is not the real one. “Can be relayed to the real service in real time” means somebody sitting between the user and the real login page can pass the answer along and walk off with a session.

That is why passkeys resist phishing during sign-in. The opening attackers have found comes earlier: convincing the account to trust a new passkey.

Synced vs. device-bound passkeys

There is a fork in the road here that does not get discussed enough.

It comes down to what counts as the authenticator. For device-bound passkeys, it is hardware: a security key, Windows Hello backed by the TPM, the Microsoft Authenticator app. The private key is created there, and it does not leave.

For synced passkeys, the authenticator is a cloud passkey provider: iCloud Keychain, Google Password Manager, whatever password manager your users installed on their own time. The private key is encrypted locally and synced across eligible devices signed in to that provider account, which is convenient, and which also means the honest answer to "where does the private key live" is "in a consumer cloud account, with a recovery process your company does not run."

Entra gives you a lever. Turn on attestation enforcement and only device-bound passkeys are allowed, with synced ones excluded. At scale, that can mean buying hardware or standardizing users on Microsoft Authenticator. That is a real cost, but it is still a choice, and right now much of it is being made by default.

Can passkeys be phished?

Passkeys resist phishing during sign-in. The opening attackers have found is enrollment.

A captured passkey response cannot be reused, so attackers are not trying to steal one. Instead, they target the process that tells an account to trust a new passkey.

Okta Threat Intelligence recently put a number on how visible this pretext has become in its own investigations: One in five of the proactive warnings it sent customers over the previous month involved phishing domains containing the word “passkey.” One in five.

The most recent campaign Okta observed came from a group it tracks as O-UNC-066. Active since April, the data-extortion group used passkey enrollment as a pretext to gain persistent access to Microsoft Entra accounts.

In the campaign Okta documented, the attack began with a phone call.

Somebody calls your employee. Friendly, professional, a little bit urgent. IT is rolling out passkeys, and they need to register today. The employee is directed to a domain with “passkey” in the name. The page carries your company’s branding and looks like Microsoft.  

Behind the page was an operator-controlled PHP panel. A live operator could follow the victim’s progress and swap in whichever MFA challenge appeared in the real Microsoft tenant: an SMS code, an authenticator app code, or a push approval with number matching.

The victim thought they were completing passkey enrollment. In reality, they were helping the operator sign in to the real account.

The next screen kept the illusion going. Instead of creating a passkey, the page displayed a supposed “recovery key” made from BIP-39 seed words, a cryptocurrency wallet convention that has nothing to do with Microsoft passkeys. Write these down. Confirm word four and word nine. Success.

Based on the code it recovered, Okta assesses that the operator used that time to complete the real enrollment elsewhere. With access to the legitimate Microsoft account, the attacker could register a new passkey under their own control.

Microsoft would then do exactly what it was supposed to do: notify the account owner that a new passkey had been added. The victim, who believed they had just completed the process themselves, could read that message as confirmation that everything worked. The attacker could also give the new passkey an ordinary name so it did not stand out.

One caveat belongs here rather than in a footnote. Okta did not directly observe these Microsoft account compromises in its own customer telemetry because the kit did not support federation to third-party identity providers. Its report combines infrastructure it observed and code it recovered, along with an assessment of how the operator used them. That is strong evidence of intent and capability. It is not a signed confession.

What passkeys don't protect against

Passkeys protect the sign-in ceremony. They stop credential phishing, replay, and lookalike domains, and they do it well. What they do not do is secure the processes around that ceremony: enrolling a new authenticator, recovering an account, and deciding what an authenticated session is actually allowed to reach.

Okta has now documented attackers going after both ends. O-UNC-066 used enrollment as the pretext. A second group, O-UNC-067, went after recovery instead, hunting for organizations that let users reset their own passwords and prove themselves with factors that are not phishing resistant. Same phone call, different door.

Okta's own conclusion is the part worth quoting. Whichever end gets targeted, "the success or failure of the attack hinges on the target's org-level account management policies."

The strength of the credential was not the deciding factor. The policy governing how access gets created and restored was.

Why the enrollment step is the weak point

The credential did not fail. The process used to enroll or recover it handed phishable authentication methods the authority to create stronger access. Weak proof was good enough to mint strong proof.

There is a detail in how Entra works that makes this tighter than it looks. To register or change a passkey, a user has to complete an MFA within the previous five minutes. If the session is not that fresh, Entra asks again.

Okta does not say the kit was built around that requirement, so the connection is inferred. Even so, a five-minute clock explains a lot about why this crew runs a live human and a one-second polling loop instead of a script. Automation gets brittle when you do not know which challenge is coming. A person wearing a headset does not.

So, what closes the gap?

Turn on attestation enforcement, and use passkey profiles to set different rules for different groups. Your privileged administrators do not need the same options as seasonal staff.

Restrict where enrollment can happen. Microsoft Entra Conditional Access can target the Register security information action. For higher-risk users, limit registration to trusted network locations or block it outside approved public IP ranges. Even if an attacker satisfies the existing MFA flow, the enrollment request still has to come from somewhere the organization permits.

Know what attestation buys you. Without it, Entra cannot guarantee any attribute a passkey claims about itself, including whether it is synced or device-bound. An AAGUID allowlist on its own is not a hard trust boundary. It is preferable.

Turning it on later is not a cleanup. Microsoft is explicit that passkeys registered before you enforced attestation stay usable afterward. Tightening the policy next quarter does not remove one that an attacker already enrolled. Go look at what is registered and take out what should not be there.

Alert on registration events, not just sign-ins. This attack path leaves a successful authentication and a newly registered authenticator. Watch only sign-ins and both look routine.

Give the helpdesk a separate way to verify callers and show users what legitimate enrollment will look like before rollout begins. The pretext works because employees are already expecting the request.

Get rid of the phishable fallback. Keeping SMS around just in case means paying for phishing-resistant authentication while leaving the back door propped open.

Where do passkeys fit in a Zero Trust security strategy?

Conditional Access can protect the passkey registration action by limiting where it can be performed. ThreatLocker Zero Trust Cloud Access (ZTCA) adds a separate check when that passkey is later used.

A passkey answers one question very well: Is this credential valid?

It does not answer the next one: Is this device approved?

Those are two different questions, and they need two different controls.  

ZTCA ties access to your Microsoft 365 and other cloud tenants to devices you have approved. Run the O-UNC-066 playbook against an organization doing that, and the attacker still gets through the phone call, still collects the credentials, still enrolls a passkey. A real one. Phishing resistant, works perfectly. And from an unapproved device, it gets them nowhere, because the final check is not only whether the credential is valid. It is whether the request came from a device the organization approved.

The same control helps with the synced passkey problem. If cloud access only works from an approved endpoint, a synced passkey cannot simply be used from every device it syncs to.

ZTCA does not stop enrollment. Nothing in a device trust layer reaches into that phone call. What it does is make the resulting credential useless from the attacker's laptop, which is the part that was going to hurt.

Passkeys are an important step in identity security, but not the whole strategy

Everything in that comparison table is real. Passkeys offer stronger protection than passwords and one-time codes, and organizations should adopt them. The important thing is understanding what they solve.

Passkeys eliminate the shared-secret credential and resist phishing and replay. They do not secure the processes that create and restore access, and they do not prevent a valid credential from being misused on the wrong device. You have until September 1 to work out which of those you were quietly counting on.