Three separate research efforts landed this week showing ways to defeat passkey protections, and the coverage split into two equally wrong camps: “passkeys are broken” and “nothing to see here.”

Neither. Here is what the research actually shows and what it means for you.

What was not broken

Start here, because it determines how much you should worry.

FIDO2 cryptography was not broken. No private keys were extracted from hardware security keys or device enclaves. The math is fine. The key material stayed where it was supposed to stay.

The attack family — SpecterOps calls it “Pass-the-Passkey” — comprises more than 20 techniques that exploit the ecosystem around passkeys: endpoint logging, server-side assertion validation, authentication prompts, browser behaviour, password manager interfaces, and enterprise authentication workflows. Affected surfaces include Windows 11, Microsoft Entra ID, web browsers, password managers, and enterprise auth flows.

This is implementation and integration, not primitives. Which is the normal place for real-world cryptographic systems to fail, and has been for forty years.

The worst chain

The most serious attack combined two independent defects, and it is worth understanding because it illustrates the entire category.

Defect one — Windows logged too much. Windows recorded complete WebAuthn assertion responses in the Microsoft-Windows-WebAuthN/Operational event log. That log entry contained the full signed assertion — the artifact the relying party checks to confirm you authenticated.

Defect two — Entra ID checked too little. Microsoft Entra ID omitted essential WebAuthn anti-replay checks during server-side validation.

Individually, each is bad practice. Together they are a full authentication bypass. WebAuthn’s replay protection exists precisely because an assertion is a bearer artifact once produced — it is only safe if the server refuses to accept the same one twice, and enforces the challenge and signature counter checks that make each assertion single-use. Windows wrote the artifact to a readable log; Entra ID accepted it again.

An attacker with local read access to that event log — which is a much lower bar than compromising a TPM — could lift an assertion and replay it to impersonate the user, including privileged users. Phishing-resistant MFA, bypassed, without a single cryptographic operation being attacked.

Microsoft has fixed it. The Windows logging flaw is tracked as CVE-2026-34348, addressed by truncating logged signatures. July 2026 Windows updates make the WebAuthn assertions written to event logs unusable for replay.

The generalisable lesson

The pattern across all twenty-plus techniques is the same one that keeps recurring in authentication security, and it is worth internalising because it predicts the next round.

Authentication produces a credential. The credential is the target.

Kerberos ticket theft — pass-the-ticket — did not break Kerberos crypto. NTLM hash relay did not break NTLM’s hash function. Session cookie theft does not break TLS. In each case, attackers ignored the strong part and took the artifact the strong part produced.

Passkeys are unusually well-designed against phishing specifically: the assertion is bound to the origin, so a fake login page cannot harvest anything usable for the real site. That property is genuine and it is why passkeys are worth adopting. But the assertion still has to travel from an authenticator, through an OS API, through a browser, over a network, to a server that validates it. Every hop is somewhere it can be observed, mishandled, or accepted twice.

The browser-in-the-middle work presented at DEF CON this week is the same insight from the other end — attacking authenticated sessions rather than the authentication.

What this means for you personally

Direct and unhedged: keep using passkeys, and adopt them more widely.

The threat model here is overwhelmingly enterprise. The headline chain required local access to an endpoint’s event log and a relying party with broken validation. If an attacker already has that level of access to your machine, your authentication method was never the weak link.

Compare against what passkeys replace. Passwords are phished at industrial scale, reused across services, and dumped in breaches weekly. SMS codes are defeated by SIM swap. TOTP codes are relayed in real time by phishing kits that have been commodity products for five years. Those attacks are automated, cheap, and used against ordinary people every day.

Pass-the-Passkey is a targeted enterprise attack requiring specific conditions and specific unpatched software. It is not what is going to happen to your email account.

The practical checklist

For individuals:

  1. Enable passkeys everywhere they are offered — Google, Apple, Microsoft, GitHub, and increasingly banks. Do this today if you have not.
  2. Keep your OS patched. The most serious chain here was fixed by a July Windows update. That is the entire mitigation for the worst finding in this research, and it is free.
  3. Prefer hardware-bound passkeys for high-value accounts. A YubiKey or equivalent means the key material never syncs and never leaves the device. Synced passkeys — the kind stored in your iCloud Keychain or Google Password Manager — are more convenient and appropriate for most accounts, but their security inherits your platform account’s security.
  4. Remove weaker fallbacks once passkeys work. A passkey on an account that still permits SMS reset is protected at the strength of SMS. Attackers use the recovery path, not the front door.
  5. Do not let a password manager become a single point of failure without its own strong second factor.

For anyone running Windows or Entra ID at work:

  1. Confirm July 2026 Windows updates are deployed. CVE-2026-34348 is the one that matters.
  2. Restrict read access to Microsoft-Windows-WebAuthN/Operational and treat authentication logs as credential material rather than telemetry — the general principle this research establishes.
  3. Read SpecterOps’s full write-up. Twenty techniques means nineteen more than the one that made headlines, and they span password managers and browser flows, not just Microsoft.

The part that should concern you

Not the attacks. The response time.

Windows was writing complete, replayable WebAuthn assertions to a local event log, and Entra ID was not enforcing anti-replay. Those are not exotic failures — anti-replay is not an optional feature of WebAuthn, it is the mechanism that makes an assertion safe to transmit. It is in the specification. It is in every implementation guide.

That two independently sufficient defects coexisted in the flagship enterprise identity stack of the company that has been loudest about passkey adoption, until outside researchers found them, is the finding. Not that passkeys are weak — they are strong — but that the assurance you get from a strong protocol is capped by the least careful implementation in the chain, and you have no way to audit that from where you stand.

The pattern

Every generation of authentication gets sold as the one that ends the problem, and every generation is defeated at the seams rather than at the core.

Passkeys are genuinely the largest improvement in consumer authentication in twenty years. Use them. Also understand that “phishing-resistant” describes a property of the protocol, not a property of the deployment, and the gap between those two things is where every attack in this research lives.