Pass-ta-key: The Passkey Cryptography Held. The Sync Layer Didn’t.

Passkeys have spent three years being sold as the end of credential theft. This week researchers at Unit 42, Palo Alto Networks’ threat intelligence group, published three attack techniques that hijack passkeys synced through Google Password Manager. They are called Pass-ta-key, Silver Pass-ta-key and Golden Pass-ta-key, and the last one recovers the single secret that encrypts every passkey in a victim’s account.

Before anyone rips passkeys out of a rollout plan: the cryptography did not break. Every one of these techniques needs malware already running on the user’s Windows machine. What the research actually exposes is that the industry hardened the authentication ceremony and left the sync, enrolment and recovery machinery around it comparatively soft.

What Unit 42 found

The three techniques escalate. Each assumes malware with ordinary local user privileges — no kernel exploit, no administrator rights.

Pass-ta-key extracts Chrome’s device identity key and uses the machine’s TPM to sign authentication requests the attacker chooses. The resulting assertion is missing the User Verified flag, so any service that bothers to check that flag will reject it. Many do not.

Silver Pass-ta-key forces the device to re-enrol and slips an attacker-controlled key in before Chrome creates its own user-verification key. Unit 42 reports the service does not verify that a newly registered key came from secure hardware, so the substitute is accepted as genuine.

Golden Pass-ta-key is the serious one. Google Password Manager encrypts synced passkeys with a 32-byte value called the security domain secret. That secret is handed to Chrome briefly whenever a device enrols or recovers access, and while it sits in process memory it is plaintext. Malware that triggers a re-enrolment can read it out and decrypt the private keys for every passkey in the account.

Why the master key changes the calculus

A stolen session cookie expires. A stolen password gets rotated. According to Unit 42 there is currently no way to rotate or revoke the security domain secret. If it leaks, the remedy is not a reset, it is re-enrolling every passkey the account holds, on every site.

Google has already removed the secret from Chrome’s debug logs, which is where one of the leak paths ran. Reporting indicates it remains recoverable from process memory during device re-registration, and no CVE identifiers have been assigned to any of the three techniques.

What this is not

It is not a reason to go back to passwords. A password gets phished at scale from anywhere in the world; these attacks need code already executing on a specific machine. That is a materially harder bar, and passkeys remain phishing-resistant in the case that matters most to your clients, a convincing email at 4pm on a Friday.

It is also not a flaw unique to Google. The weakness is in the cloud-authenticator pattern itself: a synced credential has to be recoverable across devices, and recoverability means a secret exists somewhere that can reconstruct it. Any provider syncing passkeys through a cloud account inherits some version of this problem.

What MSPs and MSSPs should do this week

1. Verify the UV flag on the relying-party side. An assertion without User Verified should be refused, not logged. This is the cheapest of these fixes and it neutralises the first technique outright.
2. Treat endpoint compromise as the root event. Every one of these paths starts with malware on a managed Windows device. EDR coverage, and knowing which endpoints lack it, matters more here than any passkey setting.
3. Alert on passkey re-enrolment. Silver and Golden both require forcing a device to re-register. A sudden re-enrolment on an endpoint nobody replaced is a signal worth an alert.
4. Prefer device-bound credentials for privileged accounts. Where a credential never syncs, there is no shared secret to recover. Reserve synced passkeys for the long tail and keep admin, finance and remote-access accounts on hardware-backed, device-bound authentication.
5. Know where passkeys are not yet an option. Most client estates still contain legacy apps that cannot take a passkey at all, and those accounts are the ones actually being breached today.

The lesson worth keeping

Authentication research keeps arriving at the same place. The login ceremony is now the strongest part of the stack, so attackers moved to enrolment, sync and recovery. Pass-ta-key is a well-executed reminder that a credential is only as trustworthy as the process that provisioned and can restore it.

Where KZero fits

KZero Passwordless was built on the assumption this research demonstrates: that the weak point is the recovery and sync path, not the signature. Our passwordless authentication keeps credentials bound to a device and verified by biometrics, so there is no cloud-held secret that reconstructs a user’s credentials somewhere else. Our biometric password manager covers the legacy applications that cannot accept a passkey yet, which is where most real breaches still begin, and Security Audit shows MSPs which client credentials are weak, reused or already exposed.

We will not pretend any of this makes an infected endpoint safe; nothing does, and a vendor who tells you otherwise is selling something. What it does mean is that compromising one machine does not hand an attacker a key to every credential the user owns. If you manage authentication for other people’s businesses, that difference is worth designing for.