Pass-ta-Key: When Synced Passkeys Trust a Compromised Host

The first useful clue is not a failed login. It is a file that changes under Chrome’s profile while a recovery prompt appears for no obvious reason.

In a composite lab scenario, an operator already running as the logged-on Windows user watches %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB, finds WebAuthn credential metadata, and forces the browser through device onboarding again. The passkey itself was never phished. The signature is valid. Yet the authentication boundary has moved beneath the relying party.

That is the uncomfortable result of Unit 42’s August 2026 research into Google Password Manager on Chrome for Windows: passkeys can keep their origin binding and still fail to contain an endpoint compromise. The work describes three Pass-ta-key attacks that target device trust, user-verification registration, and synced-key recovery—not WebAuthn’s public-key cryptography.

The guarantee is narrower than the slogan

A passkey gives the relying party an RP-scoped public key. During authentication, the authenticator signs authenticatorData || SHA-256(clientDataJSON) with the corresponding private key. The browser supplies the origin and challenge context; the authenticator data carries flags including user presence (UP), user verification (UV), backup eligibility (BE), and backup state (BS). The WebAuthn Level 3 specification is explicit about these semantics.

This design removes the reusable server-side secret and makes ordinary credential phishing largely irrelevant. It does not prove that every component allowed to request a signature is uncompromised. Synced passkeys add another system around the ceremony: a provider must enroll devices, authorize cloud cryptographic operations, recover access, and make encrypted credentials available across platforms. Google’s own passkey environment documentation describes that sync and the Google Password Manager PIN used on a new environment.

The practical trust chain is therefore longer than “browser talks to authenticator”:

Relying party
    ↕ WebAuthn assertion
Browser / OS client
    ↕ device identity + user-verification state
Cloud authenticator
    ↕ recovery / synchronization fabric
Encrypted passkey corpus

Pass-ta-key attacks the middle of that chain after malware has obtained local user execution. This prerequisite matters. The research does not describe a drive-by remote bypass, and it does not make passkeys equivalent to passwords. It changes the post-compromise question from “can the infostealer read a password?” to “which trust and recovery operations can code in this session impersonate?”

Three paths through the same trust boundary

Unit 42’s primary report separates the problem into three escalating techniques.

Pass-ta-key reuses the device identity path. Chrome creates a TPM-backed identity key on Windows and stores a wrapped representation in passkey_enclave_state. According to the research, ordinary user-level code on the same machine can cause that key to sign requests without an administrator token, biometric gesture, or device-unlock prompt. The cloud authenticator returns a cryptographically valid assertion, but its UV bit is zero.

That last bit is decisive. GitHub rejected the researchers’ test because user verification was absent. eBay accepted the assertion despite requesting verification, then corrected its validation after disclosure. A relying party that asks the client for userVerification: "required" but fails to reject UV=0 has implemented a preference, not a policy.

Silver Pass-ta-key removes that limitation. By forcing a fresh onboarding flow, the attacker registers a user-verification key under attacker control. The cloud service then accepts signatures from that key as proof of local verification, producing assertions with UV=1. The attacker no longer needs to keep relaying through the victim device. This is the difference between abusing a trusted workstation and manufacturing portable trust.

Golden Pass-ta-key targets the Security Domain Secret (SDS), a 32-byte master secret used to protect synced passkey material. Re-enrollment causes Chrome to receive the SDS in recoverable form. Google removed it from Chrome’s logging output after Unit 42 reported the issue, but the researchers state that it still appears temporarily in browser process memory. Extracting it allows decryption of the victim’s current synced passkeys and, because future credentials use the same secret, potentially later ones as well. At publication time, Unit 42 reported no mechanism to rotate or revoke that SDS.

These are not three names for replay. The first depends on RP validation and continued access to the device. The second forges a stronger device-verification relationship. The third recovers the material below individual credentials. Remediation therefore differs: fixing an RP’s UV check stops the first path, re-enrolling a device can break Silver persistence, while Golden requires a provider-level answer to master-secret rotation.

A safe RP-side test that catches the first failure

Security teams can reproduce the relying-party error without extracting a key or touching a real account. In an isolated WebAuthn test tenant, capture the decoded authenticatorData produced by your verifier and make UV enforcement an explicit assertion. The flags byte is offset 32; bit 0x04 is user verification.

