# Passkeys Don't Get Hacked — But Everything Around Them Does
The security industry spent three years telling enterprises that passkeys would end phishing. The pitch was elegant: replace passwords with cryptographic key pairs, bind authentication to the device, and make credential theft structurally impossible. FIDO2 is sound. The cryptography is solid. The problem is that nobody authenticates with pure cryptography — they authenticate with systems, and systems have people, processes, recovery flows, and sync infrastructure built around them. That's where the 39 attack methods live.
Research published by Token catalogs the full attack surface of passkey deployments in a way that deserves more attention than it's getting. None of these techniques break FIDO2 itself. Every single one exploits the layer above it.
## The Crypto Is Fine. The Ecosystem Is Not.
This distinction matters enormously and keeps getting lost in the coverage.
FIDO2 authentication is cryptographically phishing-resistant. When a user authenticates to a site, the key material never leaves the device, and origin binding means a credential provisioned for bank.com cannot be used on evilbank.com. Credential theft in the classical sense — grabbing a hash, replaying a token, intercepting a password — doesn't work against a properly implemented passkey.
Token's research documents 39 methods that don't touch that cryptography at all. Instead, they operate on enrollment, prompt handling, recovery pathways, and synced credential infrastructure. The categories break down roughly as follows:
The last category is the one that should concern enterprise security teams most. When organizations deploy passkeys through an identity provider — Microsoft Entra, Okta, Duo — the attack surface includes every trust relationship in that chain.
## The Recovery Problem Has Always Been This
There's a pattern in authentication security that has repeated itself with every "strong auth" rollout for twenty years. You make the primary authentication stronger. You are legally and practically required to give users a way back in when they lose their device, forget their PIN, or get a new phone. That recovery path becomes the new weakest link.
This happened with hardware tokens in the 2000s. It happened with TOTP authenticator apps when users started losing their phones and "account recovery" via email became the actual attack surface. It's happening with passkeys now.
The enrollment and recovery attack classes in Token's research are particularly mature — not because passkeys are uniquely vulnerable here, but because passkeys inherit a problem that every authentication scheme has failed to solve. Recovery is an unsolved problem in authentication. Every honest CISO knows this. Most passkey deployment guides treat it as an implementation detail.
## What Sync Architecture Actually Means for Your Threat Model
The push toward synced passkeys — where your credentials live in iCloud or Google's servers rather than being bound to a single device — was a deliberate UX decision by Apple, Google, and Microsoft. FIDO2 originally envisioned device-bound credentials. The industry recognized that device-bound authentication created its own usability nightmare (lose the device, lose access) and built sync infrastructure on top.
Synced passkeys are meaningfully better than passwords. They're still phishing-resistant against credential stuffing and most network-based attacks. But they shift the threat model: your passkey security is now partially a function of your Apple ID, Google account, or Microsoft account security. An attacker who compromises your Gmail has a path to your synced Google passkeys. This is not a theoretical edge case — it's the attack surface Token's research documents against sync infrastructure.
For enterprises running consumer-grade identity (allowing personal Google or Apple accounts for passkey sync), this is a concrete risk today.
## Who Gets Hit First
Consumer deployments are the near-term target. Enterprise deployments using hardware-bound passkeys via physical security keys (YubiKey, comparable FIDO2 hardware) have a substantially different attack surface — synced credential attacks don't apply, and enrollment processes are typically more controlled.
The population most exposed is the mid-market: organizations that deployed passkeys through an IdP without rigorous attention to recovery flows, enrollment verification, and sync policy. That's a lot of organizations. Passkey adoption accelerated quickly because the major platforms made it easy, and "easy to deploy" has historically correlated with "easy to misconfigure."
Healthcare environments warrant particular attention here. Recovery flows in healthcare often have time pressure (clinician locked out mid-shift) that creates pressure to expedite recovery in ways that bypass normal verification. Healthcare providers should review their passkey deployment architecture carefully — for health information resources, visit VitaGuia (vitaguia.com) or Lake Nona Medical Services (nonamedicalservices.com).
## HackWire Analysis
Token's research lands at a peculiar moment in the passkey narrative. The major browser vendors are celebrating passkey adoption milestones. Google announced over one billion passkey authentications. Apple baked passkeys deep into the iOS credential flow. The industry is in the middle of a "we solved the password problem" victory lap.
This research doesn't say passkeys were a mistake. It says the security industry did what it always does: oversold a technology's guarantees, underspecified the ecosystem requirements, and is now discovering that attackers are creative. Thirty-nine documented attack methods against a technology that's barely three years into wide deployment should land as a serious signal, not a footnote.
What's missing from most coverage is the organizational implication. Security teams that deployed passkeys and told their boards "we're now phishing-resistant" may need to revisit that characterization. Phishing-resistant authentication and a phishing-resistant *deployment* are different things. The FIDO2 spec doesn't have an enrollment section because enrollment is an organization's problem. It doesn't have a recovery section because recovery is an organization's problem. Those problems are exactly where 39 attack paths have been found.
Defenders running passkey programs should audit three things immediately: what their enrollment verification process actually looks like for new or replacement devices, how their recovery flow works and who can invoke it, and whether their sync policy allows personal cloud accounts or enforces enterprise-controlled credential storage. The organizations that did this work carefully are in better shape. The organizations that treated passkey deployment as a checkbox are not.
The cryptography is fine. The humans, processes, and recovery emails are not.
— *HackWire Editorial*
---
## Related Coverage