Passkeys are designed to replace reusable passwords and make phishing far less effective. But new research shows a worrying pattern: passkey attacks can succeed without breaking the underlying cryptography. Instead, the studies focused on the “surrounding controls” where authentication material is stored, validated, or reused.
Three separate teams published findings last week that, taken together, illustrate different ways attackers may recover sensitive authentication material or bypass phishing-resistant MFA protections. The work does not claim a single universal flaw; it highlights multiple implementation and validation weaknesses across Windows, cloud identity checks, and synced passkey storage.
How passkey defenses can fail without cracking cryptography
Passkeys rely on strong cryptographic mechanisms, but the overall login flow depends on how systems handle signed assertions, device-bound secrets, and user-verification signals. If an attacker can reuse valid authentication data or obtain sensitive key material through implementation details, the math may remain intact while the security outcome changes.
In all three research efforts, the dangerous inputs were not created by “breaking” the passkey scheme itself. Rather, the attackers leveraged conditions like previously generated signatures kept by Windows, malware-assisted access to browser or session memory, and cloud challenge behaviors that allowed signatures to be accepted outside their expected context.
SpecterOps: Windows signature reuse and Entra impersonation
SpecterOps presented a Pass-the-Passkey study at Black Hat USA 2026. The core idea is that Windows stored previously created YubiKey signatures in a readable form in certain circumstances. According to the researchers, authenticated users without elevated privileges—including remote users—could access these stored signatures, which then became building blocks for further abuse.
By chaining those signatures with weaknesses in how Microsoft Entra ID validated passkey-related authentication, the team claims it was possible to impersonate privileged users even when policies required phishing-resistant MFA. Importantly, this approach did not involve extracting a passkey authenticator’s private key from the YubiKey.
The Windows component is tracked under CVE-2026-34348, described as an information-disclosure vulnerability in the Windows Event Logging Service. Microsoft’s affected product scope spans Windows 10, Windows 11, and Windows Server releases. However, the scope stated for the CVE does not automatically prove that the full passkey attack chain behaves identically across every listed Windows release.
From a defender’s perspective, this matters because it implies a narrower failure than “breaking FIDO2,” yet it can still deliver the outcome defenders fear: an attacker authenticating as someone else.
Unit 42: Recovering synced passkey private keys via Chrome
Unit 42’s research targets the synced-passkey system in Chrome on Windows, specifically in the context of Google Password Manager. Their key message is that passkey attacks can work by abusing how a client device is identified and how synced passkeys are protected in browser-related components—without requiring an administrator-level privilege escalation.
All described attack paths begin with malware already present on the victim’s endpoint. From there, the researchers explored multiple routes to obtain the signatures and trust context needed to act as a legitimate client for synced authentication.
Abusing device identity and user-verification handling
The team describes a path that abuses Chrome’s device identity mechanics to generate the signatures needed to behave like an expected Google Password Manager client. This route does not require a fresh device unlock or additional user interaction.
Unit 42 reports that they demonstrated the technique against eBay even though the site requested user verification. After the report, eBay adjusted how it validates the WebAuthn user-verification flag—an example of how downstream relying parties can influence the practical impact of an authentication weakness.
Golden Passkey: targeting the synced-passkey master key
The most damaging variant is named Golden Pass-ta-key. Rather than focusing only on signature handling, it targets a master secret used to protect synced passkeys: the Security Domain Secret, a 32-byte value.
Unit 42 initially found this secret exposed in Chrome device logging. Google removed it from that logging output after the report. However, the researchers state the secret is still temporarily present in Chrome process memory during passkey re-registration.
With access to that secret, an attacker can recover the victim’s synced passkey private keys. The researchers also note that the current implementation provides no way to rotate or revoke the Security Domain Secret. That limitation could make compromises more persistent than a one-time captured login.
Dirk-jan Mollema: Borrowing Windows Hello without a new unlock
Independent researcher Dirk-jan Mollema investigated Windows Hello for Business. On modern Windows systems, the backing key is protected by the Trusted Platform Module (TPM) and cannot simply be exported. Still, Mollema found that software running within an already compromised user session can call Windows cryptographic interfaces to use that hardware-bound key.
Crucially, the process can do this without triggering a new PIN entry or a new biometric prompt. After acquiring the ability to use the Windows Hello for Business key, the attacker used it to produce a FIDO2 credential for Microsoft Entra ID.
Challenge validity enables cross-system reuse
Mollema also reports that the Entra WebAuthn challenge is valid for about five minutes and is not bound to a specific session, user, or tenant. In practical terms, a challenge requested by an attacker system can be moved to the victim’s machine, signed there using the Windows Hello key, and returned as a WebAuthn assertion.
If successful, the authentication can satisfy Conditional Access rules that require phishing-resistant authentication. Mollema further found that the resulting token might lack a device identifier claim. That creates another possible path: device registration leading to token refresh mechanisms that extend persistence.
Different failures, different impacts
One risk in security reporting is treating separate findings as the same underlying problem. The research teams’ approaches differ enough that passkey attacks should not be collapsed into a single “replay bug” narrative.
SpecterOps emphasizes reusable signed assertions exposed by Windows and accepted through a cloud authentication path. Unit 42 focuses on malware-assisted manipulation of client trust, user-verification handling, synced-key exposure, and recovery of private keys. Mollema’s work starts from software already inside a live Windows user session and demonstrates how legitimate hardware-bound keys can be used to create fresh authentication material.
The starting conditions matter. Unit 42 and Mollema both rely on an already compromised endpoint or session. That suggests these findings show what passkeys may not fully contain after endpoint compromise, rather than proving that passkeys can be defeated from a fully unauthenticated remote position.
What to do now: fixes, monitoring, and design choices
Mitigations vary by environment, and the studies highlight several concrete defensive actions.
For Windows: apply the relevant security update
Microsoft’s immediate guidance for SpecterOps’ reported issue is to install the applicable security update for CVE-2026-34348. Microsoft also indicates it has applied mitigations related to a separate issue involving passkey relay assertions.
From a security operations viewpoint, organizations should treat passkey-related storage, recovery workflows, and browser memory as sensitive credential territory—because the research shows attackers can turn stored or temporary data into usable authentication material once the endpoint is compromised.
For Entra ID: enforce and observe stronger context binding
Entra-side defenders can focus on detection and policy enforcement. The research suggests that implementations allowing authentication assertions or tokens to be accepted without the expected device context can increase risk. Monitoring unusual Windows Hello for Business authentications—such as events missing a device identifier or unexpected device registrations—may help identify exploitation attempts.
Microsoft also reiterated a broader stance: adopt a least-privilege approach, use phishing-resistant authentication methods, and maintain endpoint defenses through a Zero Trust model. The spokesperson emphasized continued investment across authentication methods.
For browser and synced passkeys: assume endpoint compromise changes the game
Unit 42’s findings are a reminder that synced passkeys can expose new risk surfaces. While the underlying cryptography is strong, browser components and key-handling paths can create temporary exposure windows or unrecoverable secrets.
Because the Security Domain Secret reportedly has no rotation or revocation mechanism in the studied implementation, organizations may want to review how they protect endpoints, restrict malware execution, and limit the consequences of credential theft from a compromised host.
The broader lesson: no single choice fixes everything
The research collectively challenges the idea that selecting between synced and device-bound passkeys automatically closes the entire attack surface. The overlap across findings is real enough to compare techniques, but the underlying weaknesses appear to live in different places—Windows logging and assertion validation, Chrome synced-key handling, and Windows Hello for Business challenge binding and token content.
In other words, strong cryptography matters, but the security outcome also depends on implementation details and how systems enforce user verification and context. As attackers keep finding ways to reuse or relocate valid authentication artifacts, organizations need both timely patching and practical detection for suspicious authentication flows.
Looking ahead, this also affects deployment priorities: if passkeys become widely enabled, teams must ensure their identity providers, relying parties, and endpoints all enforce the same user-verification intent and device context consistently.
Starting September 1, 2026, Microsoft indicated that Entra ID users enabled for SMS or voice authentication will be automatically enabled for passkeys and prompted to register them. SMS and voice delivery is scheduled to retire on February 1, 2027. With that timeline, strengthening implementation details and monitoring becomes even more urgent.
Conclusion
These passkey attacks demonstrate that defenders cannot rely solely on cryptography to guarantee safety. SpecterOps, Unit 42, and Mollema each showed different ways attackers can produce harmful authentication outcomes—through reused signed material, recovery of synced private keys, or using Windows Hello keys without a fresh unlock. The common thread is not “breaking passkeys,” but exploiting weaknesses around authentication validation, key handling, and context binding.
The practical takeaway is clear: patch the identified Windows issue, harden endpoints against malware, enforce expected user-verification requirements in relying parties, and watch for authentication patterns that deviate from normal device and token behavior. When passkeys scale, implementation consistency and endpoint security will determine whether the promised phishing resistance holds in real-world deployments.
Source: https://thehackernews.com/2026/08/new-passkey-attacks-can-recover-synced.html