# Lab-only verifier invariant: no credentials or private keys involved.
def require_uv(authenticator_data: bytes) -> None:
    if len(authenticator_data) < 37:
        raise ValueError("truncated authenticatorData")

    flags = authenticator_data[32]
    user_present = bool(flags & 0x01)
    user_verified = bool(flags & 0x04)

    if not user_present or not user_verified:
        raise PermissionError(
            f"WebAuthn policy failed: UP={user_present}, UV={user_verified}"
        )

The important test is end to end. Set userVerification: "required" when generating PublicKeyCredentialRequestOptions, submit a syntactically valid assertion with UV cleared in the lab fixture, and require a hard authentication failure. Do not rely only on the browser request option; the server must validate the returned flag against the ceremony policy. Also verify the RP ID hash, challenge, origin, signature, credential ownership, and backup flags according to your account policy. UV is one invariant, not the entire verifier.

For high-assurance workflows, store BE and BS at registration and feed them into risk decisions. They tell the RP whether a credential is backup-eligible and currently backed up. They do not identify the provider, list synchronized devices, or prove hardware provenance. Microsoft’s June 2026 synced-passkey FAQ notes that administrators cannot currently see or control exactly which devices hold a synchronized copy.

Hunt the transition, not a magical passkey event

There is no single Windows event that says “Golden Pass-ta-key succeeded.” The useful detections sit at the transitions required to reach it.

Start with non-browser access to passkey state. Monitor reads or modifications under Chrome profile sync databases and files containing passkey_enclave_state, especially by unsigned processes, script hosts, recently written binaries, or processes with no normal browser-management role. A LevelDB read alone is noisy—backup, EDR, indexing, and browser utilities can touch profile data—so combine it with process lineage and subsequent identity events.

Next, watch browser process access. Golden requires observing Chrome memory around re-enrollment. Sysmon Event ID 10 or equivalent EDR telemetry can expose a non-security process opening chrome.exe with VM-read rights. The exact GrantedAccess mask varies by collection and OS build; baseline your fleet rather than shipping a brittle constant. Credential dumpers, accessibility products, EDR sensors, crash handlers, and debugging tools create legitimate process-access events, so signer, parent process, destination user, and timing are mandatory context.

Then correlate state reset with recovery. Deletion or recreation of passkey enclave state followed by a Google Password Manager PIN prompt, new device enrollment, or passkey authentication from a new geography is stronger than any signal alone. The recent ClickFix analysis on this site shows why the initial process chain still matters: social execution and commodity malware are plausible entry points into this identity attack surface. Browser-resident compromise also deserves attention; OWAReaper’s half-click chain is a useful reminder that browser and identity telemetry cannot be operated as separate investigations.

Finally, make the RP produce evidence. Log credential ID (safely pseudonymized where required), UP, UV, BE, BS, sign counter, authentication policy requested, result, source device context, and credential-management events. Synced authenticators often return a constant sign counter, so counter regression is not a reliable universal cloning detector. The 2025 USENIX paper CASPER is relevant because it treats leaked synced passkeys as a detection problem rather than pretending synchronization has no compromise mode.

Architecture decisions after the research

The wrong response is to abandon passkeys. Passwords remain remotely phishable, reusable, and valuable after a verifier breach. Passkeys still remove those attack paths. The useful response is to stop treating every passkey deployment as one assurance class.

For ordinary workforce and consumer accounts, synced passkeys often deliver the best balance of phishing resistance and recovery. For administrators, break-glass identities, code-signing access, financial approval, and other high-impact roles, use device-bound credentials or hardware security keys with controlled enrollment and backup authenticators. Microsoft’s current Entra guidance makes the same population distinction.

Relying parties should enforce UV, inventory fallback routes, alert on authenticator addition and recovery, and provide a way to revoke every registered credential quickly. Endpoint teams should classify passkey stores, browser memory, and onboarding state as credential-sensitive. Identity teams should assume that a valid assertion can still emerge from a compromised client and apply risk signals to new-device and sensitive-action flows.

The strategic point is precise: phishing resistance protects the ceremony from a hostile origin. It does not make a hostile endpoint trustworthy. Pass-ta-key shows where the next contest moves once attackers can no longer ask users to type the secret.