Affiliate disclosure - this article contains an affiliate link to a password manager. If you subscribe through it we earn a commission at no extra cost to you. It changes nothing about what follows: the findings below come from Palo Alto Networks Unit 42 and the technical press, and are attributed source by source.
Short answer: yes, passkeys are still safe to use, and the researchers who published the attack say so in as many words. On 3 August 2026, Palo Alto Networks Unit 42 showed that malware already running on a Windows PC can hijack passkeys synced through Google Password Manager. Their own sentence is the one to remember: "These attacks do not break the underlying cryptography." What they broke is the plumbing around the passkey, not the passkey.
That distinction is the whole story, and most headlines dropped it.
What was actually published
Arie Olshtein, a researcher at Unit 42, published "Pass the Passkey: A Novel Attack Surface in Passwordless Authentication" on 3 August 2026. It is a technical research blog post, not a peer-reviewed paper, and it comes from a commercial security vendor, worth stating plainly, because it is detailed and credible but it is not a neutral third party.
It describes three techniques, collectively called the Pass-ta-key attacks.
Pass-ta-key, the malware pulls the wrapped device identity private key from disk or memory, then calls Windows CNG APIs (NCryptOpenStorageProvider, NCryptImportKey, NCryptSignHash) to have the TPM sign on its behalf. It signs the WebSocket handshake hash and passes itself off as a legitimate Chrome install to Google's cloud authenticator. No device unlock, no user interaction, no privilege escalation. Note the subtlety: the key never leaves the TPM, the TPM is simply made to work for the attacker.
Silver Pass-ta-key, the malware deletes passkey_enclave_state to force a device re-enrolment, exploits the transient uv_key_pending state, and registers its own user-verification key. The flaw is precise: the cloud authenticator does not validate the attestation of newly registered UV keys, so it cannot tell whether they came from secure hardware. Result: reusable access from another machine, without the victim's device.
Golden Pass-ta-key, the worst of the three. The Security Domain Secret, a 32-byte master key protecting every synced passkey, is extracted from Chrome's process memory during re-enrolment. With it, an attacker decrypts the stored credential records and walks away with every synced passkey on the account.
The two facts that make this serious
Google removed the Security Domain Secret from Chrome's diagnostic logs after the disclosure. But Unit 42 states the secret is still sent to the client and remains accessible in Chrome's process memory, acknowledged, not fixed.
And there is no way to rotate or revoke that master key in the current implementation. Present and future passkeys stay protected by the same secret. That is the hardest part of this affair, and the part that has no user-side workaround.
The one condition that changes everything
Every one of these techniques assumes malware already running on the machine. The researchers say so: "malware already existing on the victim's device during the initial stage."
Frank Dickson of IDC gave the clearest formulation, in Computerworld: "This isn't passkeys getting hacked from across the internet. It's what [an attacker] does once they're already inside the house."
So the perimeter is narrow and specific:
| Condition | Required |
|---|---|
| Operating system | Windows |
| Browser | Chrome |
| Credential store | Google Password Manager (synced passkeys) |
| Hardware | Machine with a TPM |
| Precondition | Malware already running locally |
| Privileges needed | User-level: no elevation |
| User interaction | None |
No phishing is needed, no malicious extension, no stolen session, no downgrade to another factor. And no remote exploitation: if your machine is clean, none of this reaches you.
Apple's iCloud Keychain, Windows Hello, 1Password and Bitwarden were not tested. Unit 42 observes that other providers use a similar cloud-authenticator design, which is a warning about architecture: not a finding that they are vulnerable. Anyone telling you "all passkeys are affected" is going beyond the research.
What is worth changing
If you are an individual. The single real lock here is the one prerequisite: keep malware off the machine. Unit 42's own recommendation is to invest in endpoint protection and to treat passkeys as one layer in a broader strategy rather than a finish line. For your highest-value accounts, email, banking, domain registrar, a hardware security key is the device-bound option that this research does not touch, since nothing is synced to a cloud enclave. That is a trade-off, not a verdict: you gain resistance to this class of attack and you lose the convenience of syncing across devices.
If you run a service. The concrete fix is server-side and it is named: require userVerification and actually validate the UV flag in the authentication response. This is not hypothetical, eBay was accepting authentication without user verification while userVerification was set to required, and corrected it after Unit 42's report. GitHub correctly rejected the same attack. A sound implementation holds; an uneven one does not. As analyst Justin Greis summarised in Computerworld: "The specification is sound, but the ecosystem implementing it is uneven."
Beyond that, the measures documented by the researchers and the analysts quoted in Computerworld: validate device key attestation at enrolment, monitor abnormal passkey usage, deploy EDR and identity threat detection, set an explicit policy on synced versus device-bound credentials, and rehearse the recovery flows, because recovery and re-enrolment are precisely what these attacks abuse.
What not to conclude
Several claims circulating this week are not supported by the research, and repeating them would be wrong:
- "Passkeys are dead / broken." Contradicted in writing by Unit 42 and SecurityWeek.
- "The cryptography was cracked." It was not, explicitly.
- "Go back to passwords." No source recommends it, and it would reintroduce phishing and credential reuse, the very attacks passkeys eliminate.
- "It's a CVE being actively exploited." No CVE was assigned as of 3 August, and no exploitation in the wild has been reported.
- "Apple and Microsoft are affected too." Untested. Not the same thing.
The honest summary belongs to Unit 42 themselves: passkeys are "a meaningful step forward in authentication security" because they remove shared secrets and with them entire classes of attack. This research does not reverse that. It shows that the ecosystem built around passkeys, enrolment, recovery, cloud sync, deserves the same scrutiny the cryptography already received.
The deeper lesson, raised by J. Wolfgang Goerlich in Computerworld, is the one worth keeping: synced passkeys reintroduced a credential-portability risk that device-bound authenticators never had. Convenience across devices has a price, and this is the first time we can see it clearly.
Sources
- Arie Olshtein, "Pass the Passkey: A Novel Attack Surface in Passwordless Authentication", Palo Alto Networks Unit 42, 3 August 2026, primary source, commercial security vendor.
- BleepingComputer, 3 August 2026, first coverage, notes no CVE assigned.
- The Hacker News, 3 August 2026, "the attacks go after the code around the passkey".
- SecurityWeek, 5 August 2026, "That does not mean passkeys are broken".
- Computerworld, Evan Schuman, 5 August 2026, analyst commentary (Dickson, Greis, Goerlich, Levine, Finkelstein).
- Biometric Update, 7 August 2026, FIDO Alliance's standing position, no exploitation in the wild.
Figures and statements verified on 9 August 2026. Google had made no public statement on the substance at that date; this is the point most likely to have changed since.
★ Audit Cure53 2024 · ✓ Plan gratuit · Cross-platform
A manager with built-in 2FA & passkeys → NordPassStore TOTP & passkeys · XChaCha20 · free tier→Frequently asked questions
Are passkeys still safe after the Pass-ta-key research?
Yes, and the researchers say so themselves. Palo Alto Networks Unit 42 states plainly that these attacks do not break the underlying cryptography. SecurityWeek adds that this does not mean passkeys are broken or that people should stop using them. What the research demonstrates is that malware already running on a Windows PC can abuse the machinery around the passkey - Google's cloud synchronisation - rather than the passkey itself. Passkeys remain a real improvement over passwords because they remove the shared secret that phishing and credential stuffing depend on.
What exactly do the Pass-ta-key attacks exploit?
Three separate techniques, all published by Unit 42 on 3 August 2026. Pass-ta-key extracts the wrapped device identity key and uses Windows CNG APIs to make the TPM sign on the attacker's behalf, impersonating a legitimate Chrome install to Google's cloud authenticator. Silver Pass-ta-key forces a device re-enrolment and registers the attacker's own user-verification key, because the cloud authenticator does not validate the attestation of newly registered UV keys. Golden Pass-ta-key extracts the Security Domain Secret, a 32-byte master key, from Chrome's process memory - with it, every synced passkey on the account can be decrypted.
Am I affected?
Only under a specific set of conditions, and they must all be true at once: Windows, Chrome, passkeys synced through Google Password Manager, a machine with a TPM, and above all malware already running on that machine. There is no remote exploitation: the researchers state the attack requires malware already existing on the victim's device. IDC analyst Frank Dickson put it clearly in Computerworld - this is not passkeys being hacked from across the internet, it is what an attacker does once they are already inside the house.
Are Apple, Microsoft or third-party password managers affected?
Not established, and it would be wrong to claim otherwise. Unit 42 tested Google Password Manager on Chrome under Windows. iCloud Keychain, Windows Hello, 1Password, Bitwarden and others were not tested. Unit 42 does note that other providers use a similar cloud-authenticator model, which is a caution about design, not a finding of vulnerability. Treat them as untested, not as safe and not as vulnerable.
Has Google fixed it?
Partly, and it is important to be precise. Google removed the Security Domain Secret from Chrome's diagnostic logs after the disclosure. But Unit 42 notes the secret is still sent to the client and remains accessible in Chrome's process memory, and that issue is acknowledged rather than resolved. Worse, the current implementation offers no way to rotate or revoke that master key, so present and future passkeys stay protected by the same one. As of publication Google had made no public statement on the substance, and the disclosure does not establish that all three attack paths are closed.
Should I stop using synced passkeys and go back to passwords?
No source recommends that, and neither do we. Going back to passwords reintroduces exactly the attacks passkeys remove - phishing, reuse, credential stuffing - in exchange for protection against an attack that requires your machine to already be compromised. The more useful distinction, raised by J. Wolfgang Goerlich in Computerworld, is that synced passkeys reintroduced a credential-portability risk that device-bound authenticators did not have. For your highest-value accounts, a hardware security key is the device-bound option.
What should a company do about this?
The concrete measure named by the researchers and analysts is server-side: require userVerification and actually validate the UV flag in the authentication response. That gap is not theoretical - eBay accepted authentication without user verification even though userVerification was set to required, and fixed it after Unit 42's report. GitHub correctly rejected the same attack, which shows a correct implementation holds. Beyond that: validate device key attestation, monitor abnormal passkey use, deploy endpoint detection, and set an explicit policy on synced versus device-bound credentials.
Was this attack used against real people?
No exploitation in the wild has been reported. Biometric Update noted on 7 August 2026 that this is demonstrative research, and no CVE had been assigned as of 3 August. That matters for how you should react: this is a reason to review how your accounts recover and re-enrol, not a reason to panic.
