Pass the Passkey: When Passwordless Authentication Meets Its Achilles' Heel

Passkeys are increasingly promoted as the successor to passwords, but two independent studies published in 2026 (SpecterOps on Windows/Entra ID¹ and Unit 42 on Google Password Manager²) show that the real-world implementation – rather than the underlying cryptography – introduces concrete attack surfaces, including overly verbose logs, replay attacks, and local malware abuse. This article examines both attack families and provides practical recommendations for developers, administrators, and security teams.

Let us recap

Passkeys are increasingly promoted as the successor to passwords, although they are not the only passwordless option on the table; certificate-based authentication (e.g., smart cards), magic links, and other FIDO-adjacent mechanisms exist too. Still, passkeys are the approach most actively pushed by the major platform vendors, which makes their real-world security worth scrutinizing.

The roots of passkeys go back to the founding of the FIDO Alliance in February 2013, created with the goal of reducing reliance on shared passwords. From there, progress was gradual: first the U2F standards, then FIDO2/WebAuthn, which became an official W3C recommendation in March 2019, laid the technical groundwork. The term “passkey” and the user experience we know today were then standardized and jointly promoted by Apple, Google, and Microsoft starting on May 5, 2022, the date of their joint announcement of expanded support for the FIDO standard.³

From a technical standpoint, a passkey is a passwordless authentication method based on public-key cryptography: at registration with a service, the device (or authenticator) generates a key pair specific to that service – not a new pair on every login, but a dedicated pair for each relying party. The private key remains securely stored on the device (or on a hardware token) and never leaves that environment, while the public key is shared with the online service. To log in, the user authenticates locally – with a fingerprint, face, or PIN – and the device uses the private key to sign the challenge sent by the site without ever transmitting any secret over the network.

Given that it relies on public-key cryptography, it is natural to ask whether passkeys are vulnerable to quantum computing. Most passkeys use elliptic curves (typically ES256/P-256), whose security rests on the difficulty of the elliptic curve discrete logarithm problem. A sufficiently powerful quantum computer could in theory solve this problem using Shor’s algorithm, but no quantum computer capable of doing so in practice currently exists, and the industry is already working on post-quantum extensions in anticipation of that future scenario.

The main advantage of passkeys is that users no longer have to rely on their own memory: biometric data (or a local PIN) is only used to “unlock” the private key’s signature, and it never leaves the device. Passkeys are also, by design, resistant to phishing, brute-force attacks, credential database breaches, and credential reuse. The outlook therefore looks very appealing, but, as we will see, the real-world implementation of the system introduces new and, in some ways, unexpected attack surfaces.

Pass the Key Attacks: Michael Grafnetter’s research (SpecterOps)

Over the past few months, research by Michael Grafnetter (SpecterOps), presented at Black Hat USA 2026 and compiled in the white paper “Pass-the-Passkey Family of Attacks”¹, has highlighted several significant vulnerabilities in the implementation of passkeys on Windows 11 and Microsoft Entra ID. Some of these were later reclassified by Microsoft (often lowering their severity) and partially fixed, but the study remains interesting because it opens the door to a broader family of attack techniques, drawing an analogy of sorts with the classic pass-the-hash, pass-the-key, and NTLM relay attacks in the Windows world.

The starting point of the research is a simple question: “if passkeys are meant to eliminate phishing, replay, and relay attacks that plague passwords, what happens when the surrounding implementation falls short?”¹

Signature saved in Windows Event Logs

Grafnetter discovered that Windows 11 writes the entire WebAuthn assertion to the event log (channel Microsoft-Windows-WebAuthN/Operational) every time a user authenticates with a passkey (cf. white paper §3.1, “Passkey Assertion Mining via Windows Event Log”¹). This applies to Windows Hello, to roaming authenticators such as YubiKeys, to password manager plug-ins like 1Password or Bitwarden, and to hybrid flows involving a smartphone. The only exceptions are private browsing sessions and certain plug-ins that autofill the passkey by bypassing the Windows API¹.

The logged payload is the entire PublicKeyCredential structure: challenge, authenticator data, signature, user handle, and credential ID – everything needed to impersonate the user. Reading these events locally requires only membership in the Users group; remotely, it is enough to belong to Event Log Readers, Remote Desktop Users, Remote Management Users.¹

The practical impact is significant in escalation scenarios: consider an Entra ID Global Administrator who authenticates on a shared or centrally managed machine. An attacker with only Event Log Readers privileges on that machine, but with little or no cloud privileges, can read the logged assertion and replay it to impersonate the privileged user in the cloud, gaining access well beyond their own authorization.¹

For the attack to work on the server side, three conditions are required, all of which held true for Microsoft Entra ID at the time: the relying party does not check for challenge reuse, the challenge is not bound to the user session, and signature counters are not tracked.¹

