Pass-ta-key Exposes the Gap Between FIDO2 Cryptography and…

Unit 42 reveals three post-compromise techniques that bypass PIN and biometrics on Chrome for Windows. Passkeys resist phishing, not malware already on the device.

Unit 42, the threat intelligence division of Palo Alto Networks, published research on August 3, 2026 detailing three attack techniques — Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key — that allow malware already resident on Windows systems to bypass biometric protections and PINs, hijacking Google Password Manager synced passkeys in Chrome. The discovery shifts focus from phishing resistance, the strength of the FIDO2 model, to the vulnerability of the implementation on compromised endpoints.

Key Takeaways

All three techniques require malware running on the device: they are post-compromise attacks, not remote exploits.
Pass-ta-key abuses the TPM-protected device identity key to sign authentication requests without user verification, producing assertions lacking the UV (User Verified) flag.
Silver Pass-ta-key exploits an attacker-controllable re-enrollment window where the cloud service does not attest the hardware origin of the new key.
Golden Pass-ta-key extracts the 32-byte Security Domain Secret (SDS) master key from Chrome memory, enabling persistent access to synced passkeys even from other systems.

How Pass-ta-key Bypasses Biometrics and PIN Without Breaking Cryptography

The core of the first technique lies in the implementation handling of the TPM key in Chrome on Windows. According to The Hacker News citing Unit 42, the malware extracts the wrapped device identity key and requests TPM signing via the Windows Cryptography Next Generation (CNG) APIs. Chrome then creates an unnamed TPM key — with a reference to a TODO in Chromium source code issue 398125799 — that suppresses the user verification prompt.

The result is an authentication assertion missing the UV (User Verified) flag, which some services fail to validate correctly. Unit 42 tested the technique against GitHub, which rejected it due to proper UV flag validation, and against eBay, which initially accepted it and later fixed the issue after disclosure. The difference in behavior highlights a critical fragmentation in relying party security posture.

"Although Google removed this secret from Chrome's logging output following our report, the SDS is still sent to the client and remains accessible in Chrome's process memory" — Unit 42 (Palo Alto Networks), via BleepingComputer

Silver Pass-ta-key: The Re-enrollment Window Without Hardware Attestation

The second technique, Silver Pass-ta-key, targets the moment of key reconstitution on a new device. According to Unit 42, Chrome does not immediately create a user-verification key during re-enrollment, generating an attacker-controllable window. In this phase, the cloud service does not verify the hardware attestation of the new key's origin, allowing malware to register a key it controls.

The mechanism does not attack the underlying FIDO2 asymmetric cryptography, but its implementation in the synchronization ecosystem. The lack of hardware origin verification turns a legitimate recovery operation into a compromise vector.

Golden Pass-ta-key: The 32-Byte Master Key Exposed in Memory

The third technique is the most invasive. Golden Pass-ta-key extracts the Security Domain Secret (SDS), a 32-byte master key, from the Chrome process memory during enrollment and recovery operations. The SDS is sent to the client during re-enrollment and resides in data structures accessible to processes with sufficient privileges on the already compromised system.

According to BleepingComputer citing Unit 42, SDS extraction allows decryption of synced private passkeys and maintains persistent access to future passkeys synced to the same account. Google removed the SDS from Chrome's FIDO logs after the report, but the key continues to be transmitted to the client and remains in Chrome memory. BleepingComputer further reports that Google's current implementation provides no mechanism for SDS rotation or revocation, meaning present and future passkeys remain protected by the same secret.

Why This Matters

The research repositions the passkey in its correct threat context. As documented by Google and cited by BleepingComputer, passkeys "cannot be shared, copied, transcribed, or accidentally handed to third parties," making them more secure against phishing. Unit 42 does not contest this: its techniques demonstrate instead that the passkey is phishing-resistant but not malware-resistant, a decisive operational distinction for enterprise security posture.

The dossier does not specify the full remediation status for all three attack paths, nor whether the Google service has implemented hardware attestation verification during re-enrollment. It is not documented whether changing the Google Password Manager PIN or clearing local data invalidates a previously extracted SDS. No specific Chrome version is indicated as affected or fixed.

No evidence of active in-the-wild exploitation exists at the time of publication. The Web Authentication specification, as reported by The Hacker News, prescribes that a relying party requiring userVerification set to required must fail the ceremony when the UV bit is absent: the discrepancy between GitHub and eBay in meeting this requirement signals that mitigation is not uniform across the ecosystem.

Questions and Answers

Are passkeys less secure than passwords?

No. Unit 42 research explicitly states the opposite. Passkeys retain their phishing resistance, which remains the predominant attack vector. The Pass-ta-key techniques require a pre-existing device compromise, a condition that does not apply to most users.

Can these techniques work on devices without TPM?

The dossier does not document behavior on systems lacking TPM. The described techniques refer explicitly to the Google Password Manager implementation in Chrome on Windows with TPM.

Is there a CVE for these vulnerabilities?

No. According to The Hacker News, as of August 3, 2026 no CVE has been assigned to the Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key techniques. CVE-2026-34348 documented in the dossier refers to separate research (Pass-the-Passkey/Grafnetter) on Windows 11 and Entra ID, not the Unit 42 techniques.

Unit 42 research shifts attention from the cryptographic promise of the passkey to its implementation reality. The industry must now verify that its services rigorously validate the UV flag and that synchronization ecosystems include hardware attestation and master key rotation. FIDO2 cryptography holds; it is the implementation chain that shows weak links.

Sources

Information verified against cited sources and current as of publication.

Sources

Sources and references