Pass-ta-key: What the attack on Google passkeys really means

Are passkeys no longer secure? That is the central question raised by Pass-ta-key.

Palo Alto Networks Unit 42 describes three attack chains that allow malware to abuse Google-synced passkeys, bypass user verification, and, in the most severe scenario, extract all private passkey keys belonging to an account.

None of the three techniques breaks WebAuthn, FIDO2, or the underlying public-key cryptography. All of them require malware to already be running on the victim’s Windows PC. That is a significant limitation.

Even so, dismissing the issue with “everything is lost once an endpoint is compromised” is too simplistic. The Golden Pass-ta-key variant can turn a local intrusion into a permanently usable, exportable package containing all synced passkeys. Its impact therefore extends beyond the theft of a single browser session.

The short assessment

Yes, this is a new and distinct security topic. It is not a reason to abandon passkeys or return to passwords as the only authentication method.

The correct assessment is:

• The protocol holds: Origin binding, challenge-response, and asymmetric cryptography are not broken.
• A specific implementation is attacked: Unit 42 tested the combination of Google Password Manager, Chrome, Windows, and a TPM.
• The endpoint must already be compromised: A random website cannot launch this attack remotely against a clean computer.
• The potential damage is still substantial: The variants range from silently creating a login assertion to extracting the private keys of all synced passkeys.
• Synced and device-bound passkeys have different risk profiles: Both are passkeys, but they do not provide the same assurance level.
• Passwords remain the weaker alternative: They can also be phished, reused, guessed, and stolen from server databases.

My risk assessment is therefore not “nothing happened,” but rather: narrow technical scope and demanding prerequisites, yet potentially very high impact when successfully executed.

Technical scope and evidence

The evidence available as of August 31, 2026 includes the attack flows documented by Unit 42, the WebAuthn specification, Google’s passkey documentation, the publicly visible Chromium issue, and current NIST requirements for syncable authenticators. The wider assessment also includes SpecterOps’ Pass-the-Passkey research, CVE-2026-34348, Proofpoint’s FIDO downgrade, and technical findings from Expel and SquareX.

The research was published on August 3 and updated by Unit 42 on August 14. It explicitly concerns Google Password Manager in Chrome on Windows devices with a Trusted Platform Module. Other browsers, operating systems, and passkey providers may face similar architectural questions, but these three attacks have not been demonstrated against them.

No active campaign exploiting these specific techniques in the wild has been documented. The current evidence consists of research, proofs of concept, and responsible disclosure. That distinction matters: a technically demonstrated attack is not automatically being exploited at scale.

What a passkey actually protects

A passkey is not an unusually long password. It is a WebAuthn credential based on asymmetric cryptography.

During registration, the authenticator creates a key pair:

private key -> remains with the authenticator
public key  -> is registered with the online service

The online service, called the relying party in WebAuthn, stores the public key together with a credential ID and the user account. During a later login, the service sends a new random challenge. The authenticator signs data that binds this challenge and the context of the requesting website. The server verifies the signature using the stored public key.

The private key is never sent to the server like a password. A breach of the service should therefore expose only public keys, which cannot be used to create valid signatures.

Binding the credential to the relying-party ID and web origin is equally important. A passkey for example.com cannot create an assertion valid for example.com on a deceptively similar phishing domain. Users have no shared secret they can type into the wrong website or disclose over the phone.

That is what phishing-resistant means. NIST defines the term narrowly: a fraudulent verifier must not obtain either the authentication secret or an authentication response that can be reused at the legitimate verifier. WebAuthn achieves this through cryptographic binding to the verifier’s name.

This property remains intact under Pass-ta-key. The malware does not build a better phishing page. It already runs on the device that the user treats as a trusted authenticator.

User Presence and User Verification are not the same

Understanding the attacks requires distinguishing two WebAuthn signals:

• User Presence, UP: A user performed an awareness action, such as touching a security key or confirming a dialog.
• User Verification, UV: The authenticator verified the user locally, for example through Windows Hello, a PIN, or biometrics.