Microsoft classified the report as Information Disclosure (CVE-2026-34348, CVSS 6.5 Medium), even though Grafnetter had proposed a more severe classification of Privilege Escalation (CVSS 8.6 High).¹⁴ The fix, released on July 14, 2026, truncates the signature fields in the log to just six bytes: enough to prevent replay without compromising debugging capability.^{1 4}

Replay attack against Entra

The second strand of the research concerns Microsoft Entra ID directly. For scalability reasons, rather than storing every issued challenge in a server-side database, Entra ID generates challenges as short-lived signed JWTs (cf. white paper §3.2, “Passkey Replay Attack”¹). The payload declares a validity of five minutes, but in testing the platform continued to accept challenges up to ten minutes after issuance, to tolerate potential clock skew between systems – a window more than sufficient to intercept and reuse a signed challenge, especially in an automated attack.¹

Making matters worse, Entra ID did not track signature counters for WebAuthn assertions, a mechanism specifically designed to detect cloned or reused credentials.¹ This means a captured assertion (for example, from the event log described above) could be replayed without the system noticing. In Grafnetter’s tests, the combined attack (reading the log plus replaying against Entra ID) allowed bypassing conditional access policies that require phishing-resistant MFA, without triggering any alert on tenants protected by Microsoft 365 E5 with Identity Protection and Defender for Identity enabled.¹

A partial fix arrived in May 2026: Microsoft introduced signature counter tracking for hardware FIDO2 security keys (e.g., YubiKey). However, Windows Hello passkeys still send a fixed counter of zero, remaining vulnerable to replay.¹

A related attack described in the same study is the “Circuit Breaker” attack: with malware present on the victim’s device, it is possible to temporarily suspend the browser process (or block its outbound network traffic) at the exact moment the assertion is generated, in order to “steal” the signature before it reaches the legitimate relying party. This only works against services that do not bind the challenge to the session; once again, the case of Entra ID, unlike, for example, GitHub, which as of 2026 uses session-bound challenges.¹

Malware attacks

The third strand answers a different question: if malware is already present on the victim’s Windows machine, can it abuse their passkeys without needing to extract the private key? The answer is yes, and the mechanism is simpler than one might expect (cf. the white paper’s “Malware attacks” section¹).

Any Windows application can call the native WebAuthNAuthenticatorGetAssertion API directly – the same one used by browsers – with the difference that a browser is required to pass the real origin of the page that triggered the request, whereas a malicious application calling the API directly can declare whatever origin it wants (login.microsoft.com, github.com, etc.).¹ The result is that Windows shows the user the normal passkey authentication prompt; the victim, believing it to be a legitimate login, confirms with a fingerprint, face, or PIN, and the malware receives a fully valid assertion to forward to the attacker. Since this still requires the user’s approval, this technique is classified as a form of phishing.¹

Several variants make the attack more effective or harder to notice:¹

• Prompt flooding: If the victim rejects or closes the prompt, the attacker re-triggers it repeatedly until the user confirms out of fatigue or the challenge expires – the “passkey” equivalent of MFA push fatigue.
• Application metadata spoofing: The name and publisher shown in the prompt (e.g., “Microsoft Edge – Microsoft Corporation”) come from the executable’s version information, which is easily falsified by a malicious application.
• Window handle injection: A vulnerability (not fixed by Microsoft, classified as “Low severity”) allows the prompt to appear as if it belongs to a different, already-trusted application, such as the browser itself.
• RDP/Hyper-V relay: Windows natively forwards WebAuthn requests from the remote machine you are connected to back to your local device; malware present on the remote host can therefore exploit this channel to request a signature from the connected victim.

Beyond malware: administrative abuse and credential storage risks

The white paper also flags risks that do not fit the “trick the user into approving a forged prompt” pattern above, but are worth covering alongside the malware techniques because they target the same underlying trust assumption: that a passkey on an account genuinely belongs to, and was registered by, its legitimate owner.

The first is a plain storage problem rather than a prompt-forging technique: KeePassXC and Bitwarden allow synced passkeys to be exported as JSON files. KeePassXC always exports them in plaintext (with an explicit warning in the interface); Bitwarden offers unencrypted export as a default option. Malware scanning the disk for these files can recover fully usable private keys without needing the original vault’s master password, no deceptive WebAuthn prompt required. Even the emerging Credential Exchange Format (CXF) from the FIDO Alliance, designed to transfer credentials between different password managers, exposes passkey material in plaintext if intercepted outside the protected transfer channel.⁵

