Three Pass-ta-key Attacks Bypass Google Passkeys — Chrome's Cloud Authenticator Validates Compromised Machines Without Checking the TPM

August 3, 2026. Unit 42, the research arm of Palo Alto Networks, published a report that cracks the marketing narrative around passkeys. Three attacks, collectively named Pass-ta-key, allow malware already present on a Windows machine to hijack passkeys synced through Google Password Manager in Chrome. None of these attacks break the underlying cryptography. They exploit a deeper problem: Google’s cloud authenticator trusts a compromised machine.

The three attacks target Google’s passkey synchronization architecture. They require no administrator privileges, no user interaction, and — in the case of Golden Pass-ta-key — compromise all future passkeys synced by the victim’s Google account.

The three attacks, from mild to catastrophic

Pass-ta-key: machine identity spoofing

The first attack exploits the device identity key stored in Windows’ TPM (Trusted Platform Module) and managed by Chrome. Unprivileged malware can:

1. Use this key to sign a request to Google’s cloud authenticator.
2. Impersonate the victim’s trusted device.
3. Obtain a signed authentication assertion — the equivalent of a valid login token — for the targeted account.

The attack requires no PIN, no biometric, and no device unlock. The TPM signs the request, Google validates it, and the attacker receives the assertion.

Limitation. The assertion contains a User Verified flag indicating whether biometric or PIN verification occurred. If the target service requires and properly validates this flag, the attack fails.

Unit 42 successfully tested the attack against eBay, which required user verification but did not properly validate the flag. Conversely, GitHub — which correctly checks this flag — blocked the attack. eBay has since fixed the issue.

Silver Pass-ta-key: malicious key registration

The second attack goes further. It completely bypasses user verification by registering an attacker-controlled verification key in Google’s cloud authenticator.

The mechanism:

1. The malware invalidates Chrome’s existing verification key or deletes the local file containing passkey state.
2. Chrome, believing the device is no longer registered, initiates re-registration with the cloud authenticator.
3. During re-registration, the cloud authenticator does not verify whether the new verification key originates from trusted hardware (the TPM).
4. The attacker registers their own verification key, which Google accepts as proof that the user unlocked their device.

Consequence. The attacker can now authenticate requests with the User Verified flag set, bypassing even services that properly validate this flag. And once the malicious key is registered, the attacker no longer needs access to the victim’s machine — they can operate from their own system.

Golden Pass-ta-key: master key theft

This is the most severe attack. It enables extraction of the security domain secret (SDS) — the master key that encrypts all synced passkeys on the victim’s Google account.

The SDS is temporarily sent to Chrome when a device registers or recovers access to the account. Unit 42 initially discovered that Chrome exposed this secret in plaintext through its internal FIDO logs. Google removed the secret from the logs after the report, but the SDS is still sent to Chrome and remains temporarily accessible in the browser’s process memory.

The attack works as follows:

1. The malware forces device re-registration with the cloud authenticator.
2. During re-registration, it extracts the SDS from Chrome’s memory by searching for a known pattern.
3. With the SDS, the attacker decrypts all synced passkeys on the victim’s Google account and recovers the private keys.

And it does not stop there. Unit 42 warns that Google’s current implementation provides no way to rotate or revoke the SDS. The stolen master key can therefore be used to decrypt future passkeys synced by the compromised account.

An architectural problem, not a cryptographic one

The core finding of the Unit 42 report: passkey cryptography is not broken. The FIDO2/WebAuthn algorithms are solid. The problem is architectural:

• Google’s cloud authenticator trusts the machine without verifying the integrity of the hardware trust chain (TPM → secure enclave → application).
• Device re-registration is treated as a benign event, with no additional challenge (PIN, biometric, second factor).
• The SDS transits through a user-process memory space (Chrome) accessible by any unprivileged malware.

These three weaknesses form a coherent exploitation chain: machine compromise → forced re-registration → SDS extraction → permanent Google account compromise.

What this means for cloud passwordless

Passkeys are promoted by the FIDO Alliance, Google, Apple, and Microsoft as the definitive replacement for passwords. The official narrative: “passkeys cannot be phished, shared, or stolen.”

The Pass-ta-key report nuances this narrative in a fundamental way:

Passkeys remain vastly superior to passwords. They cannot be guessed, reused, or captured by classic phishing. But on a compromised machine, the cloud synchronization architecture introduces a new attack vector that local passwords did not have: stealing the synchronization master key compromises all account passkeys, present and future.

This is the passkey equivalent of stealing the password manager vault — except here, the vault has no rotating lock.

Unit 42’s recommendations

The Palo Alto Networks researchers make four recommendations:

• For websites: require and properly validate the User Verified flag. Do not just request it — verify that the relying party actually received it and that the authenticator correctly set it.
• For credential managers (Google, Apple, Microsoft): validate the hardware origin of verification keys during device re-registration. A key not generated by a TPM must not be accepted.
• For credential managers: harden recovery and re-registration processes. A re-registration must trigger an out-of-band verification (email, second factor, mandatory PIN).
• For credential managers: prevent master keys from becoming accessible in browser memory. The SDS must never reside in the address space of an unprivileged process.

Verdict

Passkeys remain the future of authentication, but the current cloud synchronization architecture is a ticking time bomb. The three Pass-ta-key attacks do not break FIDO2 — they exploit the fact that Google treats a compromised machine as a trusted machine as long as the TPM signs.

For CISOs: continue deploying passkeys — they eliminate mass phishing — but do not treat a compromised Windows machine as a negligible scenario. If an employee runs malware on their workstation, passkeys synced through Google Password Manager are all compromised. The immediate mitigation: require device-bound passkeys rather than synced ones, and enforce the User Verified flag on all internal services.

For Google: the ball is in your court. Golden Pass-ta-key is not a bug — it is an architectural decision that exposes the master key in the memory of a user process. Fixing this is not optional.

References

1. New Pass-ta-key attacks let malware hijack Google-synced passkeys — BleepingComputer, August 3, 2026
2. Unit 42 (Palo Alto Networks) — Pass-ta-key: Three Attacks on Google’s Synced Passkeys, August 2026
3. Google Password Manager — Passkey documentation
4. FIDO Alliance — Passkeys and device-bound credentials