An attack that starts at the endpoint
Passkeys replace shared passwords with a cryptographic key pair. That is a meaningful improvement: a passkey is not meant to be copied or handed over like a traditional secret. But the promise does not remove the need to protect the environment where the passkey is used.
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.
The research does not claim that these paths are being exploited in the wild, nor that every current Chrome version remains vulnerable. It documents a post-compromise threat model and 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.
Soclyde addresses that complementary layer by generating unique secrets, storing them in local-first encrypted vaults, and keeping control of the data on the user’s devices. It does not protect an infected endpoint and does not replace passkeys, MFA, or monitoring. It does reduce reuse and avoids turning a local incident into a centralized cloud-vault problem.
The lesson from Pass-ta-key is concise: the key can be excellent, but the door around it still depends on the device. Explore Soclyde’s local-first approach.