The WebAuthn assertion reports these results as flags in authenticatorData. A server must not merely trust what it requested when starting the login. If it requests userVerification: "required", it must also verify that the returned assertion actually has the UV flag set.

This single check matters. Unit 42 could not complete the basic Pass-ta-key attack against GitHub because the required user verification was missing. The login initially succeeded against eBay even though user verification had been requested. eBay corrected its server-side validation after the disclosure.

The difference shows why a cryptographically valid signature is not always enough for correctly implemented multi-factor authentication. The relying party must also validate which security conditions the authenticator actually confirmed.

Why synced passkeys create an additional trust boundary

A device-bound passkey remains on one authenticator, such as a hardware security key or a locally protected platform authenticator. A synced passkey is intended to be available on several devices. Its private key material must therefore be backed up in encrypted form, transported through synchronization infrastructure, and restored on other authorized devices.

That is not a minor implementation detail. Synchronization expands the system:

Relying Party
    |
browser and WebAuthn client
    |
local platform authenticator
    |
passkey manager and recovery logic
    |
cloud sync and additional devices

Every added layer needs its own rules for device trust, onboarding, recovery, key encryption, and revocation.

NIST therefore treats syncable authenticators as a separate category. They can be suitable for scenarios up to Authentication Assurance Level 2. AAL3, however, requires non-exportable keys in a hardware-protected environment or a separate authenticator. This does not make synced passkeys weak. It means that portability and convenience produce a different assurance model.

Pass-ta-key targets precisely this additional trust boundary.

The exact scope of the research

Unit 42 identifies several prerequisites that many headlines omit:

• Google Password Manager manages the affected synced passkeys.
• Chrome runs on Windows.
• The device has a TPM.
• Malware is already running in the victim’s user context.
• The user is configured in the relevant Chrome and Google environment.
• Some variants require the malware to read local Chrome data, manipulate state files, or inspect Chrome process memory.

The research did not demonstrate a universal attack against every passkey. Nor did it show that a remote attacker without an existing endpoint compromise can simply extract a WebAuthn key from the TPM.

The precise conclusion is: Unit 42 demonstrated three attack chains against the trust, onboarding, and recovery mechanisms of synced Google passkeys on compromised Windows endpoints.

Phase zero: Mapping local passkeys

Before any of the three variants begins, the malware reads the local Chrome sync database. It contains WebauthnCredentialSpecifics records with relying-party information, usernames, credential IDs, and encrypted private-key material.

The relevant path is:

%LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB

Reading these records did not require elevated privileges in the test. The private material is not stored in plaintext, but the metadata gives malware a target list: which services have passkeys, which accounts they belong to, and which credential ID must be addressed.

This already matters for detection. An infostealer no longer needs to guess its targets. It can inventory them first and selectively attack high-value accounts afterward.

Pass-ta-key: A valid assertion without user interaction

The first variant abuses the device key through which Chrome proves the identity of the Windows device to the Google Cloud Authenticator.

Chrome creates a TPM-backed Identity Key. Its private key is not stored as an ordinary plaintext key. Chrome exports it through Windows CNG as an NCRYPT_OPAQUE_KEY_BLOB, protected by the TPM so it can be imported for cryptographic operations on the same physical TPM.

That is cryptographically sensible, but it does not automatically solve authorization. Malware running in the normal user context could read or recover the stored wrapped_identity_private_key and call standard Windows CNG functions. The TPM then performs a signature because the request technically comes from the correct device. It cannot tell whether Chrome or malware called the API.

The simplified flow is:

attacker requests a fresh challenge from the online service
    -> malware on the victim PC uses the TPM-bound identity key
    -> Google Cloud Authenticator accepts the device identity
    -> Cloud Authenticator creates a valid passkey assertion
    -> attacker submits the assertion to the online service

The private passkey file does not necessarily leave the device in this variant. Instead, the malware uses the compromised endpoint and Google’s Cloud Authenticator as a signing service.

