Unit 42 describes three attack scenarios targeting Google Password Manager in Chrome on Windows devices equipped with a TPM. They assume malware is already running on the device; they do not show that all passkeys are broken or that exploitation is widespread. Google removed the SDS secret from Chrome logs after disclosure, but Unit 42 says it remains accessible in memory in the scenario studied.
An attack that starts at the endpoint
Passkeys replace shared passwords with a cryptographic key pair. The private key is not normally revealed to the website or typed by the user like a password. Some passkeys are synced across devices by their provider, and in September 2026 Google announced secure transfers between password managers on Android. This controlled portability does not make the key equivalent to a plaintext password, but it means the provider, synchronization, and transfer flows are also part of the trust boundary.
Unit 42’s research describes three techniques—Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key—against Google Password Manager in Chrome on Windows devices equipped with a TPM. They all begin with the same condition: malware is already running on the victim’s endpoint as an ordinary user.
That boundary matters. This is not a remote attack that breaks passkey cryptography. It is an attempt to abuse the trust relationships between the browser, the device, the cloud credential manager, and the relying party.
Three trust paths under pressure
The first path, Pass-ta-key, reuses the device’s hardware-backed identity to obtain a login assertion without a fingerprint, PIN, or visible interaction. When a relying party correctly checks WebAuthn’s User Verified (UV) bit, it should reject that assertion when user verification is required. The weakness appears when a service trusts the requested policy but fails to validate the returned result.
The second path, Silver Pass-ta-key, targets device re-enrollment. After local state is deleted or invalidated, Chrome can enter a phase where a new verification key must be registered. The research describes an attacker-controlled key being enrolled during that transition. That key could then produce assertions that appear to have been user-verified.
The third, Golden Pass-ta-key, targets the 32-byte Security Domain Secret (SDS) used to decrypt synced passkeys. The researchers report that it can briefly appear in Chrome process memory during re-enrollment. If extracted, synced passkeys could be decrypted and reused from the attacker’s own environment.
Unit 42 says Google removed the SDS from Chrome logs after disclosure, but that the secret remained accessible in memory in the scenario studied. Unit 42 also says it reported and helped eBay fix its validation of the UV bit. These fixes target specific weaknesses: the research does not say that every current Chrome version or every service is vulnerable, or that every attack path described has been fixed. It also notes that changing a PIN or deleting data is not proven to revoke a secret that has already been stolen.
What this means for businesses
A passkey sharply reduces phishing and password reuse. It does not make a compromised endpoint trustworthy. If malware can read local data, alter re-enrollment state, or inspect browser memory, it can target the chain around authentication.
The responsibilities are shared:
- Relying parties should set
userVerification: requiredwhen the risk warrants it and validate the UV bit in every WebAuthn response. - Credential managers should harden recovery and re-enrollment, validate the origin of new keys, and keep master secrets out of client logs and memory.
- Businesses should reduce endpoint risk with updates, malware protection, least privilege, monitoring for unusual changes, and a tested revocation process.
For an SMB, the practical signal is simple: an unexpected recovery request, newly registered device, or unusual browser behavior should trigger verification—not automatic approval.
Passkeys and passwords are complementary
This research is not an argument for abandoning passkeys. It is a reminder that no authentication method should be assessed in isolation. Passkeys are a strong option for services that support them; unique passwords remain necessary for accounts and systems that do not. For a broader view, read our article on what passwordless authentication really changes.
How Soclyde fits in
Soclyde complements passkeys for accounts that still use passwords: it helps create unique secrets and keep them in a local-first encrypted vault. It does not protect an infected endpoint or replace passkeys, MFA, or endpoint monitoring.
Takeaway
Pass-ta-key targets a specific chain—Google Password Manager, Chrome on Windows, a TPM and an already compromised device—not the cryptography of all passkeys. For more on malware risks to endpoints, read our practical infostealer guide and our analysis of an infostealer bypassing Chrome’s data encryption.
