Summary
- Researchers demonstrated three attack paths against Google Password Manager passkeys synchronised through Chrome on Windows.
- Each demonstrated technique requires malware to be present on the victim’s endpoint during the initial stage.
- The attacks exploit device, onboarding, recovery, and validation assumptions rather than breaking passkey cryptography.
Researchers have demonstrated three ways malware on a compromised Windows endpoint could misuse passkeys synchronised through Google Password Manager, without breaking the cryptography underlying WebAuthn.
Palo Alto Networks Unit 42 called the techniques Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key. The research focuses on Google Password Manager in Chrome on Windows devices equipped with a Trusted Platform Module.
All three attacks require malware to be present on the victim’s endpoint during the initial stage. The researchers did not claim to have broken the cryptography underlying passkeys or the Web Authentication standard.
The first technique allows an attacker to use information and device-backed signing capabilities available on the compromised computer to authenticate to a passkey-protected account. Unit 42 said it can operate without privilege escalation, device unlock, or direct user interaction where a service does not require strict user verification.
The Silver variant targets the mechanism used to signal that the user has verified their identity, such as through biometrics. According to the researchers, it can provide reusable access that no longer depends on the victim’s device being active during each later authentication attempt.
The Golden technique is designed to extract synchronised passkeys in a form that could be transferred or traded, turning credentials intended to resist phishing into reusable assets outside the original device environment.
Unit 42 said the work was responsibly disclosed and did not report evidence that the techniques had been used in real attacks. Its findings are therefore a laboratory demonstration of an attack surface, not confirmation of an active account-takeover campaign.
The research does not reverse the security case for passkeys. Properly implemented passkeys avoid several weaknesses associated with passwords, including reuse, disclosure through conventional phishing pages, and reliance on shared secrets that a service must store.
It does, however, show that phishing resistance is not equivalent to endpoint independence. Authentication still takes place through a device, operating system, browser, synchronisation service, cloud authenticator, and relying party. An attacker that already controls one of those components may be able to exploit the trust between them.
Synced passkeys introduce a deliberate usability trade-off. Credentials can be made available across a person’s devices and recovered through a cloud account, reducing the risk of lockout and making adoption practical at scale. The same architecture creates additional identities, recovery mechanisms, and synchronisation processes that must be secured.
The role of user-verification settings is particularly important. Some services treat user verification as preferred rather than required so that authentication works across a wider range of devices and accessibility needs. Unit 42’s research indicates that the configuration can influence whether a compromised device is sufficient to complete authentication.
Enterprise adoption therefore cannot be assessed solely by asking whether a service supports passkeys. Organisations also need to understand whether credentials are hardware-bound or synchronised, how device enrolment is controlled, which verification level a relying party requires, and what happens when an endpoint or cloud account is compromised.
The findings leave endpoint compromise inside the threat model even where passwords have been removed from authentication. Passkeys can remove passwords from an attacker’s workflow, but they do not make malware harmless. A compromised device may expose account metadata, active sessions, browser data, recovery paths, or the local mechanisms used to interact with protected credentials.
Unit 42’s work narrows the claim rather than invalidating the technology: the passkey itself was not mathematically defeated, but the surrounding implementation allowed a compromised endpoint to influence an authentication process designed to appear hardware-backed and user-verified.