The natural limit is the UV flag. The Identity Key proves possession of the device, but not a successful PIN or biometric check. A correctly implemented service that requires user verification and checks the result must reject an assertion with UV = 0.

That does not make the variant harmless. Many services configure user verification as preferred for compatibility or usability. Others request it but validate the response incorrectly. In those cases, a login designed as multi-factor effectively collapses to one factor: access to the device identity.

Silver Pass-ta-key: The attacker registers a new UV identity

Silver Pass-ta-key bypasses that limitation. The attacker does not break Windows Hello or the victim’s biometrics. Instead, the Cloud Authenticator is made to accept an attacker-controlled key as a valid future proof of user verification.

The starting point is re-onboarding. Malware can make the Cloud Authenticator forget the existing device state or delete the local passkey_enclave_state file. Chrome must then register the device again during the next passkey operation.

On Windows, the user-verification key is not necessarily created during the first step. Chrome can initially use the Google Password Manager recovery PIN and set the state to uv_key_pending. The actual UV key follows during the next passkey operation. This usability-oriented intermediate state creates the attack window.

The victim must complete the unexpectedly triggered recovery or re-onboarding step and enter the GPM PIN. The malware does not need to steal that PIN. It uses the resulting uv_key_pending state. Later malicious logins can then occur without further interaction and without the victim device being reachable.

The attacker generates a key pair in a separate environment and submits the public key as a new UV key. The Google Cloud Authenticator did not verify that this key originated in trusted hardware. It stored the attacker’s key alongside the legitimate device identity.

From that point onward, the attacker can sign requests with the corresponding private key. The Cloud Authenticator treats them as locally completed user verification and produces assertions with the UV flag set. The victim PC no longer needs to be online.

The publicly visible Chromium issue labels this behavior “GPM Passkeys Are Vulnerable to User Verification Key Abuse.” Regardless of its internal classification, the case demonstrates an important architectural rule: any recovery or onboarding process that binds a new trusted key is itself a high-risk authentication event.

Golden Pass-ta-key: Cloud sync becomes exportable key material

Golden Pass-ta-key is the most severe variant. It targets the Security Domain Secret, or SDS, a 32-byte secret that protects the synced private passkey keys of a Google Password Manager account.

The architectural promise is simple: the client holds only an encrypted wrapped_secret, while decryption occurs in the Cloud Authenticator using a device-specific key. Malware on the client should not be able to obtain the private passkey keys directly.

During onboarding and recovery, however, the synchronization infrastructure must add devices back into the Security Domain. Chrome receives the SDS in a form accessible to the client. It initially even appeared in Chrome’s FIDO diagnostic log. Google removed the log output after disclosure, but the SDS still reaches Chrome process memory during the operation.

Golden Pass-ta-key is therefore not an arbitrary memory dump that works at any moment. Malware first forces the security-sensitive onboarding or recovery path and must capture the moment when the SDS is present in Chrome memory. That makes the attack more complex, but it does not reduce the scope of the secret after successful extraction.

The chain combines several steps:

1. Malware forces new onboarding.
2. It waits for the local enclave state to be recreated or changed.
3. It reads Chrome process memory at the right moment and searches for the SDS.
4. It combines the SDS with the previously collected sync records.
5. It decrypts the private passkey keys in those records.
6. A separate authenticator can then generate valid assertions independently of the victim device.

This is the qualitative difference from a stolen session cookie. A session can expire or be revoked. Golden Pass-ta-key can export the private keys of all previously synced passkeys. The same SDS also protects passkeys created later, and the examined architecture exposed no user-facing way to rotate or revoke it.

That statement applies to the examined Google implementation. It does not prove that every passkey provider uses the same master-key design, nor that Google cannot change its architecture.

Why local malware does not make the attack irrelevant

An attacker who can already execute arbitrary malware in the context of a logged-in user has many simpler options. They can steal session cookies, read browser content, manipulate transactions, exfiltrate files, or act directly through the active account. No authentication system can place unlimited trust in a fully compromised client.

