Google Password Manager Research Highlights Post-Compromise Risks for Passkey-Protected Accounts

Passkeys have become a cornerstone of modern online security, offering stronger protection than traditional passwords. However, new security research suggests that malware already running on a compromised Windows computer may be able to abuse Google’s Password Manager implementation in Chrome to access passkey-protected accounts under specific conditions. The findings do not indicate a flaw in passkey cryptography itself but instead focus on weaknesses in how authentication is managed after a device has already been compromised.

Security Researchers Detail Three Attack Techniques

Researchers from Unit 42 have identified three attack methods—Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key—that target Google Password Manager’s cloud authenticator on Windows systems equipped with a Trusted Platform Module (TPM).

Rather than breaking the cryptographic protections behind passkeys, the techniques exploit how Chrome stores authentication data, re-registers trusted devices, and handles user verification during the sign-in process.

According to the researchers, the attacks could allow malware to silently generate authentication assertions, install attacker-controlled user verification keys, or extract the 32-byte Security Domain Secret (SDS), which is used to decrypt synchronized passkey private keys.

Notably, the research describes post-compromise scenarios. Every attack requires malware to already be running on the victim’s Windows device. The report does not describe active exploitation in the wild, assign CVE identifiers, or specify affected Chrome versions.

How the Attacks Work

Local Reconnaissance

The attacks begin by gathering information stored locally by Chrome.

Researchers found that synchronized credential records are stored within Chrome’s user profile under the Windows Local AppData directory. Malware running without administrator privileges can reportedly read metadata identifying websites, usernames, credential identifiers, and encrypted passkey-related data associated with the victim’s Google Password Manager account.

Pass-ta-key

The first technique focuses on Chrome’s wrapped device identity key.

Researchers say malware can extract this key and use the Windows Cryptography API: Next Generation (CNG) to request authentication from the same TPM without displaying prompts to the user.

The resulting authentication lacks the User Verified (UV) flag, which normally confirms that the user completed verification through a PIN, fingerprint, or another authentication method.

Under the current Web Authentication specification, websites that require user verification should reject authentication attempts when the UV flag is missing.

The researchers reported that GitHub correctly enforced this requirement, while eBay initially accepted the authentication until it addressed the issue after responsible disclosure.

Silver Pass-ta-key Exploits Device Re-Enrollment

The second technique targets Chrome’s device re-registration process.

Researchers found that if malware forces Chrome to re-enroll a device before a user verification key is created, an attacker may be able to register their own verification key during that window.

According to Unit 42, if Google’s service accepts the replacement key without verifying that it originated from trusted hardware, future authentication requests could include a valid UV flag, enabling logins from the attacker’s own environment.

Public Chromium source code confirms that newly registered devices can temporarily remain in a deferred verification state, although the publicly available code does not independently verify whether the reported server-side behavior remains exploitable in current Chrome releases.

Golden Pass-ta-key Targets the Security Domain Secret

The third and most significant technique attempts to obtain the Security Domain Secret (SDS).

Researchers said malware can trigger device re-enrollment and capture the SDS from Chrome’s memory while it briefly exists in plaintext. That secret can then be used to recover synchronized passkey private keys.

Chromium source code confirms that 32-byte Security Domain Secrets are processed within Chrome’s client memory. However, the broader claims regarding reliable extraction, long-term persistence, and account takeover remain based on Unit 42’s research.

The researchers also noted that Google previously removed an earlier SDS exposure from Chrome’s FIDO logs and that eBay now validates the UV flag. However, they argue that keeping the SDS in client memory still leaves a potential attack path after endpoint compromise.

No Evidence of Active Exploitation

As of August 3, 2026, no Common Vulnerabilities and Exposures (CVE) entries matching the three attack techniques had been published in the National Vulnerability Database.

The research also does not clarify whether Google has fully addressed all three attack paths. Public Chrome documentation, Google support resources, and eBay announcements do not currently document every reported mitigation or provide users with a method to determine whether an SDS has been exposed.

Google’s support documentation allows users to change their Google Password Manager PIN or delete stored Password Manager data, but it does not explain whether those actions invalidate a previously compromised Security Domain Secret.

Recommended Security Measures

Researchers recommend that websites enforce the Web Authentication standard by requiring user verification and validating the returned User Verified flag during authentication.

They also advise credential providers to verify newly enrolled authentication keys using hardware attestation, strengthen device recovery and re-registration safeguards, limit access to locally stored passkey information, and reduce the exposure of sensitive master keys within client memory and logging systems.

For individual users, the research reinforces the importance of preventing malware infections through timely software updates, reputable security software, and cautious handling of downloads and email attachments. Since all three attack methods require an already compromised Windows system, maintaining endpoint security remains the most effective defense.

Conclusion

The Unit 42 research highlights that even strong authentication technologies like passkeys can be affected by weaknesses in surrounding software workflows after a device has been compromised. While the underlying cryptography remains intact, the findings emphasize the importance of secure implementation, rigorous user verification checks, and continued improvements to credential management systems. There is currently no evidence that these techniques are being exploited in the wild, but the research offers valuable guidance for browser developers, online services, and organizations seeking to strengthen passkey security.

John Irving

John Irving writes for Bjournal, covering news, politics, business, technology, sport, entertainment, and lifestyle. He focuses on clear, reliable reporting and useful information, helping readers stay informed about current events, emerging trends, and stories that matter.