Pass-ta-key: your synced passkeys are only as strong as the endpoint

On 3 August 2026, Unit 42 published Pass the Passkey: A Novel Attack Surface in Passwordless Authentication, the third part of its series on Google's cloud authenticator. It contains three working techniques that let malware running as the logged-in, unprivileged user on a Windows machine produce valid WebAuthn assertions for that user's passkeys — no biometric, no device unlock, no administrator rights — and, in the strongest case, walk off with the master key that decrypts every passkey synced to that Google account. None of it breaks WebAuthn's cryptography. All of it breaks the sentence that most security programmes wrote into their MFA rollout document: passkeys are phishing-resistant, therefore this control is done.

What Pass-ta-key actually does to a synced passkey

The mental model most people carry — "my passkey lives in the TPM, the TPM requires my fingerprint" — is not how Google Password Manager works on Chrome for Windows. Three separable secrets are in play:

• A device identity key, hardware-backed by the TPM, which proves to Google's cloud authenticator that this is an enrolled device.
• A user verification (UV) key, which signs the one bit that tells a relying party a human was present and verified.
• The Security Domain Secret (SDS), a 32-byte master key that decrypts the passkey private keys held in the sync fabric.

Because those are separable, they fail separately. Unit 42's first technique extracts the wrapped identity private key and drives it through standard Windows CNG calls — NCryptOpenStorageProvider, NCryptImportKey, NCryptSignHash — to sign attacker-chosen challenges. The report attributes the reachability to how Chrome creates the key: "Chrome calls the NcryptCreatePersistedKey function without assigning a key name, making the TPM-backed key ephemeral." The TPM did its job. It signed for a process that asked, which is what it is for.

The three techniques, ranked by how long the damage lasts

Technique	What it abuses	What the attacker gets	Survives an endpoint rebuild?
Pass-ta-key	TPM-backed device identity key via Windows CNG	Valid assertions on demand, with the UV bit unset	No — needs code on that host
Silver Pass-ta-key	The re-enrolment window where Chrome defers UV key creation; the cloud authenticator "does not validate the attestation of newly registered UV keys"	An attacker-controlled UV key, so sign-in works from the attacker's own machine	Yes, until the rogue key is removed
Golden Pass-ta-key	The SDS, briefly present in plaintext in Chrome's process memory during re-onboarding	The master key to every passkey in that security domain, decryptable anywhere	Yes, until the security domain is re-keyed

The Golden/Silver naming borrows from Kerberos ticket attacks and it earns the borrowing: the same escalation from I can act as you, here, while I have code on your box to I hold the key material that mints you, anywhere, indefinitely. All three start from the same place — malware already running as the logged-in user, no elevation required.

The UV flag is a one-bit contract, and only the relying party can enforce it

A Pass-ta-key assertion is bit-for-bit indistinguishable from a legitimate one except for a single flag. The W3C WebAuthn Level 3 specification is unambiguous about whose job that is: "If the Relying Party requires user verification for this registration, verify that the UV bit of the flags in authData is set."

That is a server-side step. And here is the part worth sitting with: eBay accepted these forged assertions despite configuring userVerification: "required", until Unit 42 reported it. Setting userVerification: "required" in the request options expresses a preference to the client. Checking the UV bit in the response is the control. A large number of WebAuthn integrations do the first and skip the second, because the ceremony succeeds either way and nothing in the happy path ever tells you.

This exact failure already shipped in a password manager three years ago

Zero Hunt's Knowledge RAG surfaced a precedent from the pre-2026 corpus that the news cycle would not have led us to, and both entries re-verified on NVD before we cite them here:

• CVE-2023-27706 (published 9 June 2023, CVSS 7.1): "Bitwarden Windows desktop application versions prior to v2023.4.0 store biometric keys in Windows Credential Manager, accessible to other local unprivileged processes."
• CVE-2023-38840 (published 15 August 2023, CVSS 5.5): "Bitwarden Desktop 2023.7.0 and below allows an attacker with local access to obtain sensitive information via the Bitwarden.exe process."

Those are the two failure modes Unit 42 just re-demonstrated, three years early, in a different credential manager: key material parked in an OS store that any unprivileged local process can reach, and a secret sitting in the application's own memory. Both scored modestly — 7.1 and 5.5 — because AV:L discounts everything, and the industry filed them under local access required, therefore out of scope. Then the industry moved passwordless authentication into the same architecture and did not revisit the assumption.

The generalisable lesson is not about Bitwarden or Google. It is that "requires local code execution" is a severity discount, not an architectural exemption — and once your authentication story depends on the endpoint being clean, the endpoint is your authentication story.

What AAL2 actually promised about synced passkeys

This is where it stops being an interesting attack write-up and starts being a compliance problem.