The underlying attack class is not new either. Stealing secrets or active sessions from a compromised password manager and browser has long been part of the infostealer playbook. Pass-ta-key does not magically turn an existing endpoint compromise into a remote attack.

Yet dismissing it as irrelevant misses concrete, implementation-specific findings:

• An unprivileged process could use a TPM-bound Chrome device key for signatures.
• The boundary between device possession and user verification depended on the relying party correctly evaluating the UV flag.
• Re-onboarding allowed registration of an attacker-controlled UV key.
• The central sync secret first appeared in a log and remained reachable in process memory.
• The most severe path made synced private keys reusable outside the original device.
• Synced passkeys often lack a reliable cloning signal from classic signature counters because multiple legitimate devices share one credential.

“Endpoint compromised” is a prerequisite, not a complete damage assessment. Incident response must distinguish between a temporary stolen session and long-lived private key material usable across many services.

Pass-ta-key is only one part of the new attack surface

Pass-ta-key did not appear in isolation. Research from 2025 and 2026 shows several ways attackers can reduce the protection provided by passkeys without mathematically breaking their private keys.

Abusing sync and recovery requires malware already running on the Windows endpoint. Pass-the-Passkey combines access to a logged assertion with a server-side replay flaw. A FIDO downgrade depends on an additional phishing-capable sign-in method, while Passkeys Pwned requires a malicious browser extension or script execution in the browser context. Infostealers do not attack the passkey itself, but steal the authenticated session from a compromised browser or endpoint.

None of these paths breaks public-key cryptography. They target a trust layer around WebAuthn: sync and recovery, server-side validation, the browser, or the post-login session.

This distinction is more than semantics. A protocol break would fundamentally challenge every conforming implementation. These cases instead demand different controls across endpoints, browsers, identity systems, and servers.

Pass-the-Passkey: Reusing a valid assertion

At Black Hat USA 2026, SpecterOps identified three vulnerabilities in Windows 11 and Microsoft Entra ID and more than 20 attack techniques derived from them. The most important chain started in an unexpected place: Windows logged complete WebAuthn assertions to Microsoft-Windows-WebAuthN/Operational.

Such an assertion contains the credential ID, challenge, authenticator data, and signature. It is not a private key and, with correct verifier behavior, should work only once and only within its associated sign-in session. Entra ID nevertheless accepted captured assertions again for a limited period. Two failures therefore met:

Windows logs a complete assertion
    -> an attacker reads it
    -> the verifier does not bind the challenge and assertion tightly enough to the session
    -> the same signed response is accepted again

The Windows component became CVE-2026-34348. Microsoft released an update on July 14, 2026 that truncates the logged signature to a few bytes, removing the replay source. A server-side signature-counter check was also introduced for certain FIDO2 security keys. Signature counters are not universal protection, however, because some platform and synced credentials always report zero or share state across devices.

The lesson extends beyond the interrupted exploit chain. WebAuthn assertions do not belong in diagnostic or event logs. Challenges must be random, short-lived, single-use, and bound to the exact login session. A valid signature alone does not prove that the entire authentication flow was correct.

Another technique concerns the parent window handle of the Windows WebAuthn API. A local process can position a genuine passkey dialog so that it appears to belong to a trusted application such as a browser or mail client. The system UI is genuine, but its triggering context can be misleading. Users should treat unexpected passkey and Windows Hello prompts like unexpected MFA push notifications.

The weakest fallback defines the real security level

Proofpoint demonstrated a FIDO downgrade against Microsoft Entra ID in 2025. A modified Evilginx flow pretended to be a browser without FIDO support, causing the platform to offer alternative sign-in methods. If the victim selected SMS, OTP, or another phishable method, credentials and the resulting session could be captured through the adversary-in-the-middle flow.

The attack does not bypass origin binding. It prevents the WebAuthn ceremony from starting. It works only when the account permits a weaker method alongside the passkey. No in-the-wild exploitation of this downgrade has been documented.

