New Passkey Attacks Expose Private Keys and Bypass Phishing-Resistant MFA Without Breaking Encryption

Three independent security investigations have exposed weaknesses in the systems surrounding passkeys, demonstrating how attackers with access to a Windows endpoint could impersonate users, bypass phishing-resistant multifactor authentication or recover the private keys behind cloud-synchronised credentials.

The findings do not undermine the public-key cryptography at the heart of FIDO2 and WebAuthn. Instead, the researchers targeted the software, cloud services, recovery processes and operating-system interfaces responsible for creating, storing and using passkeys.

The distinction is important. Passkeys remain substantially more resistant to conventional phishing, credential stuffing and password-database theft than passwords. However, the new research shows that an attacker may not need to defeat their cryptography if malware can make a legitimate authenticator sign data, steal an earlier signed assertion, manipulate a cloud authenticator or obtain a master secret while it is exposed in browser memory.

The research encompasses three separate bodies of work disclosed around Black Hat USA 2026. SpecterOps demonstrated a “Pass-the-Passkey” chain affecting Windows and Microsoft Entra ID. Palo Alto Networks Unit 42 documented three attacks against Google Password Manager’s passkey implementation in Chrome on Windows. Independent researcher Dirk-jan Mollema separately showed how malware operating inside a signed-in Windows session could silently use a Windows Hello for Business key to authenticate to Entra ID.

Each attack has different prerequisites and consequences. They should not be treated as a single vulnerability or evidence that passkeys can be defeated remotely in every deployment.

In the Unit 42 and Mollema scenarios, an attacker must already have code running on the victim’s endpoint or control of the victim’s active Windows session. SpecterOps’ chain similarly depends on access sufficient to obtain authentication material exposed by Windows. There is no evidence in the published research that attackers have exploited any of the techniques in real-world intrusions.

Nevertheless, the findings carry wider implications as organisations accelerate their move away from passwords and conventional MFA. Microsoft is preparing to place significantly more Entra ID users into passkey registration campaigns from September 2026, making weaknesses in implementation, endpoint protection and recovery mechanisms increasingly consequential.

Passkeys resist phishing—but cannot make a compromised endpoint trustworthy

A passkey replaces a reusable password with a cryptographic key pair. The private key is held by an authenticator, while the online service stores the corresponding public key.

During authentication, the service issues a challenge that the authenticator signs. The service validates the signature and confirms that it was produced for the correct website or application. Because the credential is bound to the service’s domain, an attacker operating a lookalike phishing site should not be able to trick the authenticator into generating a valid signature for the genuine service.

Passkeys may be device-bound, as with a hardware security key or some enterprise Windows Hello deployments, or synchronised through a credential manager so that they are available across a user’s devices.

These properties eliminate several weaknesses associated with passwords. There is no shared secret for a user to type into a fraudulent website, no password database that can be cracked into reusable credentials and no static password that can be replayed against another service.

The new research targets what happens around that cryptographic exchange.

If malware can ask the legitimate key to sign attacker-controlled data, the key does not have to be exported. If a previously generated assertion is inadvertently retained and accepted again, the attacker may not need the authenticator at all. If a synchronisation service briefly exposes the secret used to encrypt an entire collection of passkeys, an endpoint compromise can potentially become a lasting credential compromise.

That is the common thread connecting the three otherwise distinct investigations.

SpecterOps finds a route to “Pass-the-Passkey”

SpecterOps principal security researcher Michael Grafnetter presented the company’s Pass-the-Passkey research at Black Hat USA in Las Vegas on August 5.

The name draws a deliberate comparison with pass-the-hash attacks. In those attacks, adversaries do not recover a victim’s plaintext password; they reuse a derived authentication secret that is sufficient to impersonate the user. SpecterOps applied the same principle to passkeys: an attacker may not need the private key if another piece of signed material can be reused to obtain the same result.

According to the company’s technical paper, Windows retained historical signatures generated by YubiKey authenticators in cleartext event data. SpecterOps said authenticated but unprivileged users could read the information, including through remote access.

The Windows exposure was assigned CVE-2026-34348. Microsoft describes it as a protection-mechanism failure in the Windows Event Logging Service that could permit information disclosure over a network. Microsoft gave it a CVSS 3.1 score of 6.5, reflecting low attack complexity, limited privileges and the potential for high confidentiality impact without a direct impact on integrity or availability. NVD’s record lists affected configurations spanning supported versions of Windows 10, Windows 11 and Windows Server.

The breadth of the affected-product list does not necessarily mean the complete SpecterOps attack chain works identically against every listed Windows release. CVE-2026-34348 covers the operating-system disclosure; the end-to-end impersonation chain also involved how Microsoft Entra ID processed passkey authentication data.

