Pass-ta-key: malware can hijack Google-synced passkeys

Passkeys were designed to remove the phishable password from sign-in. Palo Alto Networks Unit 42 has now shown that malware already running on a Windows computer can attack Google Password Manager’s synchronisation implementation. The Pass-ta-key family does not break FIDO cryptography and cannot remotely “guess” a key. It abuses the trust that the cloud passkey store and relying service place in a compromised device.

That distinction matters. Passkeys remain stronger than passwords against conventional phishing, but they are not a shield against endpoint compromise. Organisations need to combine phishing-resistant authentication with device controls, correct user verification validation and a secure account-recovery path.

Three variants of the problem

Unit 42’s research covers Chrome on Windows with TPM-protected keys. Every scenario requires malicious code execution on the user’s device.

Pass-ta-key uses the TPM-backed device identity to request a valid assertion for an existing passkey. Researchers obtained it without a consent dialog, biometrics, a Windows Hello PIN or administrator rights. The assertion’s user verified flag was false. GitHub rejected it because it checked that property; eBay initially accepted the sign-in and corrected its validation after disclosure.

Silver Pass-ta-key forces the device to re-register with Google’s security domain. During that process, an attacker can add a user-verification key they control. The researchers found that the cloud authenticator did not verify that the key came from the expected hardware-backed mechanism. It could then approve authentication from a separate device.

Golden Pass-ta-key targets the Security Domain Secret used to protect synchronised private keys. Google removed earlier plaintext FIDO data from logs, but the secret must still exist briefly in Chrome process memory during legitimate use. Malware with process access can attempt to extract it and decrypt key material. Unit 42 also notes that users do not currently have a simple security-domain rotation mechanism analogous to changing a password.

Who is affected

The tests cover a particular combination: Google Password Manager, Chrome, Windows and synchronised passkeys. They do not prove that every manager, operating system or hardware token behaves the same way. Nor is every relying party equally exposed—the GitHub result shows that validating the assertion properties blocks the first variant.

Risk is higher when:

• employees can run unapproved code, scripts or supposed helper tools;
• EDR does not protect browser processes or detect memory-access attempts;
• a service accepts an assertion without the required user-verification flag;
• device enrolment and account recovery are weaker than routine authentication;
• the organisation assumes that deploying passkeys completes its identity-security work.

What to do now

Users should update Chrome and Windows and treat any suspected malware infection as a compromise of sessions, passkeys and other secrets available to that endpoint. Clearing the browser is not enough. Isolate and investigate the host, revoke sessions, review enrolled devices and re-establish authentication from a known-clean system.

Service developers should require the appropriate user-verification level and test negative WebAuthn cases. A valid signature is only one check; expected rpId, origin, challenge, counter and UV/UP flags also matter. Device registration and recovery should require evidence at least as strong as everyday authentication.

Administrators can reduce exposure with application allowlisting, browser-process protection in EDR, removal of local-admin rights, telemetry for new device registration and alerts on unusual recovery actions. For privileged accounts, non-synchronised hardware keys may be appropriate when the threat model warrants them.

Our guides to passkeys and passwordless authentication and session theft by infostealers provide the wider operational context.

Primary facts versus Breachroad analysis

Unit 42 confirms the three lab scenarios, their prerequisite—malware on the endpoint—and coordinated disclosure to Google and the tested services. Google and eBay made the changes described by the researchers. BleepingComputer provides an independent account of the disclosure.

Breachroad’s conclusion is that a synchronised passkey should be treated as a secret whose assurance depends on endpoint health and account recovery, not as an isolated password replacement. Cybersecurity and phishing training helps users avoid the infection path, while an IT security audit can assess WebAuthn policies, device controls and identity-compromise response.