Passkeys were sold as the end of stolen passwords: nothing to memorise, nothing to reuse, nothing a phishing site can capture. The cryptography underneath still holds. What failed in the first week of August 2026 was not that cryptography, but everything built around it.
Within days, three independent research teams each demonstrated how to bypass a passkey sign-in without breaking the encryption. None of them attacked the key pair. All three targeted the surrounding infrastructure: the Windows event log, Google's sync layer, and the Windows Hello key store. The clearest summary of the three findings was published by The Hacker News. For anyone defending an organisation the message is straightforward: a passkey still protects well against classic phishing, but it ceases to be a guarantee the moment the user's machine is already compromised. And all three techniques start from exactly that position.
At the cybersecurity company Hard2bit we follow this line of research closely because it shows where identity risk is actually moving: away from credential theft and towards abuse of the session and the device. Understanding what each team demonstrated is essential before drawing conclusions about your own architecture.
Three research efforts, one shared conclusion
The three pieces appeared within days of one another and converge on the same diagnosis: the problem is not the FIDO2 standard, but how each platform implements registration, recovery and device trust. Each team attacked a different flank.
Unit 42: recovering the master key behind synced passkeys
The team at Palo Alto Networks Unit 42 described three variants —Pass-ta-key, Silver Pass-ta-key and Golden Pass-ta-key— against the passkeys that Google Password Manager syncs in Chrome on Windows. All three begin with malware already running on the victim's endpoint and require no administrator-level privilege escalation.
The first variant abuses Chrome's device identity machinery to obtain the signatures needed to impersonate a legitimate Google client, without a fresh unlock or any user interaction. Unit 42 demonstrated the technique against eBay even though the site requested user verification; after the disclosure, eBay changed how it validates that flag, as The Hacker News reported.
The most severe variant, Golden Pass-ta-key, targets the Security Domain Secret: a 32-byte master key that decrypts every passkey synced to an account. Unit 42 first found it exposed in Chrome's internal logging; Google removed it from that output after the report, although the researchers note it still appears transiently in Chrome's process memory during re-registration. It persists for a blunt reason: the current implementation offers no way to rotate or revoke that secret once it has been stolen. The full technical context is available in the Unit 42 analysis.
SpecterOps: a signature Windows kept in cleartext
Researcher Michael Grafnetter presented SpecterOps' Pass-the-Passkey work at Black Hat USA 2026. The firm showed how Windows stored previous YubiKey signatures in cleartext, in a location that authenticated unprivileged users — including remote ones — could read. By chaining those signatures with weaknesses in Microsoft Entra ID's passkey validation, it became possible to impersonate privileged users despite a policy that required phishing-resistant MFA.
The Windows flaw is tracked as CVE-2026-34348, an information-disclosure issue in the Windows Event Logging Service, rated 6.5 by the vendor and shipped with a security update. One important qualifier: the attacker does not extract the authenticator's private key, but reuses a signature that Windows had already generated and retained. Microsoft applied mitigations, and according to SpecterOps its July 2026 Windows updates rendered those signatures unusable for replay, closing the full attack chain. One design gap remains: SpecterOps notes that Entra continues to use JWTs as WebAuthn challenges rather than single-use random values, and does not bind the challenge to the session cookie.
Dirk-jan Mollema: using Windows Hello without asking for the PIN
Independent researcher Dirk-jan Mollema focused on Windows Hello for Business. On most modern devices the backing key lives in the TPM and cannot be exported. His finding is that a low-privilege process inside an already signed-in session can use that key — without triggering a new PIN or biometric prompt — to sign as if it were a FIDO2 credential against Entra ID.
The technique is exploitable because of how Entra's WebAuthn challenge works: it remains valid for five minutes and is not bound to a session, a user or a tenant. An attacker can request the challenge on their own machine, have it signed on the victim's endpoint and return the assertion, thereby satisfying Conditional Access policies that demand phishing-resistant authentication. The resulting token may lack the device identifier claim, which opens a path to registering a fresh device and obtaining a Primary Refresh Token for persistence.
Mollema also provided defenders with a practical detection signal: look in the sign-in logs for authentications that use the Windows Hello for Business method and arrive with an empty device identifier. Under normal conditions this is an uncommon event, so it serves as a useful first filter when combined with monitoring for unexpected device registrations.
What has changed compared with a year ago?
Twelve months ago the dominant narrative was nearly unanimous: passkeys eliminate entire classes of attack and replace both the password and the traditional second factor. That remains true for ordinary phishing. What has changed is that adoption has grown large enough for attackers to stop examining the protocol and start examining the implementation — cross-device sync, account recovery, device trust, and the traces the operating system leaves along the way.
The interest tracks the scale of adoption. As Malwarebytes reports, citing the FIDO Alliance, by the end of 2024 roughly 800 million Google accounts already used passkeys. Microsoft is accelerating the shift: according to its Entra documentation, from 1 September 2026 users enabled for SMS or voice are automatically able to register passkeys, and SMS and voice delivery retire on 1 February 2027. The more accounts depend on this mechanism, the more attractive its implementation becomes as an attack surface.
What this means for your defensive architecture
The common thread across the three research efforts is also the hardest to accept: every one of them starts from an endpoint or a session that is already compromised. That does not make them less relevant. It turns them into a practical test of what a passkey does — and does not — contain once the attacker is already inside. The answer is that it contains considerably less than the phishing-resistant label implies.
The practical consequence is to treat the passkey store, the recovery flows and browser memory as credential-sensitive territory, with the same level of scrutiny applied to a secrets manager. This is where EDR and threat hunting remain the first line of defence: if the malware never executes, none of these techniques can begin.
For anyone operating identity in Microsoft 365, the pattern connects directly with attacks we have already been analysing: session hijacking through token theft and AiTM and fraudulent passkey enrolment via vishing. The underlying pattern is consistent: identity is rarely broken by force; it is inherited through a trusted session or device.
What still works and which assumption has expired
What still works: against classic phishing sites and against password reuse, the passkey remains the best option available, and that is how it should be presented. Hardware security keys with a device-bound credential and no synchronisation reduce the exposure illustrated by Unit 42, because the private key never enters the sync system or browser memory in the same way. There is also a low-cost measure that closes the user-verification gap: require each service to actually verify the user-verified flag in the response rather than merely requesting it in the challenge.
What has expired is the assumption that passkey equals phishing-resistant equals problem solved. That mental shortcut ignores synchronisation, recovery, the design of the authentication challenge, and everything that happens after the endpoint is compromised. A JWT-based challenge that is not bound to the session, or a master secret that cannot be rotated, are implementation decisions the standard's label does not cover.
For organisations subject to NIS2 or DORA the implication is direct: both frameworks expect phishing-resistant MFA and identity control, yet this research shows that control does not end with the choice of passkey. It continues through endpoint hardening, the governance of non-human identities and tokens, least privilege and the detection of anomalous sessions. That is the layered-defence approach we apply in the Microsoft 365 security work at Hard2bit.
So what now?
None of these three research efforts is a reason to retire passkeys; that would be the wrong conclusion. The real test is not whether the passkey holds, but whether your organisation can distinguish a legitimate sign-in from one signed by malware inside a hijacked session. The detection signal Mollema published — a Windows Hello authentication arriving without a device identifier — is a practical place to start looking.
This article summarises public research by Unit 42, SpecterOps and Dirk-jan Mollema disclosed in August 2026, based on the information available at that date. The detection and hardening measures cited should be validated in a test environment before being applied in production. No mention implies an unfixed security flaw in the products named: Google, Microsoft and eBay applied changes following the disclosures. Attributions and scope may evolve as the research advances.
