New Passkey Attacks Explained: What Security Researchers Found This August

Every August, Black Hat and DEF CON turn Las Vegas into what security people only half jokingly call hacker summer camp. This year the nickname earned itself twice over. This week a Delta flight out of Las Vegas landed under investigation for an unauthorized Wi-Fi network onboard, reportedly the work of DEF CON attendees testing gear at 30,000 feet. Delta says no actual aircraft system was compromised, but the timing made it a fitting mascot for the week's real headline.

Black Hat USA 2026 ran the same week, and SpecterOps used it to present new passkey research. Two more findings, against Google Password Manager and Windows Hello for Business, surfaced in that same stretch of days. Passkeys have had two years of vendor messaging calling them phishing resistant and effectively unbreakable, and that kind of claim, at that kind of scale, is exactly what a room full of the industry's best offensive researchers shows up to test. Together, the three findings amount to the most serious stress test passkeys have faced since enterprises started deploying them at scale.

What is Pass-the-Passkey, and who does it affect?

Pass-the-Passkey is the name SpecterOps gave the research it presented at Black Hat USA 2026, covering three core vulnerabilities and more than 20 distinct techniques spanning Windows 11, Microsoft Entra ID, browsers, and password managers. Every technique in the set shares the same insight: you don't need to break a passkey's private key if you can abuse the systems that log, validate, or relay its use.

The primary exploit chain works like this. Windows 11's platform authenticator wrote complete, un-truncated WebAuthn assertions, including cryptographic signatures and authenticator data, directly into the Windows Event Log. Anyone with local or delegated access to a shared or compromised endpoint could harvest that log data. On its own, that's a local information disclosure issue. Chained with Microsoft Entra ID's server-side validation, it becomes something worse: Entra ID wasn't verifying challenge uniqueness, wasn't binding challenges to individual sessions, and wasn't tracking signature counter increments. Combine the two, and an attacker who harvested a logged assertion from a compromised workstation could replay it to impersonate a privileged cloud administrator, while the login still technically satisfied phishing-resistant MFA policy.

Microsoft patched the Windows logging component on July 14, 2026 (CVE-2026-34348), truncating logged signatures to six bytes so they can't be replayed. The Entra ID validation gaps, challenge uniqueness, session binding, and counter tracking, are still open as of this writing.

Beyond replay, SpecterOps also documented techniques that don't need a harvested assertion at all: malware hooking the local WebAuthn API to flood users with credential prompts until they approve one out of fatigue, spoof legitimate enterprise applications, tunnel passkey requests across active RDP sessions, or overlay fake UI on top of the real Windows credential prompt. SpecterOps released open-source tooling on GitHub for defenders to test their own environments against these techniques.

Who's exposed: any organization running Windows 11 endpoints with WebAuthn or passkey authentication enabled, any organization using Microsoft Entra ID as its cloud identity provider, and specifically, any organization where privileged administrators authenticate from workstations that are shared, remotely accessed, or otherwise reachable by an attacker with local code execution.

What other passkey security research surfaced the same week?

Two more findings landed in that same stretch of days and widen the exposure further.

In a Unit 42 blog post published August 3, Palo Alto Networks researchers disclosed a separate attack family they call Pass-ta-key, three variants (Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key) targeting Google Password Manager's synced passkeys in Chrome. The most severe variant, Golden Pass-ta-key, recovers the security domain secret, the single 32-byte master key protecting every synced passkey in a Chrome account, straight out of Chrome's process memory. Google has no way to rotate or revoke that secret once exposed. That affects any organization or individual relying on Chrome's synced passkey storage.

In his own writeup published the same week, independent Entra ID researcher Dirk-jan Mollema showed that malware inside an already-signed-in Windows session can use a hardware-bound Windows Hello for Business key without a fresh PIN or biometric. That affects any organization treating an unlocked session as sufficient proof of identity for sensitive actions.

How does HYPR's architecture address these same failure points?

The Pass-the-Passkey exploit chain lives inside two Microsoft-specific components: Windows 11's platform authenticator logging and Entra ID's server-side validation. Read alongside the Unit 42 and Mollema findings, the three attacks point at the same underlying pattern: key custody and replay validation treated as afterthoughts rather than foundational design constraints.

Three architectural decisions separate that pattern from how HYPR is built.

Key custody, decentralized from the start. Golden Pass-ta-key's core vulnerability is a direct consequence of centralizing key material behind one recoverable secret, the security domain secret. HYPR's key management model distributes private keys across user devices, with no equivalent master secret for an attacker to extract. That's a structural property of how keys are generated and stored, present from the initial design rather than added after the fact.

Replay validation, enforced as a baseline requirement. Entra ID's gap was a validation step the implementation left unenforced: challenge uniqueness, session binding, and signature counter tracking.

