Google Passkeys Can Be Hijacked. Not the Cryptography. The Cloud Sync.

Passkeys were supposed to fix the credential problem. Unit 42 just published three attacks that show cloud-synced passkeys can be hijacked from a compromised device. The cryptography is fine. The problem is one layer up.

The research is named Pass-ta-key. It covers three distinct techniques — Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key — each targeting a different point in how Google Password Manager handles cloud-synced passkeys in Chrome on Windows devices with a Trusted Platform Module. Unit 42 coordinated disclosure with Google and affected services before publishing.

The first technique, Pass-ta-key, does not require administrator privileges, user interaction, biometrics, or device unlock. Unprivileged malware already running on the victim's machine can impersonate the device to Google's cloud authenticator and receive a valid authentication response for any of the victim's synced passkeys. There is an important caveat: the authentication response includes a User Verified flag indicating whether biometric or PIN verification occurred. If a service properly validates this flag, the attack fails. Unit 42 confirmed this: the attack failed against GitHub, which checks the flag correctly. It succeeded against eBay, which required user verification but did not validate whether it actually occurred. eBay fixed the issue after disclosure.

The mechanism is specific. Chrome uses a TPM-backed device identity key to establish trust with Google's cloud authenticator. This key exists to prove that a request is coming from a legitimate enrolled device. But the key is accessible to processes running with standard user privileges. Malware running in that context can use it to sign authentication requests that Google's cloud authenticator accepts as coming from a trusted device.

Why This Attack Works

The fundamental issue is the design choice that makes cloud-synced passkeys useful: they need to work across multiple devices. When you get a new laptop, your passkeys should be available without going through a new enrollment process for every account. Google solves this by keeping an encrypted copy of your passkeys in the cloud and provisioning them to new devices through the Google account.

That provisioning flow requires the cloud authenticator to decide what counts as a "trusted device" that is allowed to receive or use a synced passkey. Chrome's TPM-backed device identity key is the mechanism Google uses to make that determination. The assumption is that only legitimate Chrome instances on enrolled devices can use that key.

The assumption holds against remote attackers who do not have access to the device. It does not hold against malware that is already running on the device with standard user privileges, because that malware has access to the same environment Chrome operates in, including the mechanisms Chrome uses to prove its identity.

The cryptography of the passkey itself is not broken. The private key is protected by the TPM and cannot be directly extracted in most configurations. But the attacker does not need to extract the private key. They only need to convince Google's cloud authenticator that they are a trusted device, and then use the authentication response they receive.

Silver Pass-ta-key and Golden Pass-ta-key: The Escalating Severity

The basic Pass-ta-key technique can be blocked by services that properly validate the User Verified flag. Silver Pass-ta-key eliminates that defense. The attacker uses malware on the compromised device to force Chrome to re-register by invalidating its existing verification key or deleting the local passkey state file. During re-registration, the attacker registers a user-verification key they control, because Google's cloud authenticator does not validate whether the new key originated from trusted hardware. Once registered, the attacker's key is accepted as proof that the victim completed biometric or PIN verification. This allows the attacker to authenticate to services that require and properly validate user verification — and to do so from a completely separate system, without further access to the victim's device.

Golden Pass-ta-key is the most severe of the three. It targets the security domain secret: the master key Google uses to encrypt all passkeys synced through the victim's Google Password Manager account. Chrome receives this secret temporarily when a device registers or recovers access to the Google account. Unit 42 initially found it exposed in plaintext in Chrome's internal FIDO logs. Google removed it from the logs after disclosure, but the secret is still sent to Chrome and remains accessible in the browser's process memory. An attacker who forces a re-registration and knows the memory pattern can extract it directly. Once obtained, the stolen master key decrypts all of the victim's current synced passkeys and all future ones added to the account. Google's current implementation provides no mechanism to rotate or revoke this key, meaning a successful Golden Pass-ta-key attack has permanent consequences for the victim's entire passkey portfolio.

The Cloud Security Layer Nobody Is Watching

Most enterprise cloud security reviews focus on three layers: the infrastructure layer (cloud provider configuration, S3 buckets, storage permissions), the application layer (SaaS misconfigurations, overprivileged OAuth apps), and the identity layer (MFA enforcement, privileged access management, conditional access policies).

What Pass-ta-key exposes is a fourth layer: the cloud credential provisioning layer. This is the trust model that governs how cloud-based authentication systems decide which devices can access which credentials. Most security teams do not have explicit coverage of this layer in their threat models, because it was not an attack surface that existed before cloud-synced passkeys became mainstream.

The assumption embedded in most zero-trust frameworks is that device trust equals user trust: if the device is enrolled, compliant, and managed, the user on that device is who they claim to be. Pass-ta-key shows that this equivalence can be violated when malware is present, even when the device passes all compliance checks. Malware running with user privileges does not trigger device compliance failures. It just runs alongside the legitimate Chrome instance and uses the same trust infrastructure.

I have reviewed cloud security architectures for organizations in financial services, healthcare, and government. In every case, the identity trust model assumed that a managed, compliant device was a sufficiently trusted environment for cloud credential access. This research is a direct challenge to that assumption.

Hardware-Bound Keys Versus Cloud-Synced Passkeys

This is the comparison that matters for enterprise authentication decisions.

Hardware-bound FIDO2 keys, physical security keys like YubiKey or Google Titan, store the private key inside hardware that cannot be exported. Authentication requires the physical key to be present and, for higher-assurance configurations, a PIN or biometric confirmation directly on the device. There is no cloud sync layer. The private key never leaves the hardware. Pass-ta-key has no attack surface here because there is nothing in the cloud to impersonate access to.

Cloud-synced passkeys trade that assurance for convenience. They work across devices without carrying a physical key. They recover automatically when you get a new phone or laptop. They are significantly better than passwords. But they introduce a cloud sync layer with a trust model that, as Pass-ta-key demonstrates, can be attacked from a compromised device without elevated privileges.

The implication for enterprise authentication architecture is not that passkeys are bad. It is that the choice between hardware-bound and cloud-synced authentication should be made explicitly based on the risk profile of the accounts being protected, not by default.

What CISOs Should Do Now

Require hardware-bound FIDO2 for privileged accounts. Administrators, service account managers, cloud infrastructure owners, and executives with access to sensitive data should authenticate with physical security keys, not cloud-synced passkeys. This is true even if cloud-synced passkeys are acceptable for standard users. The risk profile is different, and the controls should reflect that.

Strengthen endpoint security on devices where passkeys are enrolled. Pass-ta-key requires malware to already be on the device. The primary control is preventing malware from getting there. Endpoint detection and response coverage, application allowlisting, privilege reduction, and browser extension controls all reduce the probability of a successful device compromise that could enable this attack.

Update your threat model to include cloud credential provisioning as an attack surface. Your cloud security architecture documentation should explicitly account for how device trust translates to cloud credential access. If you are using Google Workspace or Chrome Enterprise with cloud-synced passkeys, document the trust chain and where it can be broken.

Review device compliance enforcement as a gate for sensitive cloud operations. If your identity policies allow cloud authentication from devices that are not continuously monitored and compliant, you are relying on the cloud sync trust model without the endpoint security foundation it requires. Conditional Access or equivalent controls should enforce compliance posture as a condition of cloud authentication, not just device enrollment.

Brief your security architecture team on the distinction between hardware-bound and cloud-synced passkeys. Many organizations made authentication decisions based on FIDO2 passkeys as a category without distinguishing between these two deployment models. That distinction now has a meaningful security impact. The next authentication architecture review should make it explicit.