SpecterOps found that the exposed signed material could be combined with weaknesses in Entra ID’s validation process. This enabled the researchers to impersonate privileged identities while producing an authentication result that satisfied policies requiring phishing-resistant MFA.

Crucially, the researchers did not extract the private key from the YubiKey. The cryptographic signature was authentic because the legitimate hardware authenticator had created it earlier. The failure arose because Windows retained sensitive output and the downstream identity service reportedly accepted it in a subsequent attack flow.

Microsoft issued security updates for CVE-2026-34348 in July. The company has also said it applied mitigations for the separately reported passkey-relay assertion issue, although its public CVE advisory does not explain the Entra-side changes in technical detail.

That separation matters to defenders. Installing the Windows update addresses the documented Event Logging Service vulnerability, but organisations should not assume that the CVE entry fully describes every cloud-side condition involved in SpecterOps’ research.

SpecterOps has also published research tools and supporting documentation intended to help authorised security teams assess WebAuthn and FIDO2 deployments.

Malware can impersonate a Google Password Manager client

Unit 42’s research focuses on synchronised passkeys managed by Google Password Manager in Chrome on Windows systems equipped with a Trusted Platform Module.

The researchers identified three techniques, named Pass-ta-key, Silver Pass-ta-key and Golden Pass-ta-key. All begin with malware already operating as a standard user on the victim’s computer. They are therefore post-compromise techniques rather than a way for an unauthenticated attacker on the internet to defeat a passkey directly.

Chrome stores synchronised passkey records in its local synchronisation database. Unit 42 found that an ordinary user process could read records containing the websites and usernames associated with the victim’s passkeys, credential identifiers and encrypted private-key material.

The encrypted private keys were not immediately usable. However, the records gave malware a map of which accounts to target and the information needed to interact with Google Password Manager’s cloud authenticator.

In the first Pass-ta-key technique, the researchers examined the hardware-backed key Chrome uses to establish the identity of a trusted client device.

Chrome exported the identity key in an opaque, TPM-wrapped form and saved it in a local state file. The key remained bound to the computer’s TPM, meaning malware could not simply move it to another system and decrypt it. Unit 42 nevertheless found that a process running as the victim could retrieve the wrapped key and invoke standard Windows cryptographic interfaces to ask the TPM to perform signing operations.

The malware could therefore make the victim’s computer produce a valid device-identity signature without administrative privileges, a new device unlock or visible user interaction.

An attacker could begin a passkey login on another machine, obtain a fresh challenge from the targeted service and communicate with Google’s cloud authenticator. Malware on the victim’s computer would then use the legitimate TPM-backed identity key to sign the relevant request. From the cloud service’s perspective, the message appeared to originate from a registered device.

The cloud authenticator could consequently return a cryptographically valid WebAuthn assertion for the targeted account.

The attack’s success at the final service depended on whether that service strictly enforced user verification. WebAuthn authentication data includes a user-verification flag indicating whether the user authenticated with a PIN, biometric or comparable mechanism.

Unit 42 found that assertions generated using the device identity key had the user-verification flag cleared. Correctly implemented services requiring user verification should reject them.

Not every service did.

The researchers demonstrated the attack against eBay even though the website requested user verification. The service accepted the assertion without correctly enforcing the user-verification flag. Unit 42 reported the problem, and eBay subsequently changed its validation.

This part of the research highlights that requesting user verification and verifying its presence are two different operations. A service can configure WebAuthn to ask for verification but still undermine the protection if its server-side implementation does not reject an assertion in which the relevant bit is unset.

Silver Pass-ta-key replaces the user-verification key

Unit 42’s second technique went further by attacking the mechanism that tells Google’s cloud authenticator that a device unlock has occurred.

Rather than attempting to break the legitimate user-verification key, the researchers found a way to invalidate it and register a replacement key controlled by the attacker.

Chrome’s onboarding process on Windows created a window in which a device could enter a pending state before its definitive user-verification key was registered. During initial use, the user supplied a Google Password Manager recovery PIN. Chrome deferred creation of the device’s user-verification key until a subsequent passkey operation, apparently avoiding successive prompts for the recovery PIN and Windows Hello.

According to Unit 42, malware could force the device back through this onboarding flow by manipulating its local passkey state. The attacker could then exploit the pending state to register a new public key as the device’s user-verification key.

The cloud authenticator did not adequately validate the origin or hardware attestation of the newly supplied key, the researchers said. Once registered, an attacker-controlled private key could generate requests that Google’s service treated as proof that the victim had completed biometric or PIN verification.

