As of the end of 2025, more than 7 billion online accounts worldwide support passkey sign-in. Google reports that passkeys enable sign-in 40% faster than passwords, and Intuit has achieved a 97% sign-in success rate. Since Apple, Google, and Microsoft jointly announced their expanded support for FIDO standards in May 2022, the narrative that "the era of passwords is ending" has steadily gained traction.
The technical pillar of this narrative is the passkey (a syncable authentication credential based on the FIDO2/WebAuthn standard). With public-key cryptography, the private key is never handed over to the server side. Even if a user is lured to a phishing site, there is no credential to steal. Mass credential leaks (database breaches) also become meaningless. It was a design that erased the entire category of vulnerabilities that passwords carried.
When Google made these passkeys support cloud sync, it promised more than mere convenience. The company officially stated: "A key feature of the (cloud) enclave authenticator is to make passkey secrets harder to steal, since they would otherwise be an obvious target for malware if locally available." In other words, Google's Cloud Authenticator had, as an explicit design goal, the protection of passkey private keys even if the endpoint itself were compromised.
That design goal was dismantled from three different angles by Unit 42's research, "Pass the Passkey: A Novel Attack Surface in Passwordless Authentication," published on August 3, 2026.
Why an Attack That "Doesn't Break the Cryptography" Can Still Succeed
First, let's clarify the premise. The attacks demonstrated by Unit 42 do not break the cryptographic foundations of passkeys (P-256 ECDSA signatures, the mathematics of public-key cryptography) at all. The claim repeatedly emphasized by the FIDO Alliance—that "there is no vulnerability in passkey cryptography itself"—remains unshaken even by this research.
What the attacks exploited was the "operational layer" where Chrome manages device trust, stores credential metadata, and handles re-enrollment to the cloud. If cryptography is the key to the safe itself, what Unit 42 demonstrated was not the key to the safe, but a gap in the movements of the clerk who manages the safe.
There is one precondition common to all the attacks: malware must already exist on the victim's Windows machine. However, administrator privileges or privilege escalation are not required. Malware operating with ordinary user privileges is sufficient.
Overview of a Compromise That Deepens Across Three Stages
Unit 42 classified the attacks into three levels, each structured to overcome the limitations of the previous one.
| Attack Name | Requirements | What Is Obtained | UV Flag | Persistence |
|---|---|---|---|---|
| Pass-TA-Key | Unprivileged malware | A single login assertion | 0 (unverified) | None (one-time only) |
| Silver Pass-TA-Key | Above + triggering re-enrollment | Registration of the attacker's own UV key | 1 (verified) | Semi-persistent (until re-enrollment) |
| Golden Pass-TA-Key | Above + memory dump | Private keys of all synced passkeys | 1 (verified) | Persistent (SDS rotation not possible) |
Stage 0: Reconnoitering the Unencrypted Index
As a preparatory stage for the attack, the malware reads Chrome's local sync database. On Windows, Chrome stores metadata for synced passkeys in %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB. This LevelDB database is unencrypted, and as WebauthnCredentialSpecifics records in proto format, it provides in plaintext which services the victim uses passkeys with, usernames, credential IDs, and indices to the encrypted private keys.
No privileges are required. Read access on the file system alone is sufficient.
Pass-TA-Key: A One-Bit Gap
The first attack begins by extracting the device identity key that Chrome stores in the TPM. Chrome calls NcryptCreatePersistedKey without a key name, so the key is not persisted within the TPM. Instead, it exports the key via NcryptExportKey as an NCRYPT_OPAQUE_KEY_BLOB and stores it as wrapped_identity_private_key in the passkey_enclave_state file. Malware can read this file from disk or extract it from Chrome's memory.
Using the extracted key, the malware calls Windows' standard CNG API (NCryptOpenStorageProvider, NCryptImportKey, NCryptSignHash) to sign an authentication request to Google's Cloud Authenticator. From the Cloud Authenticator's perspective, this looks like a legitimate request from a trusted device. A valid assertion is returned.
The issue here is the UV flag (User Verified flag) included in the WebAuthn authenticator data. This is a single-bit value that is set to 1 when the user has performed identity verification via biometrics or PIN, and to 0 when they have not. When signing with the identity key, this flag remains 0.
Services that set userVerification = required (such as financial institutions or GitHub) are supposed to reject authentication when this flag is 0. Indeed, GitHub correctly rejected it. However, in Unit 42's testing, eBay had set userVerification = required yet did not verify the flag, and accepted the attack. eBay has since fixed this following responsible disclosure.
Many relying parties set userVerification to preferred rather than required. This setting is intended to support a diverse range of devices and user experiences, but it leaves them effectively defenseless against the Pass-TA-Key attack.
Silver Pass-TA-Key: Weaponizing Re-Enrollment
The Silver attack completely bypasses UV flag verification. The malware deliberately corrupts or deletes Chrome's local passkey state (passkey_enclave_state). This forces Chrome into re-enrollment of the device.
Here lies a blind spot in the design. Google's Cloud Authenticator does not verify whether a newly registered user verification key (UV key) originates from secure hardware. During the re-enrollment process, an attacker can register their own key as the UV key.
From then on, the attacker can generate assertions with a legitimate UV flag (=1) from their own hardware. Authentication passes as fully "identity-verified," without ever touching the victim's device. This state persists until the victim re-enrolls their device.
Golden Pass-TA-Key: Stealing the Master Key
The most severe is the Golden attack. Its target is the Security Domain Secret (SDS), a 32-byte symmetric master key. The SDS is the sole key the Cloud Authenticator uses to encrypt and decrypt the private keys of all synced passkeys, making it the linchpin of this entire design.
Normally, the SDS exists on the device only as an encrypted wrapped_secret, and decryption occurs only within the Cloud Authenticator's isolated environment. However, Unit 42 discovered that during device enrollment (onboarding) or account recovery, the SDS is temporarily expanded in plaintext form within Chrome's process memory.
The attack procedure forces re-enrollment just as in the Silver attack, and at the moment the passkey_enclave_state file is recreated, dumps Chrome's process memory to extract the SDS. Once in possession of the SDS, the attacker can decrypt the encrypted private keys of all passkeys stored in the sync database, exfiltrate them, and authenticate from any device.
Initially, Unit 42 also discovered that the SDS was being logged in plaintext to Chrome's internal FIDO log (chrome://device-log/FIDO). Google removed this output from the log upon receiving the report, but the fundamental issue—that the SDS passes through client process memory—remains.
And there is one more decisive problem. Google's current implementation has no mechanism for SDS rotation (periodic replacement) or revocation. Once the SDS is stolen, not only the current passkeys but also all passkeys synced to that account in the future will continue to be protected by the same master key. While the Silver attack can be mitigated by re-enrolling the device, there is virtually no countermeasure available to victims against the Golden attack.
Is This a "Passkey Vulnerability"? The Boundary of the Threat Model
How to position this research is a matter on which the security community is divided.
The FIDO Alliance has long stated clearly that a compromised endpoint scenario falls outside the passkey threat model. The FIDO specification's security assumptions SA-3 and SA-4 presuppose that "the application on the user device can establish a secure channel" and that "the computing environment involved in FIDO operations behaves as a trusted agent," respectively. An environment where malware is present falls outside this premise.
In August 2025, when a similar claim (that malware could steal passkeys) was made in another study, Ars Technica sharply criticized it as "misreading the passkey threat model."
However, there is an aspect of Unit 42's research to which this counterargument does not straightforwardly apply. Google itself has explicitly stated that the design purpose of the Cloud Authenticator is to "protect passkey secret data from malware." For a local passkey implementation (e.g., a security key or device-bound key), the argument that "endpoint compromise is outside the threat model" would suffice. But for synced passkeys, Google added a defense specifically against that threat. The logic follows that if that defense was breached, it should be assessed as a "failure to meet the design goal."
Unit 42 itself states clearly in the paper's disclaimer that "all of these attacks depend on malware already being present on the victim's device at an early stage." The cryptography was not broken, nor was a flaw in the passkey standard exploited. Nevertheless, the fact that the layer Google promised would "protect against malware" was breached by unprivileged malware carries significant weight.
Questions That Remain
This research raises at least three unresolved issues.
First, the implementation of an SDS rotation mechanism. Unit 42 points out that Chrome recovers the SDS in an accessible form without using the mechanism the Cloud Authenticator has for "mediating the recovery flow without decrypting on the client device." Since the iOS/Android versions of Google Password Manager need to obtain the master key directly without using the Cloud Authenticator, it's conceivable that Chrome follows the same recovery model. But Unit 42 suggests that a more isolated approach is technically possible for the desktop version.
Second, verification of key provenance in the re-enrollment flow. The Silver attack succeeds because the Cloud Authenticator does not verify the hardware origin of a newly registered UV key. Incorporating TPM attestation (a mechanism by which hardware attests to key generation) into the re-enrollment flow might prevent this, but the implementation costs and compatibility issues remain unverified.
Third, thorough verification of the UV flag on the relying party side. As the eBay case shows, there are implementations that set userVerification = required yet fail to verify the flag. This represents a gap between the standard's implementation guidelines and actual deployments, and it is also a policy issue regarding how far the scope of audits and certification programs (FIDO Certification) should be extended.
The cryptography of passkeys has not been broken. Phishing resistance and defense against mass credential leaks are still functioning as designed. What Unit 42 demonstrated is that in the mechanism that "delivers" that cryptography—namely, the implementation of synchronization and cloud recovery—there exists a gap through which malware can slip. How far can the technology that killed the password withstand a different kind of killing? The answer lies not in the cryptography, but in the details of the implementation.