Pass-ta-key steals Google's synced passkeys and the master key can't be revoked

TL;DR

---

On August 3, 2026, Palo Alto Networks Unit 42 published three attack techniques against Google Password Manager’s synced passkeys.
The author is Arie Olshtein, and this is the third post in a series on passkey internals.

Passkeys are a FIDO2/WebAuthn login method: a public/private key pair per service, where the authenticator signs with the private key and the service only ever receives a signed authentication response.
Because there is no password to phish, passkeys have spread as a password replacement. Google syncs them to your account so the same passkey works across devices.

These three attacks go after the parts that were added to make that sync work. The cryptography is not broken.
Unit 42 states it directly: “The attacks presented in this research do not break the underlying cryptography.”

Windows, Chrome, and malware that is already there

What was tested is Google Password Manager in Chrome on Windows, on a machine that has a TPM (a dedicated chip that stores keys and signs with them without letting the key material out).
This is not about macOS, Android, or other password managers.

All three attacks also start from malware already running on the victim’s machine. How that malware gets there is out of scope.
It does not need to escalate to administrator or SYSTEM, though. It runs with ordinary user privileges.

The synced private keys live in Google’s cloud authenticator

Unit 42’s second post, published on March 23, 2026, covers how the sync works.

The private keys for synced passkeys are held by Google’s cloud authenticator. They are not sitting in the device’s TPM.
Chrome opens a WebSocket to wss://enclave.ua5v[.]com/enclave and requests signatures over a channel protected with the Noise protocol.

The key that encrypts those private keys is the Security Domain Secret, or SDS. It is a 32-byte symmetric key per account, and every synced passkey in the account is encrypted and decrypted with that single key.
When a new device joins the account, it receives the SDS through a PIN-protected recovery mechanism.

The device side gets two TPM-backed keys.
The identity key is the device’s own key, the “something you have” factor. The user verification key (UV key) is used only after Windows Hello biometrics or a PIN, and is the “something you know or are” factor.
The private half of the identity key is sealed by the TPM and stored in a file called passkey_enclave_state, as wrapped_identity_private_key.

%LocalAppData%\Google\Chrome\User Data\<Profile>\passkey_enclave_state
%LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB

The LevelDB path is Chrome’s sync database, where synced passkeys live as WebauthnCredentialSpecifics records. Unit 42 calls reading this “stage zero.”
The records hold usernames, credential identifiers, and encrypted private keys, and reading them needs no elevated privileges. This is where an attacker first enumerates which services the victim uses passkeys for.

The three attacks reach different things

Attack	What it uses	What it reaches	Victim device needed	Stopped by unregistering the device
Pass-ta-key	Identity key from passkey_enclave_state	Sign-in to a service, UV flag unset	Yes, the TPM has to sign	Yes
Silver Pass-ta-key	Forged UV key registered during re-enrollment	Fully automated sign-in that passes as user-verified	No, after registration	Yes
Golden Pass-ta-key	SDS from process memory	Every passkey private key in plaintext	No, after the SDS is taken	No

flowchart TD
    A["Malware running on<br/>a Windows machine"] --> B["Read the LevelDB sync database<br/>stage zero"]
    B --> C["wrapped_identity_private_key<br/>from passkey_enclave_state"]
    C --> D["Pass-ta-key<br/>impersonate the device, request a signature"]
    D --> E["Valid assertion<br/>with no UV flag"]
    A --> F["Delete the state file<br/>to force re-enrollment"]
    F --> G["Silver<br/>register an attacker-generated UV key"]
    F --> H["Golden<br/>dump SDS from Chrome memory"]
    G --> I["Account takeover<br/>that passes as user-verified"]
    H --> J["Decrypt every passkey<br/>ready to share or sell"]

Pass-ta-key impersonates the device with its identity key

The first attack starts by pulling wrapped_identity_private_key out of passkey_enclave_state. The TPM has sealed that key, so copying the file to another machine gets you nothing.
On the same machine, though, you can call the Windows crypto API (CNG: NCryptOpenStorageProvider, NCryptImportKey, NCryptSignHash) and have the TPM sign for you. The key material is never read, the TPM is simply asked to use it.

From there the attacker opens a WebSocket handshake with the cloud authenticator and signs the handshake hash and the assertion request with the stolen identity key.
The cloud authenticator treats this as a request from a legitimate device and returns a valid assertion — the signed authentication response a service accepts. Forwarding it to the relying party completes the sign-in.

There is a limit to this path. The assertion is cryptographically valid and matches the public key the service registered, but the UV flag stays unset. That flag is a single bit indicating that biometrics or a PIN were actually used, and signing with only the identity key leaves it at 0.
In Unit 42’s testing, services that request userVerification=required and validate the returned UV flag reject the attack. Services that request it but never check the response let it through.

Silver Pass-ta-key forges the UV key

The second attack removes that UV limitation.

