Passkeys Stopped the Phish. Malware Could Still Steal the Trust Behind Them.
Passkeys remove the shared secret that makes password phishing possible, but they do not make a compromised endpoint trustworthy. Palo Alto Networks Unit 42 has demonstrated three attacks against Google Password Manager’s synchronised passkeys in Chrome on TPM-equipped Windows systems.
The researchers did not break WebAuthn cryptography and did not show a remote attack against a clean device. Each technique requires malware already running with ordinary user privileges. The new capability is what that malware can gain: a route to reuse the device’s identity, register attacker-controlled verification material, or extract the secret that protects synchronised passkeys.
Three paths around the passwordless boundary
Unit 42 grouped the techniques under the name Pass-ta-key. They target implementation and device-trust decisions around the passkey rather than the public-key authentication protocol itself.
Pass-ta-key
The first technique uses the device identity key to produce a valid assertion without a visible user-presence check. Whether that assertion results in account access depends on the relying party correctly requiring user verification.
The researchers said eBay corrected its user-verification validation after disclosure, while GitHub rejected the attack because its implementation enforced the expected requirement. The contrast shows that a passkey’s security properties depend partly on how each service validates the result.
Silver
Silver forces a device through re-enrolment and registers verification material controlled by the attacker. That can create reusable access rather than a one-time session. It turns a compromised local account into a durable cloud-authentication foothold.
Golden
The most consequential technique extracts the 32-byte Security Domain Secret from Chrome process memory during re-registration. Unit 42 says this secret can be used to decrypt existing and future passkeys synchronised through the affected Google Password Manager security domain.
What the research does and does not prove
The work is not evidence that attackers can steal any passkey from any browser. The demonstrated environment is Google Password Manager in Chrome on TPM-equipped Windows, and the attacker first needs code execution as the signed-in user.
That prerequisite is still operationally realistic. Commodity information stealers, malicious installers and hands-on-keyboard intrusions routinely reach the user context. Passwordless authentication blocks credential replay from a fake login page, but it cannot treat the local client as honest after malware has taken control of it.
Unit 42 reported the findings to Google and affected relying parties. Google addressed logging exposure identified during the work, and eBay corrected its validation. The researchers also describe architectural limits that cannot be reduced to one patch.
Defensive priorities
- Keep passkeys. They remain a major improvement against phishing and server-side credential theft.
- Protect the endpoint. Application control, rapid containment and behavioural detection remain essential on devices that hold synchronised credentials.
- Enforce user verification. Relying parties should validate WebAuthn user-verification flags according to their stated authentication policy.
- Treat re-enrolment as sensitive. Alert on unexpected passkey security-domain resets, new device registrations and verification-key changes.
- Revoke after compromise. Endpoint remediation alone may be insufficient if an attacker registered persistent authentication material or obtained a synchronisation secret.
- Separate higher-risk accounts. Hardware-bound credentials and managed devices can reduce the blast radius for administrators and other privileged users.
The BlackTree view
The correct lesson is not that passkeys have failed. It is that passwordless authentication moves trust. The reusable secret disappears from the server and the login form, but the device, browser process, synchronisation service and relying party become more important.
Security teams should measure passkey deployments by the entire lifecycle: enrolment, synchronisation, local secret handling, user verification, device removal and post-compromise recovery. Stopping the phish is a major win. It is not the end of the authentication threat model.
Sources
- Palo Alto Networks Unit 42, Pass-ta-key: Passwordless Authentication Security Risks, published 3 August 2026. The primary page provides no publication time.
- Unit 42 article index, confirming the 3 August 2026 publication date.
