Key Takeaways
Unit 42 researchers demonstrated three attack techniques, dubbed Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key, that let endpoint malware hijack Google Password Manager passkeys on Windows.
The attacks require prior malware on the device but need no fingerprint, PIN, or on-screen prompt, defeating the user-verification guarantee passkeys were built to provide.
The Golden Pass-ta-key variant extracts a master secret from Chrome's memory, giving attackers permanent decryption access to every synced passkey, not just one account.
As of publication, Google has not assigned CVEs or announced fixes, though GitHub and eBay have already tightened their own verification checks.
Enterprises rolling out passkeys as a phishing-resistant MFA replacement should treat endpoint compromise as a passkey compromise until Google closes these gaps.
The pitch was that passkeys could not be phished. Malware does not need to phish.
Passkeys have been the industry's answer to credential phishing for two years now: no shared secret to steal, cryptographic proof tied to a specific device, and a user-verification step (fingerprint, PIN, or face scan) that is supposed to guarantee a human authorized the login. Palo Alto Networks' Unit 42 published research on August 3 showing that on Windows machines, that last guarantee can be bypassed entirely by malware already running on the endpoint, with no fingerprint, PIN, or visible prompt required.
The research describes three related techniques collectively built around what the team calls the Pass-ta-key attack family. In the base version, malware extracts a device identity key that Chrome stores using Windows' TPM-backed cryptography APIs, then uses it to impersonate the device directly to Google's Cloud Authenticator. Because the key can be accessed by an unprivileged process through standard Windows cryptography calls, no elevated permissions or device unlock are needed. The result is a full account takeover that never touches the user's fingerprint reader or PIN pad. Because the impersonation happens at the device-identity layer, the victim sees nothing unusual on their own screen, and the relying party's logs show what looks like a normal, verified login from a recognized device.
Two escalations, and one that breaks the whole vault
The second technique, Silver Pass-ta-key, is more insidious because it does not even require live malware on the device at the moment of attack. It forces the passkey system into a device re-registration flow and registers an attacker-controlled verification key during a transitional state the researchers call uv_key_pending. Once registered, the attacker can authenticate with the user-verification flag set to true, satisfying relying parties' checks, without ever touching the victim's actual device again. That makes Silver Pass-ta-key a persistence technique as much as an access technique, since the attacker-controlled key survives independently of whatever malware initially triggered the re-registration flow.
The third and most severe variant, Golden Pass-ta-key, goes after the Security Domain Secret, the master key Chrome uses to encrypt every synced passkey in a user's Password Manager vault. Researchers found this secret exposed in plaintext during normal Chrome logging, retrievable from process memory during device re-registration. Extracting it gives an attacker permanent, offline decryption access to every passkey the victim has ever synced, not a single credential but the entire vault. As Unit 42 put it, "the attacks presented in this research do not break the underlying cryptography, instead they exploit gaps between design assumptions and real-world implementations."
Why this matters for enterprise identity roadmaps
Most enterprise passkey rollouts have been justified, in part, on the assumption that once a credential is passkey-based, endpoint malware becomes a secondary concern for that particular authentication flow, because the private key never leaves the device and user verification blocks silent misuse. This research directly undercuts that assumption for any environment where Chrome syncs passkeys through Google Password Manager on Windows endpoints. If a device is already compromised, which is the threat model most enterprise EDR and zero-trust programs are built around anyway, the passkey layer offers less protection than architects assumed. That gap is easy to miss because passkey adoption metrics and phishing-resistance metrics get reported together, when this research shows they are not the same guarantee.
That does not mean passkeys are worse than passwords; they still eliminate phishing and credential-stuffing risk for the vast majority of attack paths. It means the specific claim that passkeys neutralize a compromised endpoint does not hold for this implementation. CISOs who have used passkey adoption to justify relaxing other endpoint controls, or who have positioned passkeys as sufficient standalone protection for high-value accounts, should revisit that reasoning until Google documents a fix.
The vendor response gap
As of the August 3 publication, no CVEs have been assigned to any of the three techniques, and Google has not published a fix or a public timeline for one. The researchers note that GitHub already enforces stricter user-verification checks that appear to close part of the gap, and eBay addressed a related validation weakness after disclosure, which suggests the underlying issue is at least partially addressable at the relying-party level even before Google patches the root cause in Chrome. That is a useful interim option for any enterprise that controls its own login flow and does not want to wait on Google's timeline.
That puts enterprises in an awkward position: the fix is not fully in their hands. Security teams can push relying parties they control (internal applications, customer-facing login flows) to tighten user-verification enforcement on their end, but the core TPM key handling and Security Domain Secret exposure live inside Chrome and Google's infrastructure. Until Google ships a fix, the practical mitigation is treating any Windows endpoint with signs of compromise as a trigger for passkey re-enrollment across every account synced through Google Password Manager on that machine, not just a credential reset.
What security leaders should do now
Start by inventorying where Google Password Manager is actually in use for enterprise authentication, versus platform-native or hardware-backed passkey stores like Windows Hello for Business or FIDO2 security keys, which were not the subject of this research. If your organization relies on Chrome-synced passkeys for any privileged access, treat endpoint detection and response as the primary control protecting those credentials, not a secondary one, since this research shows the passkey layer itself is not an independent backstop against a compromised device.
Push your identity and endpoint teams to monitor for the specific artifacts Unit 42 documented, particularly anomalous device re-registration events and Chrome memory access patterns consistent with credential extraction. And build a re-enrollment plan now, before you need it: if a Windows endpoint with synced passkeys is confirmed compromised, every account tied to that Google Password Manager vault needs new passkeys, not just the one account you happened to notice was affected. Treat that re-enrollment plan as part of your standard incident response runbook rather than something you improvise the first time it is actually needed.
