For years, the cybersecurity industry has been moving toward what it calls phishing resistant authentication. Passkeys, Windows Hello, and FIDO2 have been central to that transition, and for good reason. They are a substantial improvement over passwords, SMS codes, and push based authenticator apps.
But the phrase phishing resistant is now being stretched well beyond what it actually proves. The cryptographic protocol may resist a traditional fake website, while the complete authentication system around it remains vulnerable to malware, recovery attacks, endpoint compromise, cloud synchronization, social engineering, session theft, and enrollment abuse.
That distinction is important because the attack surface has expanded dramatically. We now identify 16 significant attack and assurance vectors around Windows Hello deployments, and 39 distinct attack paths and weaknesses across broader passkey implementations. The latter span operating systems, browsers, cloud accounts, phones, password managers, recovery workflows, enrollment, user interface deception, transport layers, and authenticated sessions.
The first group of passkey attacks targets the Windows and browser environment itself. Researchers have demonstrated techniques such as assertion mining, assertion replay, prompt flooding, remote desktop phishing, malicious WebAuthn hooks, challenge substitution, passkey assertion capture, and attempts to manipulate user verification and user presence flags. Malware does not necessarily need to extract the private key. It can ask the operating system for a legitimate assertion, manipulate what the user sees, capture the result, or target the session that follows authentication.
Then the attack surface moves onto phones and cloud ecosystems. Synced passkeys may be stored or restored through Apple, Google, or password manager accounts. That creates attack paths involving cloud account takeover, recovery takeover, stolen or compromised phones, mobile malware, rooted devices, password manager vault compromise, exported passkeys, credential exchange files, malicious browser extensions, and hybrid QR or Bluetooth authentication flows.
This is where the original idea of a device bound credential starts to blur. A passkey may now exist across multiple devices, inside a consumer cloud identity, through a password manager, or on a personal phone the enterprise does not control. The company may not know every device capable of using the credential, who controls biometric enrollment on those devices, or what malware may already be present. Windows Hello itself can also allow a PIN in place of a fingerprint or face, and the relying service may know that local verification occurred without knowing which method was actually used.
The final group of attack vectors may be the most concerning because they exploit people and recovery processes rather than cryptography. These include fallback downgrade attacks that push users back toward passwords, SMS, TOTP, or push approvals; enrollment vishing that convinces users to add an attacker controlled passkey; attacker phone enrollment; help desk takeover; temporary credential abuse; SIM swap based recovery; reverse vishing; and migration pretexts that make fraudulent support calls sound legitimate.
That is the larger lesson behind the number 39. Attackers do not need to break FIDO2 mathematics. They only need to compromise one part of the surrounding identity system.
This does not mean passkeys or Windows Hello are bad technology. They are far better than passwords and legacy MFA. But it does mean that calling an entire authentication architecture phishing resistant simply because it uses WebAuthn is no longer sufficient.
For higher consequence access, enterprises need stronger identity assurance. That means knowing which physical authenticator was used, requiring a biometric every time, preventing credential synchronization, eliminating PIN or code fallbacks, keeping the credential inside controlled hardware, and establishing that the authenticator is physically near the device requesting access.
Token takes that approach by removing many of the surrounding attack surfaces altogether. The credential remains inside dedicated hardware, every authentication requires the registered fingerprint, there is no cloud synchronization, no PIN or code fallback, and proximity can be enforced between the authenticator and the device requesting access.
To date, we have not seen any demonstrated attack vector that defeats a correctly implemented TokenCore authentication flow. That claim depends on leveraging our recommended deployment, including correct FIDO2 origin validation, enterprise policy, device enrollment, recovery controls, counters, AAGUID locks, and proximity enforcement. In other words, the objective is not merely a stronger passkey. It is to eliminate the surrounding paths attackers have learned to exploit.
Passkeys solved one problem. Attackers simply moved to the 39 others. The goal now is to remove those paths too.