Passkeys were heralded as a significant leap forward in authentication, promising to replace passwords with public key cryptography and effectively neutralize phishing and credential theft. The core cryptographic principles remain sound, binding credentials to legitimate services and securing private keys away from servers. However, the security landscape has rapidly evolved. There are now at least 39 publicly documented methods, attack paths, and exploitation scenarios involving passkeys and their surrounding infrastructure. Many of these already have working proof-of-concept tools or published research, with some techniques already observed in real-world attack patterns. This doesn't mean all 39 methods are operationalized by criminals, but it signifies that the playbook for attackers is being written in public. More critically, this research highlights a fundamental distinction: the **FIDO2** cryptography can remain entirely intact while the account it protects is still compromised. ## The Target Is No Longer Just the Passkey A modern passkey authentication ceremony spans numerous trust boundaries. This can include the web application, browser, operating system, password manager, cloud synchronization service, mobile device, Bluetooth transport, account recovery system, help desk, and the user themselves. Researchers are actively targeting almost every one of these layers. Published techniques now encompass assertion mining, assertion replay, circuit breaker attacks, assertion phishing, browser hooking, assertion capture, challenge injection, detour replay, user verification manipulation, and user presence manipulation. **SpecterOps** notably demonstrated this problem in their "Pass the Passkey" research. A key observation was that malware does not necessarily need to extract a private key. A malicious **Windows** application, for instance, can leverage the legitimate **WebAuthn** infrastructure to generate a signed assertion. The user perceives a legitimate **Windows** authentication prompt, completes verification, and the attacker receives the resulting assertion. The private key remains secure, and the cryptography uncompromised, yet the authentication process is successfully manipulated. This distinction is crucial for understanding the evolving passkey threat model. ## Even the Passkey Prompt Is an Attack Surface Several of the 39 published techniques specifically target the user interface surrounding authentication. Researchers have demonstrated passkey prompt flooding, credential interface deception, application metadata spoofing, window handle spoofing, remote desktop passkey phishing, and **FIDO** interface overlay attacks. This mirrors a challenge previously faced with push-based Multi-Factor Authentication (MFA), where users become accustomed to authentication prompts. Once authentication becomes a routine visual interaction, attackers can manufacture, repeat, disguise, or strategically time these interactions. **SpecterOps** demonstrated tooling capable of repeatedly invoking legitimate-looking **Windows** passkey prompts. Researchers also showed how malicious authentication activity could be made to appear as if it originated from a trusted application. This underlines that phishing resistance at the cryptographic protocol layer does not guarantee deception resistance across the operating system, browser, application, and user interface layers. ## Shareable Passkeys Expand the Attack Surface The attack surface grows significantly when passkeys can be shared, synchronized, exported, restored, or moved between devices. The documented inventory of attacks now includes synced vault compromise, **Apple** or **Google** account takeover, cloud recovery takeover, stolen or compromised phones, mobile malware, rooted mobile devices, hybrid authentication manipulation, **KeePassXC** export theft, **Bitwarden** export theft, credential exchange theft, malicious browser extensions, and attacks involving **CTAP** and Bluetooth communication. This is not a fundamental cryptography problem but an architectural one. Once a credential can move between devices, synchronize through a cloud account, be exported from a vault, be restored using another identity, or be recovered through another process, the security boundary extends far beyond the original authenticator. An attacker no longer needs to defeat **FIDO2**; they merely need to compromise a sufficiently trusted component within the surrounding ecosystem. A synchronized passkey, therefore, inherits the weaknesses of the phone, operating system, password manager, cloud account, browser, recovery process, and synchronization system managing it. ## Enrollment and Recovery Create Another Opening Some of the most impactful attacks don't steal an existing passkey but instead create a new one. Published techniques include shadow passkeys, enrollment vishing, attacker phone enrollment, attacker-controlled passkey registration, help desk takeover, temporary credential abuse, SIM-based recovery, reverse vishing, and migration pretext attacks. Consider a scenario where an attacker gains sufficient control of an employee account to initiate legitimate passkey registration. Instead of extracting the employee's existing credential, the attacker registers an entirely new credential on a device they control. Nothing is cracked or stolen from the existing authenticator; the legitimate service itself creates a perfectly valid credential for the adversary. This emphasizes a critical identity principle: phishing-resistant authentication is insufficient if enrollment, replacement, recovery, and device registration are not protected to the same high standard. ## Dedicated Biometric Hardware Changes the Attack Surface Dedicated biometric hardware offers a fundamentally different approach compared to passkeys stored on general-purpose devices. A purpose-built biometric authenticator can retain the private credential within secure hardware, without cloud synchronization, export mechanisms, or a password manager moving the credential between devices. Authentication can require a live fingerprint directly on the authenticator, alongside physical proximity to the endpoint requesting access. Crucially, a dedicated authenticator does not need to contain a traditional general-purpose operating system, an application store, a browser, or a screen. This distinction eliminates enormous portions of the attack surface. There are no third-party applications for an attacker to replace, no rogue applications to install, no browser extension ecosystem to compromise, and no screen for malware to present deceptive authentication interfaces. This drastically alters the economics of attacking the system, forcing adversaries to confront a tightly controlled hardware device specifically designed to protect cryptographic credentials and verify biometric identity.