Palo Alto Networks’ Unit 42 research team has disclosed three attack techniques, collectively called “Pass-ta-key,” that let malware running on a compromised Windows device hijack passkeys synced through Google Password Manager. The research, published on August 3, does not break the cryptography underlying passkeys; it exploits how Chrome and Google’s cloud authenticator handle device trust, onboarding, recovery, and synced credentials.
All three paths begin with malware already executing on the victim’s machine, and the research is limited to Google Password Manager on Chrome and Windows systems equipped with a Trusted Platform Module (TPM). Unit 42 reported no in-the-wild exploitation, and no CVE identifiers were issued for the three methods as of the report’s publication.
How the Three Pass-ta-key Techniques Compromise Synced Passkeys
Unit 42 groups the attacks into escalating variants: Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key. Each exploits a different assumption in the flow Chrome uses to enroll a device with Google’s cloud authenticator and to recover or reuse synced credentials.
Pass-ta-key and Silver Pass-ta-key Reuse Device Trust and Re-Enrollment
The first variant lets unprivileged malware abuse Chrome’s TPM-backed device identity key to request a valid authentication assertion from Google Cloud Authenticator without admin rights, user interaction, biometrics, or device unlock. The assertion carries a User Verified (UV) flag, and the attack’s success depends on whether the relying party validates that flag. Unit 42 reported the technique failed against GitHub, which checks the flag, but succeeded against eBay, which did not properly validate it until after the researchers reported the gap.
The second variant forces Chrome to re-register the device and registers a user-verification key controlled by the attacker. Google does not validate that a newly registered key came from trusted hardware, so assertions signed with the attacker’s key carry the UV flag and enable later logins without the victim’s device involved.
Golden Pass-ta-key Extracts the Security Domain Secret From Chrome Memory
The most severe variant triggers re-enrollment and extracts the 32-byte Security Domain Secret (SDS), the master key that decrypts all synced passkeys, from Chrome’s process memory where it briefly sits in plaintext. Unit 42 initially found the SDS exposed in Chrome’s internal FIDO logs; Google removed it from those logs after disclosure, but the secret is still delivered to the client and remains accessible in process memory. With the SDS, an attacker can recover passkey private keys, transfer them to another system, and decrypt future synced passkeys. According to the researchers, Google’s implementation provides no rotation or revocation control for the secret.
The eBay User-Verification Gap and Relying Party Responsibility
The eBay outcome illustrates why passkeys advertised as phishing-resistant still leave relying parties responsible for validating the User Verified flag. eBay fixed its validation gap after the disclosure, and Unit 42 recommends websites require and properly validate userVerification rather than trusting the request setting.
Chromium Source Code Corroborates Parts of the Architecture
Unit 42 said the Chromium source code corroborates elements of the design, including a wrapped TPM key created without a key name, a deferred_uv_key_creation state, and the SDS entering client memory. The source does not independently verify all server-side claims against the latest stable Chrome release.
What the Pass-ta-key Findings Mean for Passkey Deployments
The report hands security teams a concrete baseline: relying parties should verify the UV bit instead of trusting the request, credential providers should attest newly enrolled keys and harden re-registration and recovery flows, and master keys should stay out of browser memory and client logs. Google did not respond to questions on whether a stolen SDS survives a PIN change.
The three techniques also illustrate how the passkey ecosystem distributes security across layers no single vendor fully controls: the browser, the cloud authenticator, and every relying party that accepts an assertion. A gap at any one of those layers, as eBay’s validation handling showed, can nullify the protection the other layers provide.
The broader implication is that passkeys move trust from shared secrets to the integrity of a local device and to the validity checks performed by everyone downstream of it. Once that device is compromised, the passkey model’s phishing resistance does not protect the synced credentials themselves, and the absence of any rotation mechanism for the SDS means a single extraction can compromise credentials both past and future. Relying parties that skip user-verification validation widen the window in which a stolen assertion is reusable, which makes validation enforcement as important as the passkey mechanism itself.
