# Passkeys Don't Break Themselves — The Ecosystem Around Them Does
Passkeys were supposed to end the phishing era. Three separate research efforts published last week suggest the era is instead entering a more complicated chapter — one where the cryptography holds but everything built around it doesn't.
None of the attacks break the underlying math. The elliptic curve signatures that make FIDO2 authentication resistant to credential stuffing and phishing-site replay remain solid. What the researchers broke, in three distinct ways, were the systems that store, sync, and negotiate those keys — and one of the exploits doesn't even require cracking anything. It requires waiting for Windows to hand the material over.
## When Windows Does the Attacker's Work
The first attack exploited signed authentication material that Windows exposed during the authentication flow. The exact mechanism varies across implementations, but the pattern has a well-worn shape in Windows authentication history: the OS generates or holds a cryptographic artifact, some component passes it over an insufficiently protected channel or to a process that shouldn't see it, and a sufficiently positioned attacker captures it before it expires.
In classical Windows credential attacks — NTLM relay, Kerberos delegation abuse, pass-the-ticket — the attack surface was always the plumbing around the authentication, not the algorithm itself. The researchers appear to have found an analogous seam in the Windows Hello credential provider or the WebAuthn broker. Signed assertions or challenge responses, captured in the right window, can be replayed against services that don't adequately validate context binding.
This matters because it bypasses the "phishing-resistant" label without requiring a phishing page. If an attacker can replay a captured WebAuthn assertion, they don't need to trick the user into visiting a fake site — they just need to have been watching.
## The Cloud Sync Problem No One Wants to Talk About
The second attack is the one that should concern enterprise security teams most, because it exposes a fundamental tension baked into the passkey ecosystem from the start.
Apple, Google, and increasingly Microsoft have built passkey sync into their platforms — iCloud Keychain, Google Password Manager, Windows backup. The convenience argument is sound: without sync, a user who loses their device loses their passkeys, and the recovery story becomes a support nightmare. So the industry accepted that passkey private keys would live in the cloud.
The researchers demonstrated that malware with sufficient privileges on the victim's machine can extract synced passkey private keys from the operating system's keychain. This isn't a zero-day in the sync protocol itself — it's the same class of problem that's always existed with software-stored secrets. Once an adversary has code execution with adequate permissions, DPAPI-protected stores on Windows, the macOS Keychain, and Android's credential store all have documented extraction paths. Passkeys stored there are no different from passwords stored there.
The nuance that defenders often miss: the "phishing-resistant" claim was never a claim about malware resistance. FIDO2 threat model documentation is explicit that the authenticator is the security boundary, and a hardware authenticator (a physical FIDO key, Face ID backed by the Secure Enclave) provides much stronger guarantees than a software authenticator synced to the cloud. But the industry has largely marketed cloud-synced passkeys and hardware-backed passkeys as equivalent experiences, and users and even many security teams have believed it.
## The Third Vector: What We Know Without the Full Paper
The third research thread — the details appear incomplete in the current disclosure — appears to use some mechanism to bypass phishing-resistant MFA after the passkey authentication succeeds. The most probable architecture: an adversary-in-the-middle proxy that lets the real authentication complete, then harvests the post-authentication session. Evilginx-style tooling already does this against password-based MFA; adapting it to passkeys doesn't require breaking the passkey itself, only stealing the session cookie that follows.
If that's the correct read, it continues a pattern seen since passkeys began rolling out at scale: attackers pivoting from credential theft to session theft. You can't phish the passkey. You can still phish the session it creates.
## HackWire Analysis
The passkey rollout has been among the most substantive security improvements in consumer authentication in decades — that's not in dispute. But the research disclosed last week illustrates a recurring dynamic in security tooling: the solution gets deployed, marketing calls the problem solved, and attackers find the seams that weren't in the threat model diagram.
Three things stand out that other coverage is either missing or understating.
First, the cloud sync attack isn't news in the narrow technical sense — security researchers have known for years that software-stored secrets are software-stored secrets regardless of what they're protecting. What's new is that this vector is now worth targeting at scale, because passkeys have achieved enough adoption that the prize on the other end justifies the investment. The attack surface grew when the user base did.
Second, Windows-specific signed material exposure fits a historical pattern that should make every enterprise Windows shop nervous. Windows authentication complexity — the sheer number of protocols, credential providers, and trust relationships — has generated exploitable seams for thirty years. Adding a new authentication method doesn't erase that legacy; it adds another surface for legacy pathways to touch.
Third, the defender calculus here is cleaner than it might seem. Hardware security keys — actual FIDO2 hardware, not cloud-synced passkeys — are not meaningfully affected by the cloud sync attack. Enterprises that have deployed hardware keys to high-value users are in better shape than the headlines suggest. The vulnerability exposure scales with how much of your passkey deployment relies on software-backed sync rather than hardware-bound keys. Most consumer deployments use sync. Most high-security enterprise deployments that did this right don't.
The practical takeaway for defenders: audit your passkey deployment. Know whether your implementation is hardware-backed or software-synced. Prioritize hardware keys for privileged access, executive accounts, and anyone with access to production systems. And model your threat against session theft, not just credential theft — post-authentication token protections matter even when the authentication itself is cryptographically sound.
— HackWire Editorial
## Related Coverage