Malware already running on a Windows device can now pull a victim’s synced passkeys straight out of Google Password Manager. That’s the finding from new Unit 42’s Pass-ta-key research , which details three attacks collectively named ‘Pass-ta-key.’
These attacks demonstrate why consumer solutions like synced passkeys aren’t always appropriate for enterprise use cases, and why most workforce instances should err on the side of device-bound passkeys. IT and security teams always need to balance security and convenience: for government agencies, financial services, and highly-regulated industries, Pass-ta-key is a reminder that synced passkeys can introduce new risks associated to device trust, recovery, and other stages in the credential lifecycle.
Let’s review what the Pass-ta-key attacks are, the security lessons organizations should take from the attacks, and the capabilities that security-first organizations should prioritize in deploying secure, phishing-resistant passwordless.
The base Pass-ta-key attack lets unprivileged malware impersonate a trusted device and request a signed authentication response for one of the victim’s passkeys, without a PIN, biometrics, or any user interaction.
The second attack, Silver Pass-ta-key, goes further. Malware forces the device to re-register with Google’s cloud authenticator, then registers its own verification key in place of the victim’s. Google accepts this new registration, because the cloud authenticator doesn’t check whether the new key came from trusted hardware. From that point, the attacker can authenticate from an entirely different machine, with no further access to the victim’s device required.
The third, Golden Pass-ta-key, should worry security teams most. It extracts the security domain secret, the master key Google uses to encrypt every passkey synced to an account. That key is briefly sent to Chrome during device registration and recovery, and Unit 42 found it accessible in the browser’s process memory.
Once an attacker has the security domain secret, every passkey synced to that account, past and future, can be decrypted. Google has removed the secret from Chrome’s logs since the report, but the underlying exposure in memory remains, and there is still no way to rotate the key.
The recommended fixes, stricter user-verification checks, hardened re-registration, and keeping master keys out of browser memory, are sound advice for any vendor running a synced credential store, not just Google.
Pass-ta-key doesn’t mean that passkeys are broken. It means syncing consumers’ private key material across every signed-in device under one master secret is exactly the feature these attacks target.
That distinction matters far more for enterprises than for individual consumers, and it points to three things security leaders should take from this research:
1. Enterprises should proceed with caution with synced passkeys. The entire value of synced passkeys is that a credential registered on your phone also works on your laptop and the next device you buy, all protected by one secret that Google, Apple, Meta, or another provider the holds on your behalf. That’s a reasonable tradeoff for a consumer switching phones. In most cases that’s not acceptable for a workforce credential, because any credential that can be electronically copied significantly decreases the assurance that the credential is securely in the possession of its legitimate owner.
RSA doesn’t sync private keys anywhere. RSA Authenticator binds each passkey to the single enrolled device that created it. Likewise, the RSA iShield Key 2 roots the credential in dedicated FIDO2 hardware that never exposes the private key outside the token. Neither has a shared secret sitting in memory for malware to extract, because there isn’t one to find.
2. Phishing resistance is the first step—not the last step. Pass-ta-key demonstrates that there are more risks threatening credentials than phishing. The attack works through malware embedded in a device that goes after the credential store itself. An authentication method that resists phishing but doesn’t address a compromised endpoint has only solved half the problem.
RSA Mobile Lock covers the other half of the equation: it detects malware and other threats on the device where credentials are stored, so a compromised endpoint gets flagged before it turns into a stolen passkey vault. Phishing-resistant authentication and device-level threat detection cover different attack paths. Government agencies, financial services, and high-assurance organizations need both. And to stay secure, these organizations need solutions that go beyond phishing to defend against advanced threats and to protect credentials through their entire lifecycle.
3. Passkey solutions are not created equal. Google Password Manager was designed to make sign-in easier for a consumer with a phone, a laptop, and no IT department behind them. That’s a legitimate design goal for some businesses. It’s the wrong choice for critical infrastructure, or for a workforce with access to regulated data, PII, or sensitive IP.
As a member of the FIDO Alliance and a leading voice in its enterprise-focused working groups, RSA pushes the standards to meet the high-security use cases our customers require. We know from experience: FIDO detailed how RSA deploys its own passwordless solutions across our global workforce. We know from our own testing that convenience-first design and enterprise-grade design aren’t the same capability wearing different branding. They’re different products, built for different threat models, and research like this is where that difference shows up.
If you work in a regulated industry, Pass-ta-key is a good reminder of the following passwordless best practices:
- Take a risk-based approach. Prioritize your riskiest users, user groups, and workflows. Organizations cannot afford to prioritize convenience over security when it comes to protecting their crown jewels and should consider requiring device-bound or hardware security keys where appropriate.
- Implement controls beyond phishing. Pass-ta-key wasn’t a phishing attack, it was malware. Likewise, when MGM resorts was breached, an attacker socially engineered the help desk to reset credentials—no credentials were phished or stolen. While organizations are right to implement phishing-resistant authentication, they need other controls to ensure secure enrollment, protect against malware, and stop help desk fraud.
- Look for passwordless solutions that can do it all. Passwordless works best when it works for everyone and in every environment. Government, financial services, and high-assurance organizations should prioritize passwordless solutions that can support cloud, desktop log-in, and data centers. Those solutions should also feature the agility to support diverse real world use cases like offline access and shared workstations, and the; flexibility to be deployed anywhere, including SaaS, private cloud, on-prem and air-gapped environments.
Contact RSA to learn more about how we support passwordless for financial services and government. Or try RSA ID Plus to see how we deploy passwordless and more across cloud, hybrid, and on-premises environments.
Pass-ta-key is a set of three attacks discovered by Palo Alto Networks’ Unit 42 that let malware already running on a Windows device abuse Google Password Manager’s synced passkeys. The attacks don’t break passkey cryptography. They exploit weaknesses in how Chrome and Google’s cloud authenticator handle device trust, re-registration, and recovery.
Malware with a foothold on a compromised Windows device can impersonate trust, register a fraudulent verification key, or, in the most severe case, extract the master key that encrypts every passkey synced to a Google account. This requires the device to already be infected; passkeys still resist standard phishing.
Phishing-resistant, hardware-rooted, or device-bound passkeys remain safe for enterprise use. Synced passkeys, which copy private key material across devices under one shared cloud secret, introduce a shared point of failure that enterprises should avoid for workforce and privileged accounts.
Synced passkeys copy encrypted private key material to a cloud account so the same credential works across multiple devices. Device-bound passkeys, like those issued through RSA Authenticator, and hardware-rooted passkeys, like the RSA iShield Key 2, never leave the device or token that created them.
No. Pass-ta-key requires malware already running on the victim’s device; it isn’t a phishing attack. Passkeys still resist credential phishing. The research shows that phishing resistance alone doesn’t protect against a device that’s already compromised, which is why endpoint-level threat detection matters alongside authentication.
RSA avoids synced passkeys entirely. RSA Authenticator binds passkeys to a single enrolled device, and the RSA iShield Key 2 roots credentials in dedicated FIDO2 hardware, so there’s no shared cloud secret to steal. RSA Mobile Lock adds detection for malware and other threats on the device itself, closing the gap that phishing-resistant credentials alone don’t cover.
