Pass-ta-key Shows Synced Passkeys Inherit Endpoint Risk

Unit 42 published three proof-of-concept attacks on August 3 against Google Password Manager's synced passkeys in Chrome on Windows systems with a Trusted Platform Module. Pass-ta-key uses the enrolled device's identity path to request an assertion without local PIN or biometric verification. Silver Pass-ta-key registers an attacker-controlled user-verification key during re-enrolment. Golden Pass-ta-key extracts the security domain secret from Chrome process memory and uses it to decrypt synced passkey private keys.

Every demonstrated path begins with malware already running as the victim on the Windows endpoint. The work does not break WebAuthn signatures, defeat a clean hardware security key, establish a remote zero-click compromise, or document in-the-wild exploitation. It does show that passkey incident response cannot stop at deleting a browser session. Services must verify the signed User Verified flag, credential providers must harden device registration and recovery, and defenders need a recovery plan for synced credentials exposed through a compromised endpoint.

Unit 42's most important scope statement appears before the attack details: its work focuses on Google Password Manager in Chrome on Windows devices with TPM support, and every attack requires malware on the victim's device during the initial stage. The researchers demonstrate implementation abuse from an already compromised user context. They do not present a way for an arbitrary website, remote scanner, or phishing page to steal a synced passkey from a clean endpoint.

That boundary prevents two bad conclusions. It is inaccurate to say passkey cryptography has been cracked, because the attacker obtains or misuses legitimate signing paths and key material around the protocol. It is also incomplete to dismiss the work because malware can already steal cookies and passwords. Passkeys are intended to narrow post-phishing account takeover. If ordinary user-context malware can silently obtain assertions, replace a verification key, or recover portable private keys, credential lifecycle and incident-response assumptions change.

Unit 42 describes proof-of-concept research and responsible disclosure, not an observed criminal campaign. The public article does not provide prevalence, victim counts, malware families, or evidence that Golden Pass-ta-key has been used in the wild. Teams should use it to test architecture and recovery, not to announce that every Chrome user or every passkey-backed account has been compromised.

Google's documentation says passkeys saved in Google Password Manager are backed up and synchronized across devices signed into the same Google Account. On Chrome desktops, Unit 42's architecture analysis describes a Google Cloud Authenticator that works with two TPM-backed device keys. An identity key represents possession of the enrolled device, while a user-verification key is gated by the local Windows Hello gesture. The cloud service also protects a 32-byte security domain secret used to encrypt synced passkey private keys.

Chrome keeps enough local state to use that service. Unit 42 identifies a passkey enclave state file containing wrapped device material and a local sync database containing WebAuthn credential records, including relying-party identifiers, usernames, credential IDs, and encrypted private keys. The private keys are not simply stored in plaintext on disk. The attack surface appears in how an enrolled client proves device identity, how the user-verification key is replaced, and how the master secret is recovered during device onboarding.

This is the tradeoff that makes synchronized credentials useful. A user can recover and use passkeys across devices instead of enrolling a separate key at every service. FIDO guidance distinguishes those synced passkeys from device-bound passkeys that never leave one authenticator. The categories share WebAuthn's phishing resistance, but they do not have identical recovery, portability, ecosystem, or endpoint-compromise properties.

In the first attack, malware reads Chrome's wrapped device identity material and asks the same TPM to perform the signature operations expected from the enrolled computer. Unit 42 says this can occur as the current user without administrator rights, a biometric prompt, or local PIN entry. The cloud authenticator then returns a cryptographically valid assertion for the selected passkey, but the assertion records that user verification did not occur.

The enforcement point is the User Verified bit inside signed authenticator data. WebAuthn Level 3 says that when a relying party requires user verification, it must verify that this bit is set. Unit 42 reports that GitHub rejected its test because the bit was clear. It also demonstrated a successful login against eBay even though the service requested user verification, because the response was not validated correctly. The researchers say eBay fixed that gap after disclosure.