Identity assurance, continuous rather than decided once. Mollema's finding exposed the deeper limitation of session-based trust: once authenticated, nothing re-checks who's behind the keyboard. HYPR Affirm inserts identity verification at the specific moments where risk concentrates, recovery, device replacement, privileged access changes, help desk resets, so authentication becomes a decision the system can make again when it matters most.

Most enterprises run mixed environments. If your organization uses HYPR for some applications and Windows Hello for Business or Entra ID passkeys for others, those other paths carry the exposure this research describes regardless of how HYPR is configured. Patch CVE-2026-34348 on every Windows 11 endpoint and check your Entra ID configuration either way.

What single assumption made all three passkey attacks possible?

Every one of these attacks exploited the same assumption: that a trusted session, a trusted device, or a trusted sync mechanism can stand in for a verified identity.

That assumption is baked into how most passkey deployments work today. Authenticate once, and the system trusts everything that happens in that session, on that device, through that sync relationship, for as long as it's technically valid. Nobody re-checks who's actually behind the keyboard.

Passkeys solved phishing. Session compromise, credential custody, and insider misuse are identity problems, and a stronger credential alone can't fix them. Swapping a password for a key pair doesn't change who's allowed to use it.

Why do these passkey attacks matter for Microsoft Entra ID users?

Starting September 1, 2026, every Entra ID user currently on SMS or voice MFA gets automatically enabled for passkeys and nudged to register one. Microsoft-provided SMS and voice authentication retires entirely on February 1, 2027.

Retiring SMS and voice is the right call. Both have been the weakest link in MFA for years, and phasing them out closes a real gap. But the timing puts millions of Entra identities on the exact architecture this month's research just spent a week taking apart, right as attackers walk away with working technical detail on how to get around it.

Speed of adoption without a plan for the gaps it inherits is how "we deployed phishing-resistant MFA" turns into next year's incident report.

What should security teams do about these passkey attacks?

• Patch CVE-2026-34348 now. This is the one concrete fix available today.
• Enforce user-verification flags server-side. Unit 42's attack against eBay worked even though eBay's site required user verification. The server never actually checked the flag it asked for, and eBay has since fixed it.
• Treat passkey stores, recovery flows, and browser memory as credential-sensitive territory. They hold the keys. Defend them like it.
• Monitor for Windows Hello for Business authentications without a device identifier, and for unexpected device registrations on Entra.
• Stop treating "we deployed passkeys" as the finish line. A phishing-resistant credential issued to the wrong person, or borrowed from an already-compromised session, is still a compromise.

What security layer do these passkey attacks expose?

These three attacks required trusting the surrounding environment: a log file, a piece of memory, an open session. That's an architecture problem, and it shows up in two places.

First, custody. A single synced master secret that protects every passkey in an account, with no way to revoke it once exposed, is the same centralized-secret risk passwordless was supposed to eliminate. It just moved up a layer. Decentralized key management, where there's no master secret sitting anywhere for an attacker to find, closes that gap by design rather than by patch.

Second, verification. Strong authentication answers "is this a valid credential." It doesn't answer "is this still the right human, right now," especially once a session is already open. That's why identity verification can't just live at enrollment. It has to show up again at the moments that matter: recovery, device replacement, privileged access changes, help desk resets. That's the exact gap Mollema's research exposed, and it's what we built HYPR Affirm to close.

Authentication proves you have the key. Identity assurance proves you're still the person who should.

The bottom line

Passkeys resisted phishing exactly as designed. None of them were built to stop an attacker who was already inside the perimeter, the session, or the sync layer from acting like they belonged there.

This is an identity problem, and it's the one the industry keeps deferring until research like this makes it unavoidable.

Frequently Asked Questions 

What is Pass-the-Passkey?

The name SpecterOps gave the research it presented at Black Hat USA 2026, covering three core vulnerabilities and more than 20 techniques across Windows 11, Microsoft Entra ID, browsers, and password managers. Its primary chain combines Windows 11's WebAuthn assertion logging with gaps in Entra ID's replay validation.

Did these attacks break passkey cryptography?

No. All three exploited the infrastructure around passkeys: event logging, synced key storage, and live session trust. The underlying public-key cryptography held up in every case.

Should organizations pause passkey rollouts?

No. Patch CVE-2026-34348, enforce user-verification checks server-side, and add identity verification at high-risk moments like recovery and privileged access changes.

What is Golden Pass-ta-key?

Unit 42's attack that recovers the Security Domain Secret protecting synced passkeys in Google Password Manager, with no current way for Google to rotate or revoke that secret once exposed.

Related Reading

• Thwarting Bluekit Phishing-as-a-Service Attacks on Microsoft Authentication
• How to Prevent Helpdesk Social Engineering Attacks
• HYPR Affirm: Automated Identity Verification Solution