The result was more durable than the first Pass-ta-key technique. The attacker would no longer need the victim’s endpoint to be online every time an account was accessed. Assertions could be generated from the attacker’s own infrastructure with the user-verification flag set, allowing authentication against services that correctly required and validated user verification.

Unit 42 recommends that credential managers validate the attestation and origin of all newly registered device keys, particularly keys trusted to represent user verification. Recovery and re-registration operations should also require additional authentication rather than inheriting trust from locally manipulated state.

Golden Pass-ta-key exposes the secret protecting every synced passkey

The most serious Unit 42 technique targeted the Security Domain Secret, or SDS, used to encrypt synchronised passkey private keys.

The SDS is a 32-byte symmetric master secret. Encrypted versions of the passkey private keys can be stored and synchronised because their confidentiality depends on this master secret remaining protected.

Unit 42 initially discovered that Chrome exposed the SDS in cleartext through its FIDO device log while registering with the cloud authenticator. Google removed the value from the logging output after receiving the researchers’ report.

However, the underlying registration process continued to send the SDS to the Chrome client, according to the research. The secret consequently remained temporarily accessible in the browser’s process memory during device registration or re-registration.

Malware could force Chrome through a fresh onboarding process, monitor for the relevant change to its local state and dump the browser’s memory at the appropriate moment. Once it recovered the SDS, it could combine that secret with the encrypted passkey records in Chrome’s synchronisation database.

That would allow the attacker to decrypt and recover the actual private keys for the victim’s synchronised passkeys.

This is materially different from borrowing a TPM-bound key or relaying a signed assertion. The attacker obtains portable private-key material that can be used outside the compromised endpoint to produce valid signatures.

Unit 42 said the compromised SDS could decrypt existing synced passkeys and passkeys subsequently protected under the same secret. The researchers also reported that Google’s implementation did not provide a way to rotate or revoke the SDS, potentially making recovery from this form of compromise more difficult than resetting a password or removing a device.

The researchers warned that synchronised WebAuthn credentials also provide limited visibility through signature counters. Traditional authenticators may increment a counter when they sign an authentication request, allowing a service to identify unexpected reuse or cloning. Synchronised credentials commonly return a constant counter because maintaining a reliable global value across independent devices is technically difficult.

That limitation can deprive a service of a useful signal when a private key is used from an unexpected environment.

Unit 42’s full technical analysis says Google removed the SDS from Chrome’s device logs but does not state that all three attack paths have been completely eliminated. The researchers recommend preventing sensitive master-key material from reaching client-accessible memory at all, rather than relying solely on the absence of logging.

Windows Hello key remains non-exportable—but malware can still use it

Mollema’s investigation concerned Windows Hello for Business rather than Google’s synchronised passkey architecture.

Windows Hello for Business commonly stores a user’s private key in the computer’s TPM. The hardware protection makes the key difficult to export and is one reason the technology is treated as a strong, phishing-resistant authentication method.

A non-exportable key is not necessarily an unusable key, however.

Windows must allow the legitimate user’s session to perform cryptographic operations for single sign-on. Mollema found that a low-privilege process running inside an already authenticated session could call Windows cryptographic interfaces and ask the Windows Hello key to sign arbitrary authentication data. The operation did not require the attacker to know the user’s PIN, extract the key or trigger a new biometric prompt.

The distinction is similar to malware taking control of an unlocked session: the attacker does not steal the key itself but inherits the session’s ability to invoke it.

Earlier research had shown how Windows Hello for Business keys could contribute to requests for Primary Refresh Tokens, but that route involved additional device requirements. Mollema’s new work treated the Windows Hello key as a FIDO2 credential and used it through Entra ID’s WebAuthn flow.

He found that Entra ID issued a signed WebAuthn challenge with a five-minute validity period. According to his testing, the challenge was not bound to the browser session, user or tenant that requested it.

An attacker could therefore request a challenge on an attacker-controlled computer, send it to malware operating in the victim’s Windows session and have the legitimate Windows Hello key create the complete WebAuthn assertion. The assertion could then be returned to the attacker and exchanged for tokens or used to open an authenticated browser session as the victim.

Mollema reported that the resulting sign-in satisfied Conditional Access policies requiring phishing-resistant authentication. This is not because Entra incorrectly identified a fake cryptographic signature: the victim’s legitimate hardware-backed key really did generate the signature. The missing security boundary was fresh confirmation that the user intended that specific authentication.

His technical disclosure also describes a route from the initial sign-in to longer-term persistence. The resulting token did not contain a device ID claim. Subject to the tenant’s policies and the victim’s permissions, such a token could be used in a device-registration flow. An attacker could then obtain a Primary Refresh Token associated with a newly registered device and add other authentication material where policy allowed.