For service operators, setting userVerification to required in a client request is only the first half of the control. The server must parse and validate the returned authenticator data, bind the challenge and origin correctly, verify the signature, and fail the ceremony when the required bit is absent. Tests should include a validly signed assertion with User Verified cleared. A happy-path biometric test cannot prove the negative branch is enforced.

Silver Pass-ta-key targets re-enrolment. The malware invalidates or removes local passkey state so Chrome registers the device again, then substitutes an attacker-controlled user-verification public key. Unit 42 says the cloud authenticator accepts that key without validating its trusted-hardware origin. Requests signed by the replacement key are then treated as user-verified, allowing the attacker to authenticate later from another environment without keeping the victim's endpoint online.

Golden Pass-ta-key targets the security domain secret. During a new-device or recovery flow, Chrome retrieves this master key so synchronized passkeys can be recovered. Unit 42 first found the secret in Chrome's internal FIDO logs. Google removed that logging exposure after the report, but the researchers say the secret is still sent to Chrome and appears temporarily in process memory. Malware that forces re-onboarding can watch for the state change, dump the process, locate the secret, and decrypt the encrypted private keys stored in Chrome's sync records.

The recovery consequences differ. Unit 42 says removing or re-enrolling the affected device can mitigate the Silver path. For Golden, the researchers report that Google's current implementation has no way to rotate or revoke the security domain secret, which also protects future synchronized passkeys. That is a research claim about the studied implementation, not an official Google incident advisory. It is nevertheless a material design question for any organization promising that compromised synced credentials can be invalidated cleanly.

When malware is confirmed on a Windows device that used Google Password Manager passkeys, preserve the evidence needed to determine whether browser state, onboarding, or Chrome process memory was accessed. Useful signals include creation or deletion of the passkey enclave state file, unexpected Google Password Manager PIN or recovery prompts, new device or sign-in-method registrations, suspicious access to Chrome's sync database, process-memory collection, and authentication from unfamiliar devices or networks.

Contain the endpoint and recover it from a trusted baseline before creating replacement credentials. Review the Google Account device list, recent security activity, passkeys, security keys, and newly added sign-in or recovery methods from a separate clean device. Remove unrecognized methods and sign out suspicious sessions. For third-party services, revoke the affected passkey at each relying party and register a replacement from the clean environment. A browser reinstall alone does not invalidate a credential already registered at a service.

Do not promise that changing the Google Password Manager PIN rotates every secret described in the research. Google's help pages explain how to change the PIN, delete Password Manager data, remove Google Account passkeys, and sign devices out, but they do not document a user operation that rotates a possibly exposed security domain secret. Where Golden-path exposure is plausible, escalate to the credential provider and each high-value relying party, record the support answer, and prefer newly enrolled device-bound credentials for recovery until the scope is resolved.

The right conclusion is not to retreat to passwords. Passkeys still prevent password reuse, credential stuffing, and ordinary origin-confusing phishing. Unit 42 explicitly says they remain a meaningful security improvement. The stronger conclusion is that a passkey deployment has at least four control owners: the relying party that verifies assertions, the credential manager that syncs and recovers keys, the endpoint that presents trust signals, and the incident team that must revoke access after compromise.

Use assurance tiers. Synced passkeys can provide a strong replacement for passwords across ordinary workforce and consumer accounts. For administrators, recovery personnel, finance approvers, source-code maintainers, and other high-impact identities, consider device-bound platform credentials or hardware security keys, plus an independently stored recovery key. FIDO's moderate-assurance guidance similarly presents synced credentials for standard accounts and device-bound passkeys for accounts needing the highest assurance.

Finally, test the failure path before rollout. Confirm that every service requiring user verification rejects an assertion with the signed bit cleared. Inventory which passkeys are synced or device-bound. Practice removing one compromised device, revoking one credential at the relying party, registering from a clean device, and restoring access without falling back to weak email or SMS recovery. If the organization cannot name the master-secret rotation path, the detection evidence, or the revocation owner, the passwordless project is not yet incident-ready.