NIST SP 800-63B-4, finalised in July 2025, is the document that made synced passkeys formally acceptable at AAL2 and thereby unblocked a great deal of enterprise adoption. It defines the category in §3.1.6.1 — "Some cryptographic authenticators, referred to as syncable authenticators, can manage their authentication keys using a sync fabric (e.g., a cloud provider)" — and it already drew a line in §2.3.2: "Since syncable authenticators … require the private key to be exportable, syncable authenticators SHALL NOT be used at AAL3."

The AAL2 blessing is conditional. Appendix B.2 sets out what the sync fabric must do:

• "Authentication keys stored in the sync fabric SHALL be protected by access control mechanisms such that only the authenticated user can access their authentication keys in the sync fabric."
• "User access to authentication keys in the sync fabric SHALL be protected by AAL2-equivalent MFA to preserve the integrity of the authentication protocols using the synced keys."
• Cloned or exported keys SHALL only be stored encrypted, and SHOULD be "encrypted using a method that employs a user-controlled secret."

Read those against the three techniques. The SDS is the user-controlled secret in the third requirement — and Golden Pass-ta-key reads it out of process memory. The access control in the first requirement is satisfied, from the sync fabric's point of view, by a validly enrolled device — which is precisely what Pass-ta-key impersonates. The requirements are not wrong. They are conditional on the state of a client that the requirements have no way to inspect.

That matters well beyond NIST, because NIS2 Article 21 names multi-factor or continuous authentication as a required measure, DORA leans on the same expectation for financial entities, and the artefact everyone produces to satisfy it is an enrolment report. The AAL2 claim underneath that report rests on Appendix B.2 holding true on every endpoint, every day. No audit programme we have seen asks that question.

Auditor: "Show me that privileged access uses phishing-resistant MFA." You: "Every administrative account is on passkeys. Here's the policy and the enrolment coverage report — 100%." Auditor: "Approved."

Nothing in that exchange tested whether an assertion could be produced without the human. That was never the question, because until this week nobody had to ask it.

The scale is not marginal. The FIDO Alliance's State of Passkeys 2026, published 7 May 2026, reports "5 billion passkeys are now in use worldwide", that "68% of organizations have deployed or are actively deploying passkeys for employee sign-ins", and that 49% of people use passkeys regularly where available. This is the authentication substrate now, not a pilot.

Remediation

1. Am I affected?

Three distinct exposures, and you can hold any combination of them:

• As an endpoint owner — Windows hosts with a TPM, running Chrome with Google Password Manager passkeys enabled.
• As a relying party — any service you operate that accepts WebAuthn assertions is exposed to the UV-flag half of this regardless of which authenticator your users hold.
• As an identity owner — workforce accounts whose passkeys are synced rather than device-bound.

Locate the passkey enclave state Unit 42's techniques manipulate:

where /r "%LOCALAPPDATA%\Google\Chrome\User Data" passkey_enclave_state*

Then audit the relying-party side, which is the exposure you fully control. The flags byte sits at offset 32 of authenticatorData; UV is bit 2:

UV = 0x04
if not (authenticator_data[32] & UV):
    raise AuthnError("UV flag not set — reject the assertion")

Grep your codebase for userVerification and confirm that every place setting "required" on the request has a matching flag check on the response. If your integration only sets the request option, you have the bug eBay had.

2. Patch — exact fixed versions

There are none, and that is the honest answer rather than a gap in this write-up. Unit 42's report carries no CVE identifiers, names no fixed Chrome version, and describes design behaviour rather than a memory-safety defect. What has actually changed:

Change	By whom	Status as of 3 Aug 2026
SDS removed from Chrome's FIDO logging output	Google, after disclosure	Done — but the SDS still reaches Chrome's process memory during onboarding
UV flag validated on inbound assertions	eBay, after disclosure	Done
Attestation validated for newly registered UV keys	—	Not addressed
SDS withheld from the client entirely	—	Not addressed

Treat this as a design exposure with an open-ended window, not a patch cycle. The controls you own are on the relying-party side and in authenticator choice.

3. Can't fix the platform? Compensating controls

• Enforce UV server-side, everywhere. Not the request option — the response flag. This single check neutralises the first technique against your own services.
• Require attestation for newly registered keys. This is what closes Silver Pass-ta-key: a UV key that appears without acceptable attestation is not a re-enrolment, it is an injection.
• Move Tier-0 to device-bound authenticators. NIST already told you synced keys do not reach AAL3. Domain admins, break-glass accounts, IdP administration, cloud root: hardware security keys or platform-bound passkeys, not synced ones. This is the highest-value control on the list and it needs no vendor to ship anything.
• Do not count on signCount. Synced authenticators report a constant signature counter, so the classic clone detector does not fire here. Say so explicitly in your runbook rather than leaving a team believing it has a tripwire it does not have.
• Treat re-onboarding as a security event. Both Silver and Golden require forcing a re-enrolment. An unexpected recovery-PIN prompt, or a device re-registration in the middle of a routine sign-in, is the user-visible observable — tell your service desk what it means.
• Step up on consequence, not on login. A passkey assertion is one signal about one device. High-consequence actions — payment release, privilege grant, bulk export — should require a factor anchored somewhere the endpoint malware is not.
• Browser policy: verify, do not assume. As of publication we could not identify a Chrome Enterprise policy scoped specifically to the passkey enclave; PasswordManagerEnabled and SyncTypesListDisabled govern password saving and sync data types. Check the current policy list before writing a control into a standard.

