August 2025 —
Passkeys are rapidly becoming one of the most important developments in authentication. They eliminate passwords, provide strong resistance to phishing, and use public-key cryptography rather than shared secrets that can be stolen or reused.
But new security research demonstrates an important distinction that organizations should understand:
Not all passkeys have the same security characteristics.
Researchers from Palo Alto Networks Unit 42 have demonstrated three attacks against Google-synced passkeys that can allow malware on a compromised Windows endpoint to take over passkey-protected accounts — in some cases without administrative privileges, device unlock, or user interaction.
The research does not break FIDO or WebAuthn cryptography.
Instead, it exposes weaknesses in the infrastructure surrounding synchronized passkeys, including device trust, credential synchronization, onboarding, recovery, and user-verification processes.
For organizations evaluating passwordless authentication, this distinction between synced passkeys and device-bound credentials is increasingly important.
What Did the Researchers Find?
Unit 42 demonstrated three attack techniques against Google Password Manager's synced passkey implementation in Chrome on Windows.
The researchers collectively call the attacks "Pass-ta-key."
Importantly, all three scenarios begin with an endpoint that has already been compromised by malware. The research therefore does not show that an attacker can remotely break FIDO authentication from scratch.
What it demonstrates is what malware can potentially accomplish after gaining access to the endpoint.
1. Pass-ta-key: Impersonating a Trusted Device
The first attack targets the device identity mechanisms used by Google's Cloud Authenticator.
Researchers demonstrated that malware running without elevated privileges could access a TPM-wrapped device identity key and use the Windows cryptographic APIs to perform authentication operations.
This can allow an attacker to authenticate using a victim's synced passkey without requiring the victim to interact with the authentication process.
Whether the attack succeeds also depends on how the application receiving the authentication request — the relying party — validates user verification.
That leads to another important finding from the research.
When "MFA Required" Isn't Actually Enforced
WebAuthn authentication responses contain a User Verified (UV) flag indicating whether user verification — such as a PIN or biometric — actually occurred.
Unit 42 found relying parties that requested user verification but failed to properly validate that flag when processing the authentication response.
The result?
Authentication that was intended to require multiple factors could effectively be reduced to a single factor.
eBay was one of the services identified during the research and corrected the issue following responsible disclosure.
This finding is important beyond Google-synced passkeys because it highlights a fundamental authentication implementation issue:
Strong authentication technology only works when every participant in the authentication process correctly enforces it.
2. Silver Pass-ta-key: Bypassing User Verification
The second attack goes further.
Unit 42 researchers found that they could manipulate Google's device onboarding process and register an attacker-controlled user-verification key.
Once registered, the attacker's key could be accepted by the cloud authenticator as though legitimate device verification had occurred.
This could allow an attacker to generate authentication responses indicating that the user had successfully verified their identity — even though no biometric authentication or device unlock actually occurred.
More significantly, the attacker could subsequently authenticate from another environment without requiring the victim's device to remain online.
3. Golden Pass-ta-key: Extracting the Master Secret
The third attack has potentially the broadest consequences.
Google's synced passkey architecture protects passkey private keys using a master key called the Security Domain Secret (SDS).
Unit 42 researchers discovered that this secret could become accessible on the client during device onboarding or recovery.
Google removed one instance in which the SDS appeared in Chrome's FIDO device logs following disclosure. However, according to Unit 42, the underlying secret still reaches the client and can temporarily exist in Chrome process memory.
Malware capable of accessing that memory could potentially obtain the SDS and use it to decrypt the synced passkeys associated with the account.
This changes the threat model significantly.
Instead of compromising a single authentication attempt, an attacker who obtains the SDS could potentially recover multiple synchronized credentials.
The Most Important Point: FIDO Is Not Broken
It is critical not to draw the wrong conclusion from this research.
These attacks do not break FIDO2 or WebAuthn cryptography.
The researchers are exploiting implementation layers surrounding the underlying authentication standard.
Synced passkeys introduce additional infrastructure to make credentials conveniently available across multiple devices. That infrastructure can include cloud synchronization, recovery systems, device enrollment, account recovery, and mechanisms for establishing trust on new devices.
Those capabilities provide enormous usability benefits.
But they also create security components and attack surfaces that do not exist in the same way with a traditional device-bound hardware authenticator.
That distinction matters.
Synced Passkeys vs. Device-Bound Authentication
With a synced passkey, credentials are designed to become available across multiple authorized devices.
With a device-bound hardware authenticator — such as a security key — the private credential remains tied to the physical authenticator.
The private key does not need to be synchronized through a cloud service or exported to another device.
This eliminates several of the components targeted by the Unit 42 research.
There is no cloud-synchronized master secret for endpoint malware to extract, no passkey synchronization process to manipulate, and no cloud re-onboarding workflow required to move that private credential to another device.
For organizations protecting administrators, privileged users, regulated systems, financial applications, or other high-value resources, that architectural difference deserves careful consideration.
Hardware Security Keys Are Not a Cure for Endpoint Compromise
There is an equally important caveat.
A hardware security key does not make a compromised computer secure.
Malware running on an endpoint may still be capable of stealing session tokens, manipulating applications, capturing information, or abusing an already authenticated session.
The advantage of device-bound hardware authentication is more specific:
Compromising the computer does not provide the attacker with a portable copy of the authentication private key.
The credential remains within the authenticator.
That is a very important security property, but organizations should not mistake credential protection for complete endpoint protection.
Authentication and endpoint security remain complementary controls.
Don't Forget the Recovery Path
There is another lesson enterprises should take from this research.
Your authentication system is only as strong as its weakest enrollment, fallback, and recovery mechanism.
An organization can deploy phishing-resistant hardware security keys for employees and administrators, but much of that benefit can disappear if users can simply fall back to:
SMS authentication
Email OTP
weaker authentication methods
poorly protected account recovery
unrestricted synced passkeys
Attackers will naturally choose the easiest available route.
Organizations moving toward passwordless authentication therefore need to evaluate the entire authentication lifecycle, not simply the credential used during normal login.
Questions Security Teams Should Be Asking
The Unit 42 research provides a good opportunity for organizations to review their current passwordless deployments.
Security and identity teams should consider:
Where are synced passkeys currently being used?
Determine whether synced credentials are protecting ordinary consumer-style applications or privileged enterprise resources.
Are relying parties actually enforcing user verification?
Setting userVerification=required is not enough if the application does not validate the User Verified flag in the resulting WebAuthn response.
Is authenticator attestation being used where appropriate?
Enterprise environments may benefit from restricting enrollment to approved authenticator types.
What authentication methods are permitted as fallback?
Strong authentication can be undermined by weaker recovery mechanisms.
How are privileged accounts protected?
Administrative and other high-value accounts may warrant device-bound authentication even when synced passkeys are acceptable for lower-risk users.
What happens when a device or credential is lost?
Recovery and re-enrollment should receive the same security scrutiny as normal authentication.
Passkeys Are Still an Important Step Forward
None of this changes the fundamental value of passkeys.
Replacing passwords with cryptographic authentication removes many of the attacks organizations have struggled with for decades, including password reuse, credential stuffing, and many forms of phishing.
But as passwordless authentication becomes mainstream, attackers will increasingly target the systems surrounding the cryptography.
That is exactly what the Unit 42 research demonstrates.
The next phase of passwordless security will therefore be about more than simply asking:
"Do we support passkeys?"
Organizations will increasingly need to ask:
"What kind of passkeys are we using, where are the credentials stored, how are they synchronized, and what level of assurance do we need for this application?"
For many everyday applications, synced passkeys may provide an excellent combination of security and usability.
For privileged access and higher-assurance enterprise environments, device-bound credentials provide an important additional security boundary.
MTRIX: Choosing the Right Authentication Architecture
Authentication is not a one-size-fits-all decision.
MTRIX helps organizations evaluate authentication requirements and determine where synced passkeys, device-bound passkeys, hardware security keys, smart cards, or other phishing-resistant authentication technologies make sense.
More importantly, we help customers examine the complete authentication architecture — including enrollment, recovery, fallback authentication, authenticator policies, and integration with existing identity platforms.
The lesson from the latest research isn't that organizations should abandon passkeys.
It's that organizations need to understand which type of passkey they are deploying — and whether its security architecture matches the risk of the systems it protects.
If your organization is evaluating passkeys, FIDO2 security keys, or a broader passwordless authentication strategy, contact MTRIX to discuss the right approach for your environment.
Sources
Palo Alto Networks Unit 42 — Pass the Passkey: A Novel Attack Surface in Passwordless Authentication
Palo Alto Networks Unit 42 — Google Cloud Authenticator: The Hidden Mechanisms of Passwordless Authentication
CyberArk Labs — The Art of the Invisible Key: Passkey Global Breakthrough