The security industry has been selling passkeys as the death of phishing. They're not wrong, exactly — but Unit 42's new research is a useful bucket of cold water. Three attack chains against Google Password Manager's cloud authenticator, collectively dubbed Pass-ta-key, show that once malware is running on your Windows machine, your passkey-protected accounts can be compromised without any fingerprint scan, PIN prompt, or visible action on screen.

The three variants — Bronze, Silver, and Gold in Unit 42's taxonomy — escalate in severity. The weakest intercepts an authentication session already in progress. The strongest targets the master key that Google Password Manager uses to wrap synced credentials, meaning an attacker who extracts it can authenticate to any passkey-protected site from a different machine entirely, long after the malware has been cleaned up.

The attack requires malware running as an ordinary user — no admin rights needed. That's the sting. Passkeys were designed to stop credential theft at the network layer: no password to phish, no token to intercept in transit. But they still rely on the local device to attest that you are you. If the device is already compromised, that attestation is worthless.

Why this matters beyond the headline. Google Password Manager is the default credential store for hundreds of millions of Chrome users worldwide — including a very large share of Australian users who've adopted passkeys via Chrome's built-in prompts. The attack doesn't break the passkey standard itself; it breaks the trust model that assumes the endpoint is clean. That's a subtle but important distinction.

The practical takeaway for defenders is uncomfortable: passkeys reduce one attack surface (phishing) while leaving another (endpoint compromise) largely unchanged. An attacker who can deploy an infostealer — which is now a commodity service available for around $200 a month on dark web forums — can ride straight through passkey authentication.

Enterprises relying on passkeys as a sole MFA replacement should pair them with endpoint detection controls. Device health attestation — where the authenticating device must prove it hasn't been tampered with — is the missing piece, and it's still inconsistently deployed.

Unit 42 reported the findings to Google ahead of publication. Google's response noted that the attacks require a compromised endpoint and that Chrome's existing malware protections remain the primary defence. That's technically accurate, and also a little circular: if Chrome's malware protections had worked, you wouldn't be reading this.

What to watch: Whether Google pushes changes to how the master key is stored or accessed, and whether other password managers — 1Password, Bitwarden, Apple Keychain — issue responses clarifying their own exposure. The underlying tension here isn't going away. As passkeys spread, attackers will keep probing the gap between "the standard is secure" and "the implementation trusts a device that's already owned."