Threat Research Center Threat Research Malware Malware Pass the Passkey: A Novel Attack Surface in Passwordless Authentication 17 min read Related Products Cortex Cortex Cloud By: Arie Olshtein Published: August 3, 2026 Categories: Malware Threat Research Tags: Google authenticator Google Chrome Google Cloud Identity Key Passkey Passwordless Share Executive Summary This article analyzes new attack classes against passwordless authentication, focusing on Google’s synced passkey ecosystem and the Cloud Authenticator used by desktop clients. The attacks demonstrate how malware on a compromised endpoint can misuse onboarding, recovery and device trust workflows to take over passkey-protected accounts. We show how an attacker can authenticate without user interaction, bypass user verification requirements and extract all synced passkey private keys. After decades of breaches and billions in losses, the attack vectors that defined the era of passwords and shared secrets are finally starting to fade. Passkeys replace passwords and traditional multi-factor authentication (MFA) with public-key cryptography, decreasing entire classes of attacks that have dominated the threat landscape for years. With no shared secret to steal, reuse or phish, many of an attacker’s most reliable tools are becoming obsolete. This represents a significant disruption for the credential theft market. Attackers, however, persist. They evolve, and defenders must prepare for a new generation of attacks. As passkeys become widely adopted and scale to billions of accounts, defenders must prepare for new attack surfaces, some of which we disclose in our research. This article is part 3 in our series examining passkey adoption from a security perspective. If you haven’t read the previous parts, we recommend starting here: Part 1: The Art of the Invisible Key – Passkey Global Breakthrough Part 2: Google Authenticator: The Hidden Mechanisms of Passwordless Authentication Palo Alto Networks customers are better protected from this new attack vector through the following products and services: Cortex Cloud Identity Security Idira Threat Detection and Response Idira Endpoint Privilege Manager Idira Privilege Access Management If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team . Related Unit 42 Topics Google Authenticator , Cloud , Malware Setting the Stage Google’s synced passkey implementation is particularly instructive due to its scale and how it creates a higher standard for private key protection in two critical ways: Private keys are generated and used within a cloud-enclave isolation environment Hardware-backed, client-device-bound keys control access to cloud-based cryptographic operations, attesting to the user’s presence on a trusted device This article builds on the architectural analysis from Part 1 and Part 2 of our previous articles in this series. We now shift from how passkeys are built and deployed to how attackers can misuse them. We present three novel attacks that enable account takeover of passkey-protected accounts. Each attack challenges a different core assumption of passkey authentication security. When a client authenticates with a passkey, the following is expected: Users provide explicit consent on the device to verify user presence For MFA, users must also unlock the device to verify biometric (i.e., something you are) or knowledge-based (i.e., something you know) authentication factors Passkey private keys cannot be shared or copied The Google documentation reflects these core assumptions, describing the passkey login process as a secure alternative to passwords (as shown in Figure 1). Figure 1. Google documentation describes passkeys as requiring device access, device unlock, and non-shareable credentials. Challenging these expectations is a category of attacks we've nicknamed Pass-ta-key. This playful, layered name blends the word passkey and the phrase “pass the key,” with a light nod to the concept of plate of pasta, illustrating how tangled this key implementation can get. These attacks each expose a different weakness in practice: Pass-ta-key attack: An attacker takes over an account protected by a Google-synced passkey using malware running on the victim’s device, without requiring privilege escalation, device unlock or user interaction Silver Pass-ta-key attack: An attacker deceives the Google Cloud Authenticator into believing the victim has unlocked the device with biometrics, leading to full account takeover without using the victim’s device during authentication Golden Pass-ta-key attack: An attacker can extract all synced passkeys in a form that allows them to be shared or sold on the credential black market These attacks demonstrate how malware can exploit synced passkeys, even when providers add hardware-backed protections to secure credentials within the cloud authenticator. Disclaimer: This research involved responsible and ethical security analysis. We responsibly disclosed all presented exploits. The cloud authenticator model is used by various passkey providers across multiple browsers and platforms. This work, however, focuses on Google Password Manager in Chrome on Windows, specifically on devices equipped with a Trusted Platform Module (TPM). All presented attacks rely on malware already existing on the victim’s device during the initial stage. Stage Zero: Reconnaissance Before attempting any of the attacks, the attacker needs visibility into how passkeys are used within the victim’s account. On a compromised endpoint, this visibility is readily available. Chrome locally stores synced passkey data as part of its synchronization process. On Windows, Chrome persists this data as proto-encoded WebauthnCredentialSpecifics records, which represent synced WebAuthn credentials, within its sync database: %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB Accessing these records does not require elevated privileges. The records allow an attacker to enumerate where the victim uses passkeys, along with associated usernames, credential identifiers and the encrypted private key. After identifying a service where the victim uses passkeys, an attacker can attempt to authenticate as the victim. The primary challenge for attackers is bypassing the protection of the private key, which is used to sign authentication challenges. This private key is secured by a master key. While an encrypted version of this master key is stored on each client device, only the cloud authenticator can decrypt it. Despite this security, the architecture remains vulnerable to exploitation. The following sections detail methods attackers could use to exploit system mechanisms, authenticate as the victim, and compromise passkey-secured accounts. Device Identity Impersonation: The Pass-Ta-Key Attack Our first attack is the most straightforward approach, which involves taking over a passkey-protected account by mimicking the behavior of Google Password Manager and Chrome during legitimate authentication. In a normal flow, Chrome sends a request to the cloud authenticator, signed using the device’s hardware-backed keys. Unlike a legitimate user flow that requires user interaction and device unlock, this attack shows how malware can obtain the required signature silently, without user consent, biometrics, device unlock or elevated privileges. To understand this, we focus on Chrome’s device identity key, which represents client device possession to the cloud authenticator. As previously explained ( part 2: Login with Synced Passkey and Device Key Signature ), generating the required assertion involves signing data sent to the cloud authenticator using one of the device’s hardware-backed keys. This is the identity key or the user verification key (UV key). Although both keys are hardware-bound, they are not accessed in the same way. For the identity key, Chrome creates the conditions that allow it to request a signature while running as a user without elevated privileges and without triggering device unlock protections. On Windows, Chrome calls the NcryptCreatePersistedKey function without assigning a key name, making the TPM-backed key ephemeral and preventing it from being persisted to disk. Instead of storing the private key within the TPM, Chrome calls NcryptExportKey to export the key as an NCRYPT_OPAQUE_KEY_BLOB , which instructs the TPM to encrypt the private key using a TPM-resident key. The resulting blob is stored as wrapped_identity_private_key in the passkey_enclave_state file, making it available for future use on the same physical TPM. Malware can extract this wrapped_identity_private_key from disk or Chrome’s memory. It can then invoke cryptographic operations using standard Windows Cryptography API: Next Generation (CNG) API s ( NCryptOpenStorageProvider , NCryptImportKey , NCryptSignHash ), without elevated privileges, mimicking Chrome’s own actions. Having established that malware can generate the required signature, we now detail the full Pass-ta-key attack flow (as shown in Figure 2). This flow allows a remote attacker with unprivileged malware on the victim’s device to authenticate as the victim. Figure 2. Pass-ta-key attack flow. The attack flow consists of the following phases: After collecting the victim’s synced passkey records (Stage Zero: Reconnaissance), the attacker selects a targeted account and initiates a passkey login The relying party responds with a fresh authentication challenge The attacker initiates a WebSocket handshake with the Google Cloud Authenticator Using the hash of that handshake, the attacker interacts with the victim’s TPM and uses the extracted identity key to sign the handshake hash together with the assertion request The attacker sends an assertion request to the cloud authenticator, including the identity key signature From the cloud authenticator’s perspective, the request appears to be a trusted device making a valid