Passkeys were designed to kill off the password, replacing shared secrets with public-key cryptography that resists phishing and credential-stuffing. New research from Unit 42 shows that when it comes to Google’s synced passkey implementation on Windows, malware already sitting on a compromised machine can undermine those protections entirely, hijacking passkey-secured accounts without ever prompting the victim for a password, PIN, or fingerprint.

A Local Database and an Exportable Key

The research, the third installment in a series examining passkey security, digs into how Google’s Cloud Authenticator handles device trust, onboarding, and account recovery. The first weak point researchers identified is mundane but consequential: Chrome stores synced passkey metadata locally in an unencrypted, easily readable database. Malware with no elevated privileges can simply read this file to build a complete map of every service where a victim has passkey login enabled.

The more serious issue lies in how Chrome manages what’s called an “identity key,” a hardware-backed credential meant to prove to Google’s Cloud Authenticator that a request is coming from a device the user actually owns. Rather than being permanently sealed inside the Trusted Platform Module (TPM), where it would be inaccessible to software running on the machine, this key is generated as a temporary, exportable blob. Malware can extract it and use standard Windows cryptography APIs to sign authentication requests exactly the way Chrome itself would.

Chained together, these two weaknesses let an attacker complete a full passkey login silently, without triggering a device unlock or biometric prompt. Unit 42 has named this the “Pass-ta-key” attack.

Escalating to Silver and Golden Variants

A more advanced variant, dubbed “Silver Pass-ta-key,” goes further by defeating user verification altogether. By deleting or corrupting the local passkey state file, an attacker can force Chrome into a re-onboarding process. During that window, Google’s Cloud Authenticator accepts a newly registered, attacker-controlled verification key without validating where it actually came from, effectively handing the attacker a permanent, reusable way to authenticate as the victim, even on accounts protected by strict multi-factor authentication requirements.

The most severe technique, “Golden Pass-ta-key,” targets the master encryption key that protects all of a user’s synced passkeys at once, known as the security domain secret (SDS). Researchers found this 32-byte secret was briefly exposed in Chrome’s internal logs and remains accessible in memory during device recovery. An attacker who extracts it can decrypt every passkey tied to the account, past and future, creating persistent access that survives even after the initial compromise is detected and cleaned up. Google currently has no mechanism to rotate this master key, meaning recovery from a Golden Pass-ta-key compromise is far from straightforward.

An Implementation Gap, Not a Cryptography Break

The researchers are careful to note that none of this breaks passkey cryptography itself. Instead, it exploits gaps between the security assumptions passkey design relies on and how those assumptions hold up in real-world implementation, particularly around how much trust is placed in the client device and how consistently relying parties validate that trust. Some affected sites, including eBay, have already patched verification gaps on their end following responsible disclosure.

Recommended Mitigations

For organizations and platforms relying on Google-synced passkeys, Unit 42 recommends:

• Strictly enforcing user-verification checks rather than trusting device-level assertions alone
• Validating device key attestation before registering a new passkey
• Restricting local access to browser credential stores through endpoint controls
• Monitoring for unexpected re-triggering of onboarding or account recovery flows, which can signal an in-progress Silver Pass-ta-key attempt

Until Google addresses the underlying key-handling gaps, the practical takeaway is that a passkey is only as strong as the device it lives on. A machine already compromised by commodity malware can turn a technology built to eliminate account takeover into a fresh vector for exactly that outcome.