The organizational rule is clear: a policy is not phishing-resistant merely because a passkey is registered. It becomes phishing-resistant only when the relevant sign-in path no longer accepts phishable alternatives. Recovery and helpdesk resets must be included in the same assessment.

The browser belongs to the security model

SquareX demonstrated how a malicious browser extension or script in the browser context can interfere with navigator.credentials.create() and navigator.credentials.get(). Registration is especially important: attacker-controlled key material can be inserted while the user sees a real biometric prompt, resulting in a credential controlled by the attacker being bound in the background.

This vendor research is not a universal browser exploit. Its prerequisite is substantial: an extension or script context must already be able to position itself in the WebAuthn path. The architectural lesson nevertheless holds. Browser extensions, content scripts, and legitimate WebAuthn proxy functions are part of the trusted computing base. In managed environments, extension allowlists and control of privileged browser APIs are identity security, not merely browser hygiene.

Passkeys protect the login, not automatically the subsequent session

After a successful login, the service normally continues with a session cookie or token. If an infostealer can extract that artifact and the server accepts it from another device, the attacker needs neither the password nor the passkey. The already authenticated session is attacked instead.

This is a more practical threat today than many research proofs of concept. Passkeys substantially reduce the attack surface before and during login, but they do not replace secure token storage, appropriately short sessions, reauthentication for critical actions, token revocation, and device binding for high-value sessions.

Calling this an “MFA bypass” can be misleading. MFA completed successfully. Its result was stolen afterward.

PoisonSeed shows how quickly research can become hype

In July 2025, Expel initially reported a supposed attack against cross-device passkey authentication. An attacker was believed to relay a legitimate QR code through a phishing page and take over the remote login. Expel publicly retracted the central claim and apologized a few days later.

The follow-up analysis showed that the local proximity check required for cross-device authentication had not been bypassed. Without the necessary proximity, the process timed out, every MFA challenge failed, and the attacker gained no access.

The case is valuable because not every plausible combination of QR code, phishing, and passkey is a working FIDO bypass. Good security communication must distinguish observed account takeover, reproducible proof of concept, theoretical attack, and disproven hypothesis.

My security assessment

Pass-ta-key has limited technical reach. The demonstrated chain concerns Google Password Manager in Chrome on TPM-equipped Windows systems. Its likelihood is medium to low because malware must already be running locally and, depending on the variant, manipulate state or process memory.

Its potential impact is high to very high. Successful exploitation can result in account takeover, persistent remote access, or the extraction of several private keys. Protocol risk remains low because WebAuthn, origin binding, and public-key cryptography are not broken.

For an ordinary user, a synced passkey remains safer than a password combined with SMS or TOTP in most circumstances. It eliminates phishing, credential stuffing, and stolen reusable passwords from many realistic attack paths.

Privileged administrators, financial approvals, production access, and regulated systems require a more deliberate decision. A device-bound platform credential or separate FIDO2 hardware key may be the more appropriate boundary for these accounts.

This is not a rejection of synced passkeys. It is a tiered security architecture.

What service operators must verify

The most important lesson for relying parties is straightforward: implement WebAuthn validation correctly.

Servers should:

• set userVerification: "required" when the use case needs genuine local user verification,
• require the returned UV flag in authenticatorData,
• fully validate the challenge, origin, relying-party ID, and signature,
• generate every challenge randomly, expire it quickly, accept it once, and bind it to the exact session,
• keep complete assertions, signatures, and reusable authentication artifacts out of logs,
• log passkey registration, removal, and account recovery as high-risk events,
• require strong reauthentication before adding authenticators to privileged accounts,
• record authenticator origin and properties where possible,
• consider attestation and managed authenticators for high-security cases,
• feed unusual device changes, geographic shifts, and new passkey bindings into identity telemetry,
• revoke sessions after risky changes and reauthenticate critical actions,
• use device-bound sessions when platform and application support is mature enough.