4. Hunt for compromise

Signal	Where to look	ATT&CK
Non-Chrome process opening Chrome's User Data credential files	File-access telemetry / Sysmon	T1555.003
Deletion of passkey_enclave_state	File-delete telemetry	T1556
Handle opened to chrome.exe with PROCESS_VM_READ from a non-Google-signed image	Sysmon Event ID 10	T1555
ncrypt.dll loaded, plus CNG signing calls, in a process with no cryptographic role	Sysmon Event ID 7 + API telemetry	T1552.004
New device enrolled into the Google security domain	Google Workspace admin audit log	T1556
Assertion accepted with UV unset where policy requires verification	Relying-party authentication logs	T1606
Valid assertion from an unfamiliar ASN, constant signCount	Relying-party authentication logs	T1550

Start from SigmaHQ's Access To Browser Credential Files By Uncommon Applications (id 91cb43db-302a-47e3-b3c8-7ede481e27bf, tagged attack.t1003, requires the Microsoft-Windows-Kernel-File ETW provider). Then read what it actually covers: \User Data\Default\Login Data and \User Data\Local State. It does not cover the passkey enclave state. Add it. The default browser-credential-theft hunt that most SOCs already run will not see this class of activity, which is exactly the sort of gap that reads as coverage on a dashboard.

On the look-back window: Unit 42 published on 3 August 2026, but the techniques target design behaviour that has existed for as long as the enclave has. Scope your hunt to your infostealer incident history, not to this week. Every commodity stealer that ran on a host with synced passkeys was standing next to this.

5. Eradicate and verify

Order matters, and getting it wrong wastes the rotation:

1. Contain the endpoint before you touch the account. Rotating while the malware is live simply hands over the replacement material.
2. Assume the whole synced set is burned, not just the passkey you saw used. If Golden is in scope, the SDS decrypts every passkey in that security domain.
3. Re-key the security domain — do not merely re-register a passkey. Deleting a credential at one relying party leaves the master key valid for all the others. Remove the device from the Google account, change the account password, sign out all sessions, reset the recovery PIN, then re-register at each relying party.
4. Rotate everything else that endpoint held. The same malware had the session cookies, OAuth refresh tokens and SSO artefacts. A passkey rotation that leaves live sessions standing is theatre — the same lesson as stolen SharePoint machine keys, where the key material outlived the patch.
5. Rebuild the host. A credential-theft implant that reached CNG and another process's memory is not something you remove selectively.
6. Verify at the relying party, not at the endpoint. Replay an assertion with UV unset against your own service in a test harness and confirm it is rejected. That is the only evidence the control exists. The enrolment report is evidence that it was purchased.

One clock to watch: under NIS2 and GDPR the reporting window runs from awareness, not from confirmation. If synced passkeys covering workforce identities were exposed on a compromised host, the quality of your hunt evidence is itself the deliverable — the same dynamic that made forged token-signing material at the ADFS layer so difficult to scope after the fact.

Where Zero Hunt fits

The gap this research exposes is not a missing product; it is that "phishing-resistant MFA deployed" is an assertion, and almost nobody generates evidence that the assertion still holds. Zero Hunt maps every finding, scan and remediation continuously against 32 frameworks — NIS2 including Title 13, DORA including the TLPT RTS 2025, ISO 27001, SOC 2, NIST CSF — with severity-weighted scoring and cross-framework control mapping, so a single tested authentication control lands against every framework that asks for it instead of being re-evidenced in three separate audit exercises. Findings are ECDSA-signed at write time with chain-of-custody by construction, and the Trust Center exports the bundle an auditor or an insurer will actually accept. That is the difference this article is about: an enrolment report says a control was deployed, and a signed finding says it was tested — on a date, on a host, with a result.

Producing that evidence needs something that runs the chain rather than reasoning about it. Zero Hunt's 10-agent swarm — Recon, Exploit, Web, Credential, Post-Exploit, Pivot, Tactic and Report under an AI Controller — is organised around exactly the sequence Unit 42 describes: code on a host, then credential material, then identity, then movement. The Credential and Post-Exploit agents work the question the audit never asks — given user-level execution on this endpoint, what identity material is reachable and what does it authenticate to — and exploits are generated per target by a local LLM rather than pulled from a public database, with every new skill backtested in the AI Gym before it touches a production campaign. The whole appliance runs on-prem in ephemeral containers with no cloud callback, which matters more than usual when the assets under test are the identity systems themselves. If you want to see it against your own authentication estate, talk to us.