Passkeys were introduced with a strong security proposition. Replace passwords with public key cryptography, bind the credential to the legitimate service, keep the private key away from the server, and many of the phishing and credential theft attacks that have plagued enterprise security for decades become dramatically harder.
All of that is true. But the security conversation has changed very quickly.
There are now at least 39 publicly documented methods, attack paths, research techniques, and exploitation scenarios involving passkeys and the infrastructure around them. Many already have working proof of concept tools or published research showing exactly how the techniques can be executed. Some are already appearing in real world attack patterns.
That does not mean criminals have operationalized all 39. It does mean the playbook is being written in public, and attackers no longer have to invent these techniques themselves.
More importantly, the research exposes a fundamental distinction that enterprises need to understand. The cryptography inside FIDO2 can remain completely intact while the account protected by the passkey is still compromised.
The Target Is No Longer Just the PasskeyA modern passkey authentication ceremony crosses an extraordinary number of trust boundaries. It can involve the web application, browser, operating system, password manager, cloud synchronization service, mobile device, Bluetooth transport, account recovery system, enrollment process, help desk, and ultimately the human being approving the authentication.
Researchers are attacking almost every one of those layers. Published techniques now include 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 demonstrated the significance of this problem in its Pass the Passkey research. One of its most important observations was that malware does not necessarily need to extract a private key.
A malicious Windows application can ask the legitimate WebAuthn infrastructure to generate a signed assertion. The user sees what appears to be a legitimate Windows authentication experience, completes verification, and the attacker receives the resulting assertion.
The private key never left its protected location. The cryptography was not cracked. Yet the authentication process was successfully manipulated.
That distinction is central to understanding the new passkey threat model.
Even the Passkey Prompt Is an Attack SurfaceSeveral of the 39 published techniques 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 recreates a problem the security industry already encountered with push-based MFA. Users become accustomed to authentication prompts. Once authentication becomes a routine visual interaction, attackers can manufacture, repeat, disguise, or strategically time those interactions.
SpecterOps demonstrated tooling capable of repeatedly invoking legitimate looking Windows passkey prompts. Researchers also demonstrated techniques that can make malicious authentication activity appear to originate from an application the employee already trusts.
The lesson is important. Phishing resistance at the cryptographic protocol layer does not guarantee deception resistance across the operating system, browser, application, and user interface layers surrounding that protocol.
Shareable Passkeys Expand the Attack SurfaceThe attack surface grows significantly when passkeys can be shared, synchronized, exported, restored, or moved between devices.
The published inventory 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 fundamentally a cryptography problem. It is an architectural problem.
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 expands far beyond the original authenticator.
An attacker no longer needs to defeat FIDO2. The attacker needs to compromise one sufficiently trusted component somewhere in the surrounding ecosystem.
A synchronized passkey can therefore use extremely strong cryptography while still inheriting the weaknesses of the phone, operating system, password manager, cloud account, browser, recovery process, and synchronization system responsible for managing it.
Enrollment and Recovery Create Another OpeningSome of the most consequential attacks do not steal an existing passkey at all. They simply create another 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 what happens when an attacker gains enough 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 controlled by the attacker.
Nothing has been cracked. Nothing has necessarily been stolen from the existing authenticator. The legitimate service itself creates a perfectly valid credential for the adversary.
This leads to an increasingly important identity principle. Phishing resistant authentication is insufficient if enrollment, replacement, recovery, and device registration are not protected to the same standard.
Dedicated Biometric Hardware Changes the Attack SurfaceDedicated biometric hardware approaches the problem very differently from passkeys stored on general purpose devices.
A purpose-built biometric authenticator can retain the private credential inside secure hardware with no cloud synchronization, no export mechanism, and no password manager responsible for moving the credential between devices.
Authentication can require a live fingerprint directly on the authenticator as well as physical proximity to the endpoint requesting access.
Just as importantly, a dedicated authenticator does not need to contain a traditional general-purpose operating system, an application store, a browser, or a screen.
That distinction eliminates enormous portions of the attack surface.
There are no third-party applications for an attacker to replace with malicious versions. Rogue applications cannot simply be installed on the authenticator. There is no browser extension ecosystem to compromise. There is no screen on which malware can present a deceptive authentication interface.
There is no consumer operating system filled with unrelated applications, permissions, background services, and update dependencies.
The authenticator performs a very small number of security specific functions and nothing else.
This drastically changes the economics of attacking it. Instead of attempting to compromise a huge general purpose computing environment, an attacker is confronting a tightly controlled hardware device designed specifically to protect cryptographic credentials and verify biometric identity.
It also makes the authentication process far more resistant to employee manipulation. An employee can be persuaded to visit a website, answer a telephone call, or follow instructions from someone claiming to be technical support. But social engineering cannot install a rogue application onto hardware that does not run ordinary applications.
It cannot manipulate a screen that does not exist. It cannot synchronize a credential through a cloud service that the authenticator does not use.
In that sense, properly designed dedicated biometric hardware becomes both highly resistant to attackers and highly resistant to mistakes made by employees.
Correct Service Configuration Is CriticalDedicated hardware alone is not enough. The relying service must be configured to preserve the security model.
For sensitive enterprise environments, authentication and enrollment should be restricted to approved authenticator classes. The relying party should validate authenticator identity, enforce user verification, properly validate challenges and sessions, use appropriate signature counter protections, and prevent weaker methods from becoming fallback authentication paths.
Enrollment and recovery deserve particular attention. Adding a new authenticator should require proof from an already authorized authenticator rather than merely proving control of an account through a weaker recovery channel.
Configured correctly, this architecture prevents an attacker from simply enrolling an ordinary passkey from another laptop, phone, software vault, or security key. Cloud account takeover does not yield the credential. Password manager compromise does not yield it. Mobile malware cannot infect the authenticator.
A malicious application cannot be installed on it. And a remote attacker cannot manufacture the combination of dedicated hardware, biometric verification, physical proximity, and legitimate service interaction required to authenticate.
What the 39 Attacks Really Tell UsThe existence of 39 published attack methods does not mean FIDO2 cryptography failed. In many ways, it demonstrates the opposite.
Researchers repeatedly attack the software, synchronization systems, enrollment processes, operating systems, browsers, recovery mechanisms, and people surrounding the credential because defeating properly implemented cryptographic hardware directly is considerably more difficult.
That should tell security leaders where the next identity boundary needs to be.
For high value enterprise identities, credentials should not be freely shareable across consumer devices and cloud ecosystems. They should be bound to dedicated biometric hardware, the verified individual, the legitimate service, and an enterprise controlled enrollment and recovery process.
Passkeys solved a large part of the password problem. The 39 published attacks show us what attackers are targeting.
Dedicated biometric hardware, correctly implemented from enrollment through authentication and recovery, removes virtually all of that surrounding attack surface before an attacker ever gets the opportunity to use it.
Download the Token passkey security ebook to explore many published attack methods and see how dedicated biometric hardware changes the enterprise identity trust model.source
Recent Posts
