Passkeys had a hard month, and none of it was the cryptography

In one week of August 2026, three independent research teams published ways to defeat passkey protections. None of them broke WebAuthn. None of them factored a key or forged a signature. Every single one attacked the plumbing around the credential: where the assertion gets written, who holds the sync key, and what counts as user presence.

That distinction is the whole story, and it is being lost in the coverage. Passkeys did exactly what they promised. The promise was narrower than most rollout decks admitted.

What the three attacks actually showed

SpecterOps found the assertion in the logs. Windows wrote YubiKey WebAuthn assertions into the event log in cleartext, readable by unprivileged users, and Microsoft Entra ID accepted them on replay. That satisfied phishing-resistant MFA policy while impersonating a privileged user. Tracked as CVE-2026-34348, CVSS 6.5, mitigated in July 2026 Windows updates. The underlying design issue SpecterOps named is more durable than the bug: Entra uses JWTs as WebAuthn challenges rather than pseudorandom nonces, and does not bind the challenge to a session cookie.

Unit 42 recovered synced private keys. Against Chrome's Google Password Manager on Windows, starting from malware already on the endpoint, they pulled the 32-byte Security Domain Secret out of Chrome process memory during re-registration and used it to recover synced passkey private keys. Google removed the secret from logging output. There is still no rotation or revocation mechanism for that secret, which means a single successful extraction is permanent for that sync domain.

Dirk-jan Mollema reused the key without asking the user. Low-privilege code in a signed-in Windows session can call Windows cryptographic interfaces to exercise a non-exportable, TPM-protected Windows Hello for Business key with no fresh PIN or biometric prompt. The resulting FIDO2 assertion satisfies Conditional Access rules demanding phishing-resistant authentication, and because the token can lack a device ID claim, it opens a path to device registration and a Primary Refresh Token valid for 90 days. No CVE was issued.

The thesis: sync convenience and phishing resistance are now in tension

Passkeys won consumer adoption because of sync. Nobody was going to buy two hardware keys for a shopping account, and an unsynced credential dies with the device. So the platforms built sync fabrics, and those fabrics necessarily hold key material or the ability to derive it.

That is a defensible trade for consumer accounts. It is a different calculation for a domain admin.

The Unit 42 work makes the custody question concrete. A synced passkey has a custodian, and the custodian's secret becomes a target with a blast radius equal to every credential in that domain. The Mollema work makes the presence question concrete: a credential that never prompts is a credential whose "user verification" flag is an assertion about the platform's state, not about a human.

Neither finding argues against passkeys. Both argue against treating "we deployed passkeys" as a completed control.

What to change in a rollout

Split your population. Device-bound hardware authenticators for administrators, break-glass accounts, and anyone with production access. Synced platform passkeys for everyone else. This is the same tiering you already apply to privileged access, applied to credential custody rather than to entitlements.

Stop treating endpoint compromise as a separate incident class. Every attack in this batch presumes code execution as the user. If that is your threat model boundary, say so in the design document, because the alternative is discovering it during a response. A compromised endpoint means a compromised identity, passkey or not.

Validate user verification server-side, and mean it. eBay changed how it validates WebAuthn user-verification flags after the Unit 42 disclosure. If your relying party accepts an assertion with uv unset, or treats uv as advisory, you have a passwordless flow with a password's assurance level. Our passkey rollout checklist covers the enrolment and validation decisions.

Hunt for the specific artifacts. Windows Hello for Business sign-ins with empty device IDs. Authentications from a host that did not request the challenge. Device registrations that follow a passkey sign-in within minutes. Legitimate traffic produces some of these, which is why it belongs in ITDR tuning rather than in a blocking rule.

Enrol more than one credential per account. The single biggest recovery failure in passkey deployments is still an account with exactly one credential. WhatsApp shipped multi-passkey support in the same month as this research, which is not a coincidence: the platforms are learning the same lesson.

What this does not mean

It does not mean going back to MFA push or TOTP. The campaigns actually hitting organizations at scale this month, Mirage2FA across 4,532 domains and Kali365 device-code phishing, defeat exactly those factors with no research budget at all. Passkeys stop those attacks. The research above requires malware on the endpoint first.

The honest summary is that passkeys moved the attacker from remote and cheap to local and expensive. That is a large win. It is not the end of the program, and the vendors that sold it as one now have a credibility problem the standard does not deserve.

Related reading

• Three passkey attacks land in one week
• Windows Hello key abuse for Entra ID persistence
• WebAuthn and FIDO2 standard
• What is passwordless