Passkeys Still Beat Phishing. New Research Points Somewhere Else

Primary Guard Newsroom · August 12, 2026 · 5 min read

Unit 42 research shows malware can hijack Google synced passkeys. Primary Guard explains what it means, and why it is not a reason to abandon passkeys.

Palo Alto Networks' Unit 42 published research in early August 2026 describing three techniques, collectively named Pass-ta-key, that allow malware on a Windows machine to hijack accounts protected by Google synced passkeys.

The coverage has been loud, and much of it has drawn the wrong conclusion. Primary Guard's reading is that passkeys remain the strongest mainstream authentication method available. What the research exposes is not the cryptography. It is the machinery around it.

What the researchers found

All three techniques target Google Password Manager in Chrome on Windows devices. They differ in how far the attacker gets.

The first steals Chrome's wrapped device identity key from disk and uses Windows cryptography APIs to sign an authentication request on the attacker's behalf. The result is a valid assertion produced without any biometric prompt appearing on the victim's screen.

The second installs an attacker-controlled user verification key, achieved by corrupting the local passkey state file to force Chrome into re-onboarding. During that window the verification key is accepted without its origin being properly validated.

The third is the serious one. It extracts a 32 byte value called the Security Domain Secret out of Chrome's memory, where it sits briefly in plaintext during onboarding or account recovery. That single secret decrypts every synced passkey on the account. Worse, there is currently no mechanism to rotate it, so an attacker who obtains it retains reusable access from their own environment even after losing the original device.

Researchers also noted that Chrome keeps synced passkey metadata in a local database that is neither encrypted nor privileged, handing malware a ready-made inventory of every service where the victim uses a passkey.

The condition that changes everything

Every one of these techniques requires malware to already be running on the victim's Windows machine, under a standard user account. None of them requires administrator rights, but none of them works against a clean endpoint either.

That single condition should reframe the entire story. This is not a break in WebAuthn or FIDO2. The underlying standards are untouched. The realistic delivery mechanism is an ordinary infostealer, which means the meaningful defensive question is not "are passkeys safe" but "how confident are you that your endpoints are clean".

What the research does not say

Primary Guard would flag three limits before anyone acts on the headlines.

No exploitation in the wild has been reported. This is laboratory research, not an observed campaign.

No CVE identifiers have been issued for the three techniques, and a search of the National Vulnerability Database in early August found nothing matching them. Remediation status is therefore unclear, and at the time of publication it had not been established whether all three paths have been closed.

It is also not known publicly whether changing a Google Password Manager PIN, or deleting Password Manager data, invalidates a secret an attacker already holds. That is precisely the question anyone who suspects compromise would need answered, and it remains open.

Why passkeys are still the right direction

It would be an overreaction to retreat to passwords, and Primary Guard would advise strongly against it.

Passkeys eliminate phishing as an attack class. There is no reusable secret to steal, nothing to type into a convincing fake login page, and nothing to replay against another site. That property is unchanged by this research. Set against a threat landscape where adversary-in-the-middle phishing kits are now sold as a service and device code phishing has risen sharply through 2026, that remains an enormous gain.

What the research punctures is the marketing idea that a passkey is an unbreakable object independent of the device holding it. It is not. A synced credential is only ever as trustworthy as the endpoint syncing it.

What to do

Add a hardware security key for privileged accounts. A device-bound credential on a physical key never syncs, never enters Chrome's state, and cannot be lifted from memory. For administrators, finance staff and executives, this is the control that closes the gap. Enrol it alongside the synced passkey rather than instead of it.

Treat this as an endpoint problem, because it is one. Every technique described depends on an infostealer landing first. Endpoint detection and response, application control and prompt patching remain the controls that matter here. Our explainer on EDR, SIEM and XDR covers how those layers fit together.

Consider hardened account programmes for high-risk users. Google's Advanced Protection Program requires security keys or device-bound passkeys and tightens account recovery, which is one of the surfaces this research targets. It is well suited to executives and administrators.

Do not stop the passkey rollout. If you are partway through replacing passwords, keep going. The alternative is worse and is actively exploited every day.

How Primary Guard can help

Primary Guard advises organisations across Malaysia, Indonesia and Thailand on identity architecture and endpoint security, and works with clients as a vendor-neutral managed security services provider. If you are rolling out passkeys and want to understand where device-bound credentials should sit in your design, or you want your endpoint controls assessed against infostealer activity, talk to our team.