With five billion passkeys now live globally, we’ve finally stripped attackers of their favorite weapon: the reusable passwords (FIDO Alliance, 2026). Passkeys have removed one of the oldest weaknesses in authentication by getting rid of the reusable secret attackers can phish, steal, or stuff into another login page.
Yet as that door slams shut, attackers are already doing what they do best: finding whatever the system trusts next. Recent Unit 42 research into Google’s synced passkey ecosystem shows where that attention is moving. The researchers demonstrated three attack paths that begin with malware already running on a Windows machine and then work through the surrounding authentication infrastructure, including device identity, user verification, and recovery. In the most serious scenario, they were able to recover the private keys behind synced passkeys themselves.
FIDO Alliance says 75% of consumers now use passkeys on at least some accounts, while 68% of organizations are deploying, piloting or rolling them out.
How Malware Can Turn a Trusted Device into an Authentication Proxy
Once malware is running on the victim’s Windows device, Chrome reveals more than you might expect. Synced passkey records are stored locally as part of Chrome’s normal sync process. Unit 42 found that malware running without administrator privileges could inspect those records and identify which services the victim uses passkeys for, along with usernames, credential IDs and encrypted key material.
So, the attacker gets a map before touching the authentication flow. The first technique, Pass-ta-key, targets the hardware-backed identity key Chrome uses when talking to Google’s cloud authenticator.
The key itself is protected by the TPM, which sounds reassuring. But malware does not necessarily need to steal it. Researchers found they could extract wrapped key material and use standard Windows cryptographic APIs to make the victim’s own device perform the signing operation. The attackers are making the trusted machine behave on their behalf.
There should still be another check. Services can require user verification, usually through a PIN or biometric. WebAuthn represents that using the UV flag. Unit 42 found relying parties that requested user verification but failed to validate the UV flag correctly after the response came back. In testing, that was enough for authentication to succeed without real verification. eBay was one example before the issue was fixed. Eventually, a sophisticated passwordless stack can still come down to whether somebody checked one bit.
If Trust Can Be Rewritten, the Login Doesn’t Need to Be Beaten
The second technique goes after device onboarding rather than the login itself. During Google Password Manager setup on Windows, a device can temporarily enter a uv_key_pending state before its user verification key is fully established.
Unit 42 identified a way to force the victim back into that state, then register an attacker-controlled verification key. According to the research, the cloud authenticator did not verify that the new key actually came from secure hardware. Once accepted, signatures from the attacker’s key could be treated as though the user had legitimately unlocked the device.
That makes the second attack, Silver Pass-ta-key, much more persistent.
With Pass-ta-key, the compromised machine still participates in the login. With Silver Pass-ta-key, the attacker can later authenticate from their own environment because their verification key has already been accepted as legitimate. The victim’s laptop no longer needs to stay online for each attempt.
This is where recovery and re-enrolment deserve more attention. Security teams tend to spend most of their energy on the normal login path because that is what users see every day. Yet those flows have extraordinary authority. They decide when a new device becomes trusted, when an old one can be forgotten and when credentials can be rebuilt after something goes wrong.
One 32-Byte Secret Can Unlock the Whole Passkey Set
The third technique, Golden Pass-ta-key, targets the security domain secret, or SDS, used to protect synced passkeys. Google’s synced passkeys are protected by a 32-byte security domain secret, or SDS. If an attacker gets that secret, they can potentially decrypt the private key material behind the synced passkeys.
Unit 42 first found the SDS appearing in plaintext in Chrome’s FIDO device logs during registration. Google removed that exposure after disclosure.
Researchers found it could temporarily exist in Chrome process memory during re-registration. Malware could force a fresh onboarding event, watch for the right moment and extract the SDS from memory.
From there, encrypted synced passkey records could be decrypted and the underlying private keys recovered. That starts to recreate something passkeys were specifically meant to avoid. Portable credentials. Unit 42 says compromise of the SDS could affect existing passkeys and future ones protected by the same secret. It also reports that there is currently no way to rotate or revoke the SDS. So, resetting one account may not be enough.
The Next Credential Theft Target Is Whatever the Browser Already Trusts
We've seen this play out before. When MFA rendered stolen passwords useless, infostealers pivoted to hijacking session cookies. Stealing a browser's pre-existing proof of authentication was simply easier than logging in.
Passkeys trigger that exact same shift, just deeper in the stack. Phishing a password yields nothing, so attackers now target device identity, browser state, local memory, and recovery flows. Unit 42’s research proves the point: instead of fighting the cryptography, malware simply exploits what Chrome and cloud authenticators blindly trust about the host machine. Google is already countering this shift via Device Bound Session Credentials (DBSC) to lock cookies to specific hardware. But as passkeys dominate, the security battlefield moves permanently from the front door to the shadows, where trust is enrolled, recovered, and maintained in memory.
Passkeys will probably push more attacks into these less visible parts of authentication. Recovery becomes more interesting because it can re-establish trust. Device enrolment becomes interesting because it decides which keys belong there. Browser memory becomes interesting because sensitive material may appear there briefly even when it is heavily protected everywhere else.
Until we treat local device state and recovery flows with the same paranoid scrutiny as the initial login, we aren't actually eliminating identity theft. We’re just paying attackers to become better engineers.