Unit 42 Maps New Passkey Attack Surface
Unit 42 has described three attack classes against passwordless authentication that target implementation and workflow gaps rather than the underlying public-key cryptography. The research focuses on Google Password Manager in Chrome on Windows devices equipped with a Trusted Platform Module, and it assumes malware is already present on the victim endpoint. The practical warning is narrow but serious: passkeys reduce password theft risk, yet endpoint compromise can still undermine account protection when validation, recovery and device trust controls are weak.The research targets synced passkeys, not passkey cryptography
Unit 42 published the research on Aug. 3, 2026, under the title Pass the Passkey: A Novel Attack Surface in Passwordless Authentication. The report says the attacks do not break WebAuthn or public-key cryptography. Instead, they exploit assumptions around trusted devices, user verification signals and recovery workflows in a synced passkey ecosystem.The scope matters. Unit 42 says the work focuses on Google Password Manager in Chrome on Windows, specifically devices with a TPM, and all presented attacks rely on malware already existing on the victim device during the initial stage. That means the findings should not be read as a claim that passkeys are inherently broken. They show that passwordless systems still inherit risk from compromised endpoints.
Reconnaissance starts from local passkey sync data
The report says malware running as a standard user can inspect locally stored Chrome sync records that describe where synced passkeys are used. Unit 42 identifies these records as WebauthnCredentialSpecifics entries stored in Chrome's sync database on Windows, including associated usernames, credential identifiers and encrypted private keys.This local visibility gives an attacker a target list before any authentication attempt. The attacker still needs a valid assertion for a relying party challenge, but the endpoint already provides enough metadata to choose accounts protected by passkeys. The implication for defenders is that passkey-related local state should be treated as sensitive, even when private key material is encrypted or cloud protected.
Pass-ta-key abuses device identity without user interaction
The first attack class, called Pass-ta-key by Unit 42, shows how malware on the victim device can mimic legitimate Chrome behavior toward the Google Cloud Authenticator. According to the report, malware can use the device identity key to request a signature without elevated privileges, device unlock, biometrics or user consent.In Unit 42's described flow, the attacker selects a passkey-protected account, obtains a fresh challenge from the relying party, communicates with the cloud authenticator and uses the victim device to sign required data. The cloud authenticator then returns a valid assertion, which the attacker forwards to the relying party. This attack is most effective when the relying party does not strictly require user verification.
The User Verified flag becomes a relying-party control point
Unit 42 says the difference between device possession and full user verification can come down to the WebAuthn User Verified, or UV, flag. If an assertion is signed using the user verification key, the UV flag is set. If it is signed using the identity key, the UV flag remains unset.The report says attacks typically fail when a relying party requires user verification and properly checks that flag. Unit 42 also says it found relying parties that accepted authentication without properly validating the UV flag, reducing the process to a single factor. The report names eBay as one tested case where a passkey login succeeded despite absent user verification, and says eBay fixed the issue after Unit 42 reported it.
Silver and Golden variants target recovery and key exposure
The Silver Pass-ta-key attack described by Unit 42 targets the onboarding path for user verification keys. The report says an attacker can invalidate an existing user verification key and then exploit a pending registration state to add an attacker-controlled key. Once accepted, that key can produce assertions with the UV bit set, allowing authentication even where user verification is enforced.The Golden Pass-ta-key attack is broader. Unit 42 says the passkey private keys are protected by a symmetric master key called the security domain secret, or SDS. The researchers found the SDS present in Chrome logs during registration, and say Google removed it from logging output after their report. Unit 42 further says the SDS is still sent to the client and can remain accessible in Chrome process memory during onboarding, which could allow an attacker to decrypt synced passkey private keys if they can force re-registration and extract the secret from memory.
Defensive pressure shifts to validation and endpoint controls
Unit 42's mitigation guidance starts with relying parties. They should set userVerification = required where MFA-level assurance is needed and validate the UV flag in every authentication response. Without that check, a cryptographically valid assertion may not prove that the user unlocked the device.The report also calls for credential managers to validate the origin and attestation of newly registered device keys, harden recovery and re-registration flows, and avoid exposing sensitive key material in client logs or memory. For enterprises, the operational lesson is direct: passkey adoption should be paired with malware prevention, memory-access controls and monitoring for abnormal onboarding or recovery prompts.
Conclusion
Unit 42's findings are a warning about implementation boundaries, not a reversal of the security case for passkeys. Passwordless authentication removes shared secrets from many login flows and reduces phishing and credential reuse risk, but it does not make a compromised endpoint trustworthy.The most immediate issue for relying parties is UV validation. For platform and browser providers, the harder work is reducing the attack value of local state, recovery flows and transient key material. As synced passkeys spread across more services, those operational details will determine whether passwordless authentication delivers its intended protection under real-world compromise conditions.
Sources
Editorial Team - CoinBotLab
