Pass-ta-key: The Three Attacks Undermining Passkey Synchronization on Google Password Manager

On August 3, 2026, researchers from Palo Alto Networks Unit 42 publicly disclosed a series of three attacks — Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key — that allow malware already running on a Windows device to abuse passkeys synchronized via Google Password Manager. None of the techniques break passkey cryptography; instead, they exploit weaknesses in the trust, registration, and recovery processes of Google’s cloud authenticator. The severity is high, culminating in Golden Pass-ta-key, which can permanently steal the master key that encrypts all synchronized passkeys.

Pass-ta-key: Authentication Without User Verification by Exploiting TPM

The first attack does not require elevated privileges. Malware uses the device’s TPM-protected identity key to make Chrome sign an authentication request without any user interaction. Google’s cloud authenticator considers the response valid because it originates from a trusted computer, but verification of the User Verified flag is left to the target service. If the service does not check the flag, the attacker gains access as if they had used a PIN or biometrics.

eBay did not validate the flag and was found vulnerable (later fixed). GitHub, on the other hand, already enforced the check and was not exposed. The flaw demonstrates that passkey security partly depends on how rigorously each service applies the standard.

Silver Pass-ta-key: Registering a Verification Key Under Attacker Control

Silver Pass-ta-key intervenes during device re-registration on Chrome. The malware injects a user verification key generated by the attacker. The cloud authenticator does not verify that the new key actually comes from trusted hardware and accepts it. From that moment, the attacker can authenticate from a remote system, producing a legitimate-appearing user verification proof even for services that require a PIN or biometrics.

The attack thus bypasses strong client-side protections by exploiting a recovery process that lacks adequate provenance checks.

Golden Pass-ta-key: Theft of the Security Domain Secret and Irreversible Compromise

This is the most critical attack. The security domain secret (SDS) is the master key that encrypts all synchronized passkeys. Researchers initially found it exposed in Chrome’s internal FIDO logs; after the report, Google removed those logs. However, the key remains temporarily in the browser process memory during registration or recovery operations.

Malware can force a re-registration and capture the SDS in memory. Once in possession of the key, the attacker decrypts all synchronized passkeys (present and future) and extracts their private keys, resulting in permanent identity theft. There is no SDS rotation mechanism: the compromise survives malware removal.

What Has Been Fixed and What Remains to Be Done

Google removed the SDS from FIDO logs but had not communicated additional measures to protect the key in memory at the time the research was published. eBay fixed the missing validation of the User Verified flag. For web services, the primary mitigation remains requiring and strictly verifying the User Verified flag during passkey authentication. Client-side credential managers should:

• validate that registered user verification keys originate from trusted hardware;
• strengthen re-registration and recovery processes;
• prevent the SDS from being accessible in browser memory.

Unit 42’s research confirms that passkeys offer substantially stronger protection than passwords, but they do not eliminate the risks posed by malicious code already running on the device. Losing sight of them during an active compromise means granting permanent credentials to an adversary.