An established WebAuthn library reduces the risk of incomplete custom validation, but operators must still verify its configuration. The eBay case shows how one unchecked flag can reduce the intended assurance level. Pass-the-Passkey also shows that a correct signature is worthless when challenge and session do not belong together.

What organizations should change in passkey rollouts

Passkey projects are often planned as IAM initiatives. Pass-ta-key shows that they are endpoint, browser, and recovery initiatives as well.

Synced passkeys remain a reasonable choice for standard workforce accounts because they reduce helpdesk work and provide strong phishing protection. Policy should nevertheless follow the value of the account.

Standard user accounts can use synced passkeys on managed devices together with endpoint protection and Conditional Access. Sensitive business accounts should use managed platform authenticators or restricted synchronization environments with stronger device binding. Administrator, break-glass, and other high-value accounts should use separate device-bound FIDO2 hardware keys, tightly controlled recovery, and no uncontrolled cloud synchronization.

Organizations should also:

• keep Chrome and Windows current,
• verify Windows patch status for CVE-2026-34348,
• explicitly permit or restrict passkey storage in built-in browser managers through enterprise policy,
• enforce browser-extension allowlists and monitor privileged WebAuthn proxy functions,
• apply EDR and application control to user processes,
• monitor access to browser sync databases and Chrome process-memory dumps,
• investigate deletion or unexpected recreation of passkey_enclave_state,
• treat repeated or unexpected Google Password Manager recovery-PIN prompts as warning signals,
• test device-loss and account-recovery processes for abuse,
• remove phishable fallbacks from privileged accounts or exclude them through an authentication-strength policy,
• investigate unexpected passkey prompts, new credential registrations, and WebAuthn activity from unusual processes,
• inventory which important services use synced and which use device-bound credentials.

Endpoint detection is not a budget item separate from the passkey project. When the authenticator lives in the browser and client, endpoint security is part of the authentication model.

What users should do now

There is no sound reason to delete every passkey and return to weaker passwords.

Users should:

• update Chrome and Windows promptly,
• install only trusted software and browser extensions,
• keep device protection, Windows Hello, and malware protection enabled,
• reject unexpected passkey or Windows Hello dialogs,
• avoid casually approving unexpected recovery-PIN or re-onboarding requests,
• review registered devices and passkeys in Google Password Manager and important services,
• consider a separate hardware security key for especially valuable accounts,
• isolate and investigate a suspicious endpoint instead of continuing to use it.

Evidence of malware, manipulated Chrome state, or process-memory dumping should be treated as possible credential and session theft. A password change is not enough. Recovery requires endpoint rebuilding or verified remediation, revocation of active sessions, review of recovery methods, removal of unknown passkeys, and registration of trusted authenticators again.

A possible Golden Pass-ta-key incident requires particular care. The current research does not describe a simple user-controlled SDS rotation. Do not claim that changing a PIN or recreating one passkey definitely solves the problem. After cleaning the endpoint, I would register new device-bound credentials for valuable accounts, remove old synced credentials, and involve the provider or incident-response team in recovery.

The real lesson

Passkeys are not a shield against every form of compromise. They solve one specific and enormous problem: people no longer hand a reusable secret to a server or a potentially fraudulent website.

Pass-ta-key exposes the next layer. Once private keys are synchronized conveniently across devices, an infrastructure for key encryption, device trust, and recovery emerges. That infrastructure can contain flaws even when the underlying WebAuthn protocol is correct.

Declaring passkeys a failure would be the wrong response. Dismissing every attack after a local malware infection as trivial would be equally wrong.

My assessment remains clear: continue deploying passkeys, but describe their security guarantees precisely. Synced passkeys are excellent against phishing. Device-bound hardware keys provide a stronger boundary for high-value accounts. No authenticator replaces a clean endpoint, controlled recovery, and correct server-side validation.

Passkeys have locked the door against phishing far more effectively. Pass-ta-key reminds us that an attacker already inside the house requires a different defense.

Until next time,
Joe

FAQ