The second is the so-called Shadow Passkey: an attacker with sufficient administrative privileges (via the Microsoft Graph API or Okta) can register a “ghost” passkey on a high-value account – a backdoor that, being an independent factor, survives even a password change by the victim. This is an abuse of administrative access, not an on-device attack.

The third is a structural point about synced vs. device-bound passkeys: synced passkeys (in the cloud, via a password manager) are inherently less secure than device-bound ones (tied to a single device or hardware token), since the private key exists in multiple copies and its security ultimately depends on the strength of the account protecting the cloud vault, rather than on secure hardware.¹ For high-value accounts (an Entra ID Global Administrator, for example), a device-bound passkey is therefore preferable.

A parallel thread: Unit 42’s research on Google Password Manager

It is worth noting that, almost simultaneously, the Unit 42 team at Palo Alto Networks published similar but independent research, focused on the Google Password Manager ecosystem in Chrome on Windows (the so-called Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key attacks).² In that case too, the problem does not lie in the passkeys’ cryptography but in the cloud synchronization architecture: device identity keys extractable without elevated privileges, user verification keys that can be registered without attestation checks, and a “master key” (security domain secret) temporarily exposed in plaintext in logs and process memory.² The two studies, though covering different vendors (Microsoft/Entra ID on one side, Google/Chrome on the other), converge on the same lesson: trust placed in the endpoint remains the weak point of the system.

Related research

The “Pass-the-Passkey” thread fits into a broader body of research that in recent years has tested WebAuthn’s guarantees from various angles: a malicious browser extension capable of intercepting and substituting WebAuthn calls during registration;⁶ a phishing technique targeting synced passkeys broadly, demonstrated against Google, Apple, and Bitwarden password managers,⁷ in line with a broader academic comparison between device-bound and synced passkeys;⁸ hardware vulnerabilities in Google Titan security keys, both at the Bluetooth protocol level and via a side-channel attack capable of recovering the private key from the secure element;⁹ a timing side-channel attack capable of breaking FIDO2’s privacy property by detecting whether the same hardware token is registered on multiple accounts;¹⁰ hijacking of the CTAP channel between authenticator and host via a Bluetooth man-in-the-middle;¹¹ a bypass of Windows Hello facial recognition via injection of captured infrared frames;[^14] and, finally, a large-scale study presented at USENIX Security 2026 on the real-world adoption of passkeys on the web and how often site implementations deviate from the specification.[^15]

What we suggest to our clients

Based on both studies, the recommendations we give our clients fall into three groups, by role:

For web application developers (relying parties):

• Rigorously implement all the server-side checks required by the WebAuthn specification: challenge uniqueness, signature counter verification, and validation of the UV (User Verified) flag – not just requesting it, but actually verifying its presence in the response.
• Bind challenges to the user session, so that an intercepted assertion cannot be forwarded from an environment other than the one that initiated the login.
• Prefer mature, well-tested WebAuthn SDKs over custom implementations, and subject the integration to dedicated penetration testing.
• Never log sensitive authentication data in application logs.

For security teams and IT administrators:

• Keep Windows up to date and monitor for security updates related to WebAuthn.
• Do not treat “phishing-resistant” MFA as an absolute guarantee in conditional access policies for high-value identities and applications: it should be paired with behavioral and endpoint controls.
• Restrict the execution of unauthorized applications and the installation of unapproved browser extensions, which remain the most common vector for these attacks.
• Monitor the registration of new passkeys and authentication methods on high-value accounts (for example, via Microsoft Entra audit logs and the Graph API, or the equivalent logs of your identity provider) and alert on unexpected additions.
• For high-privilege accounts, enforce device-bound passkeys with mandatory attestation, avoiding cloud-synced variants.
• Educate users never to approve a passkey authentication prompt they did not personally initiate – the same behavioral hygiene already recommended against MFA fatigue.

For penetration testers and red teamers:

• Always include testing for replay and relay vulnerabilities in the client’s WebAuthn implementation.
• Test the system’s behavior by altering the UV/UP flags and the signature counter in assertions to determine whether the relying party actually validates them or blindly trusts the client.

Conclusion

The two studies, despite starting from different vendors and architectures, tell the same story: passkeys are not being “broken” cryptographically, but by the implementation assumptions surrounding them – overly verbose logs, missing server-side checks, onboarding and recovery flows designed for usability rather than security, and an endpoint that, if compromised, can always generate the signals the system expects to receive from a trusted device.

This does not change the overall verdict: passkeys remain real, substantial progress over passwords, eliminating entire classes of historically dominant attacks (classic phishing, credential stuffing, credential reuse) and should be adopted as soon as possible. But they need to be treated as one layer of a broader security strategy, not as a solution that is “unhackable by definition”: endpoint security, correct server-side implementation, and careful monitoring remain just as essential as they were in the password era.