A researcher at Palo Alto Networks’ Unit 42 has published a detailed account of three attacks that allow malware to take over accounts protected by passkeys stored in Google Password Manager. The work is known as Pass-ta-key, a name that folds passkey into the phrase pass the key, with a plate of pasta thrown in for good measure. Arie Olshtein, the researcher who published the report, framed the findings as a novel attack surface for passwordless authentication. The reactions from other security professionals have been more measured: the technique requires malware to already be running on the victim’s machine, which means the security model of passkeys was never designed to survive it.
The attacks target Google Password Manager’s synchronized passkeys inside Chrome on Windows, where the operating system runs with a Trusted Platform Module (TPM). In the simplest variant, malware extracts a hardware-backed identity key from a file Chrome keeps on disk and uses it to sign authentication requests silently. No fingerprint, PIN, or on-screen prompt is involved. The most powerful variant, Golden Pass-ta-key, recovers Google’s security domain secret, the master key that protects every synchronized passkey, and decrypts the whole collection into a shareable form that works on any device.
The reason these attacks are possible is specific to Windows. Under the FIDO 2 and WebAuthn specifications, passkeys do not have to live in dedicated security hardware such as a TPM or a secure enclave. On macOS, iOS, and Android, passkeys are stored locally on the device, where app sandboxing keeps malware away from the private keys. Windows is the exception: applications generally run with the privileges of the logged-in user, and its sandboxing protects apps in only one direction. That is why Google Password Manager and third-party apps including 1Password and Dashlane keep Windows passkeys in cloud-hosted vaults protected by end-to-end encryption instead of on the machine itself, a design that keeps the keys out of reach of local malware but creates a new server-side trust relationship to attack. Microsoft remains the near-lone holdout offering TPM-based passkey storage, mainly for enterprise customers.
Olshtein’s write-up documents the mechanics in detail. Chrome keeps an index of a user’s synchronized passkey credentials in a local database file that requires no elevated privileges to read, revealing which sites the user registered passkeys on and where the encrypted private keys are stored. For the basic Pass-ta-key attack, the malware copies a wrapped identity key from Chrome’s passkey state file, then uses standard Windows cryptographic APIs to sign requests in the same way Chrome itself would. The signed request is sent to Google’s cloud authenticator, which treats it as coming from a trusted device and returns a valid login assertion.
Whether that assertion is accepted by the site being logged into depends on a single bit in the authentication data, the user-verified flag. When a request is signed with the verification key, the flag is set; when signed with the identity key alone, it is not. Services that set user verification to required and actually validate the flag, as GitHub does, rejected the attack in Unit 42’s testing. eBay accepted it despite setting the requirement, because it did not validate the flag at the time; the company fixed the gap after the disclosure. A second attack, Silver Pass-ta-key, abuses the device re-enrollment flow to register an attacker-controlled verification key, allowing logins from a machine the victim never touched.
The broader argument from critics of the novel attack surface framing is that the stakes are the same as any other credential on a compromised machine. Once a device is infected and logged into sensitive accounts, an attacker can typically reach passwords, session cookies, and everything else the account can access. Passkeys are designed to stop phishing and credential theft from servers, not to withstand a fully compromised device. Even so, the research has practical value: it shows that some services treat the user-verified flag as proof of a real biometric or PIN event, and it gives Google and other vendors a concrete checklist for hardening device registration, recovery, and server-side verification.
For users, the takeaway is unchanged. Passkeys still neutralize the most common attacks against passwords, phishing sites and credential stuffing with reused passwords. Keeping Windows patched and running up-to-date anti-malware protection remains the effective defense, because every attack begins with malware already running on the machine.
Sources: Pass the Passkey: A Novel Attack Surface in Passwordless Authentication (Unit 42, Aug 2026); New Pass-ta-key attack reveals all the things we didn’t know about passkeys (Ars Technica, Aug 2026); Google’s synchronized passkeys can be stolen in ‘Pass-ta-key’ attacks (Malwarebytes, Aug 2026); Pass-ta-key Research Exposes Gaps in Google’s Passkey Security on Windows (BetaNews, Aug 2026)