The attacker deletes passkey_enclave_state, or issues the command that unregisters the device, to make Chrome re-onboard. Partway through re-enrollment there is a uv_key_pending state.
At that point the attacker generates their own key pair and sends the public half to the cloud authenticator as device/add_uv_key.

The cloud authenticator does not validate the attestation of the new UV key — the proof that the key really was created inside secure hardware.
Unit 42 puts it this way: “The cloud authenticator does not validate the attestation of newly registered UV keys to verify whether they originate from secure hardware.” The result is that a key sitting on the attacker’s machine is accepted as the user verification key.

With that in place the attacker can produce signatures with the UV flag set, from their own environment. No Windows Hello prompt appears, and the victim’s machine does not need to be online for each sign-in.
From the victim’s side, authentication completes with nothing shown on screen.

This one does go away if the device is unregistered or re-enrolled. The UV key the attacker registered disappears with it.

Golden Pass-ta-key takes the master key itself

The third attack enters the same way, by forcing re-onboarding.

At the moment a new device joins the account, the SDS travels through the recovery mechanism into Chrome. During that handoff it exists in Chrome’s process memory in plaintext.
The attacker watches for passkey_enclave_state being recreated or modified, and dumps Chrome’s process memory at that moment to grab the SDS.

Once the SDS is in hand, reading WebauthnCredentialSpecifics from the sync database and decrypting the encrypted private keys is all that remains.
What comes out is the passkey private keys themselves, in a form that can be handed to someone else or sold.

The SDS is one key per account, and the current implementation has no way to rotate or revoke it.
Unregistering the device after noticing the compromise leaves the attacker’s copy of the SDS valid, and passkeys created afterwards are encrypted with the same key.

The SDS was also appearing in plaintext in Chrome’s internal log at chrome://device-log/FIDO. Google removed it from the logging output after Unit 42’s report.
That change only stops it from being logged. The SDS is still sent to the client and still lands in process memory.

Some services never validate the UV flag

Pass-ta-key is rejected when a service both requests userVerification=required and validates the UV flag in the response it gets back.
Those are two separate things, and there are implementations that do the first without the second.

Unit 42 found services that do not validate the flag, where passkey-based multi-factor authentication effectively drops to a single factor.
The one named is eBay, which fixed it after the report and now validates properly.

That bit lives in the authenticatorData of the authentication response, and when userVerification=required is specified the relying party has to check it explicitly.
Services whose response-validation code never reaches that bit accept Pass-ta-key assertions.

It left the logs, but the SDS still reaches the client

Google removed the SDS from its logging output after the report. Unit 42 says that even after the fix, the SDS is still sent to the client and remains in Chrome’s process memory.
The Google response Unit 42 quotes is about the design goal of the cloud authenticator:

The (cloud) enclave authenticator’s primary function is to make it difficult to steal passkey private data, which would be an obvious target for malware if it were locally available.

Keeping private keys off the local machine is itself the anti-malware measure. This research targets what is left over in that arrangement: the places where the cloud side still has to trust the device.

The WebAuthn signature counter increments on every successful assertion for authenticators that implement it, which gives relying parties a way to spot cloned credentials.
In Unit 42’s analysis, Google Cloud Authenticator’s counter is always 0, so it is useless for detection in this implementation. Google’s response was that implementing a consistent counter across multiple devices and platforms is difficult.

Unit 42 says the exploits were responsibly disclosed, but the post carries no dated timeline.
Whether all three paths are now closed cannot be confirmed from public information either.

What relying parties and implementers can do

Everything Unit 42 recommends is aimed at services and implementers. Nothing here is something an end user can act on.

The immediate one for services is strict UV validation: request userVerification=required, and always validate the UV flag in the authentication response.
That closes the Pass-ta-key path.

The list for credential managers is longer: validate the attestation of newly registered device keys, harden recovery so that deleting a state file does not simply trigger re-onboarding, keep master keys out of the client environment by doing crypto operations server-side, restrict access to the sync database and passkey_enclave_state to the browser process, and implement signature counters that account for synchronization.
Keeping the master key out of the client is the item that closes Golden’s entry point. SDS rotation is not on the list — the absence of any way to do it is described instead as the reason Golden persists.

The passkey weakness that got attention earlier was a different one: overloading an authentication credential with an encryption role. That is covered in the post on why the passkey PRF extension is risky for key derivation.
Pass-ta-key comes in from the sync and recovery side instead, the machinery added to make one passkey usable on several devices.

References

• Unit 42: Pass the Passkey — A Novel Attack Surface in Passwordless Authentication
• Unit 42: Google Cloud Authenticator — The Hidden Mechanisms of Passwordless Authentication
• BleepingComputer: New Pass-ta-key attacks let malware hijack Google-synced passkeys
• The Hacker News: Google Password Manager Attacks Could Let Malware Hijack Passkey-Protected Accounts