Strict device-compliance or device-state policies may interrupt the chain, and the complete persistence route will not work in every Entra deployment.

Mollema recommended monitoring Windows Hello for Business sign-ins that contain no device identifier. His example query searches Entra sign-in logs for the Windows Hello for Business authentication method and an empty DeviceDetail.deviceId value.

This is an investigative signal rather than definitive proof of compromise. Legitimate use of an incognito window or a browser without integrated single sign-on can produce a similar event. Security teams should correlate it with unexpected device registrations, unusual locations, new authentication methods and subsequent token activity.

Synced and device-bound passkeys present different risks

The findings complicate a simplistic choice between synchronised and hardware-bound passkeys.

A device-bound credential limits portability and can prevent malware from copying the underlying private key. Both the SpecterOps and Mollema research nevertheless demonstrate ways an attacker may obtain equivalent authentication value without exporting that key—either by reusing signed data or asking the legitimate key to produce a new signature.

Synchronised passkeys offer recovery and cross-device convenience, making them easier to deploy at scale. That convenience introduces additional infrastructure: cloud authenticators, device identity keys, recovery PINs, onboarding state, local synchronisation databases and master secrets. Each component becomes part of the credential’s effective security boundary.

Unit 42 demonstrated how weaknesses across those components could lead not merely to an isolated login but to recovery of the underlying private keys.

This does not mean organisations should return to passwords or SMS-based authentication. Passwords remain phishable and reusable, while one-time codes can be stolen through adversary-in-the-middle pages, social engineering and session interception. The new research instead shows that “phishing resistant” is a property of a particular attack model, not a promise that the credential remains safe after arbitrary endpoint compromise.

Microsoft’s passkey transition raises the operational stakes

The disclosures arrive shortly before a significant change to Microsoft Entra ID.

Beginning September 1, 2026, Microsoft says users enabled for SMS or voice authentication through the Authentication Methods Policy or legacy MFA settings will automatically be enabled for passkeys. Microsoft-managed registration campaigns will then encourage those users to create passkeys after completing MFA.

The prompt will initially permit unlimited postponements. Microsoft-provided SMS and voice delivery is scheduled to end on February 1, 2027. After that date, users who have no other suitable authentication method will face a blocking passkey-registration requirement unless their organisation has configured an eligible customer-managed telecommunications provider.

Microsoft continues to describe passkeys as its preferred migration path for most users, and the new research does not negate the security benefits of that transition. It does mean that enterprises should treat passkey deployment as an identity and endpoint-security programme rather than a simple replacement of one login method with another.

Microsoft’s current migration guidance recommends enabling passkeys through a staged campaign, preparing users for the transition and moving most accounts away from telecommunications-based verification.

What organisations should do now

Windows administrators should prioritise the Microsoft security updates addressing CVE-2026-34348 across affected workstations and servers. Because the vulnerability involves information exposure through Windows logging, defenders should also consider whether untrusted or lower-privileged users have had remote access to affected systems.

Organisations using Entra ID should review authentication and device-registration policies together. Requiring phishing-resistant MFA may not be sufficient if an attacker can invoke an enrolled key from a compromised session and then use the resulting token to establish a new device identity.

Security teams should monitor for Windows Hello for Business authentications without a device ID, unexpected device registrations, new passkeys added shortly after an unusual sign-in and authentication events inconsistent with the user’s normal device and location. Device-compliance requirements and restrictions on who can register or join devices can reduce the viability of persistence chains.

Services implementing WebAuthn should explicitly require user verification where appropriate and confirm on the server that the returned assertion has the user-verification flag set. Merely requesting verification through the browser is not enough.

Endpoint security controls should regard passkey state files, browser synchronisation databases, credential-manager recovery flows and browser memory as highly sensitive. Application isolation, process-access restrictions and behavioural detection for unauthorised memory access become more important when a browser temporarily handles secrets capable of decrypting an entire credential collection.

Credential-manager providers, meanwhile, face a deeper architectural challenge. Hardware-backed keys provide limited protection if untrusted processes can freely request signatures. Cloud authenticators should validate the attestation of replacement keys, recovery should re-establish user intent through a separate trusted channel, and master secrets should not be exposed to ordinary client memory where endpoint malware can collect them.

The central lesson is not that passkeys have failed. It is that strong cryptography cannot compensate for every weakness in the surrounding system.

Passkeys remove the reusable secret that made passwords so easy to phish and replay. But authentication still depends on operating systems, browsers, cloud infrastructure, recovery mechanisms and live user sessions. The latest research shows that attackers are already shifting their attention to those layers—and that organisations adopting passkeys must secure the entire authentication chain, not only the key at its centre.