For a window of several minutes, a genuine passkey sign-in to Microsoft Entra ID could be copied and replayed by anyone who could read the local Windows event log - no phishing link, no stolen private key, no password prompt. Security researcher Michael Grafnetter (Principal Security Researcher, SpecterOps) presented this as part of the "Pass-the-Passkey" research at Black Hat USA 2026, and it's tracked as CVE-2026-34348. This post covers what actually happened, why a hardware-backed credential was replayable at all, how to check your own devices, and what Microsoft's fix actually changed.
Windows 11 was logging the complete WebAuthn sign-in response - including the cryptographic signature - into the Microsoft-Windows-WebAuthN/Operational event log on every passkey sign-in. Anyone who could read that log (a member of Remote Desktop Users on a shared server, or malware quietly reading logs, which most EDR doesn't flag) could replay the signature to Entra ID and be treated as the user who just signed in - including if that user was a Global Administrator. No private keys were ever exposed; the TPM or security key never gave them up. What leaked was the short-lived signed proof those keys produced, and Entra ID didn't check whether it had already seen that exact proof before. Microsoft's July 2026 update truncates what gets logged, and Entra now checks authenticator signature counters to reject replays.
The problem: a sign-in event log that could be replayed as a login
When you sign in to Entra ID with a passkey - a YubiKey, or Windows Hello for Business - your authenticator produces a digital signature over a challenge Entra ID sent it. That signature is sent to Entra ID as proof you hold the private key, without the private key ever leaving the hardware. Windows was also writing that entire signed response - the full WebAuthn assertion, including the signature - into the Microsoft-Windows-WebAuthN/Operational event log.
Entra ID would accept a replay of that exact same signed response for several minutes after the original sign-in. So anyone who could read that event log during that window could resend the captured assertion and be authenticated as the user who had just signed in - no password, no MFA prompt, nothing that looked like an attack from Entra ID's side.
Why it happens: full assertions logged, no replay check on the server
This needed two separate gaps to line up, and either one alone would have made this a non-issue:
- Windows logged too much. The WebAuthn operational log is meant for diagnostics - confirming a sign-in happened, troubleshooting a failure. It didn't need to contain the actual signature to do that job, but it did.
- Entra ID didn't check for a repeat. WebAuthn's own design defends against exactly this with a signature counter - a number the authenticator increments on every use, which the server should reject if it doesn't increase. Entra ID wasn't enforcing that check, so a captured signature could be replayed as many times as an attacker liked within the acceptance window.
Reading an event log is not, on its own, something most endpoint security tools treat as suspicious - it's a completely normal administrative and diagnostic action. That's exactly what made this quietly exploitable: a member of Remote Desktop Users on a shared jump box, or malware already running as any authenticated user, could read the log without tripping an alert.
How to verify: check the log, check who can read it, check your build
Three things are worth checking on any device, none of which require you to read the log's actual (sensitive) content:
Then check who can actually read it - the real attack surface for this vulnerability is anyone in a group with local log-reading rights:
Get-LocalGroupMember -Group 'Administrators' can throw An unspecified error occurred: error code = 1789 on a domain-joined device where a domain security group is nested into the local Administrators group and the machine can't resolve that group's SID. This is a genuine, documented PowerShell limitation, not a sign anything is broken - fall back to net localgroup administrators, which handles this case correctly.Finally, confirm your build against Microsoft's own July 2026 security update guidance for CVE-2026-34348 - this is the authoritative check, not anything you can determine by parsing log content:
The fix: patch, and what changed on both sides
Context: this is a two-sided fix - one part Microsoft already shipped to your devices via Windows Update, one part Microsoft already shipped server-side to Entra ID itself. There's no admin-configurable setting to turn on; the work here is confirming your fleet is patched and understanding what changed.
- Windows-side (CVE-2026-34348): Microsoft's July 2026 Windows security updates truncate the signature portion of what gets written to
Microsoft-Windows-WebAuthN/Operationaldown to 6 bytes - enough to keep the log useful for diagnosing sign-in failures, not enough to replay. Confirm this update is deployed via your normal patch management tooling (Intune Update rings, WSUS, or ConfigMgr). - Entra ID-side: Microsoft has updated Entra ID to check the authenticator's signature counter and reject a replayed assertion, closing the server-side gap independently of whether every device is patched yet. This is a Microsoft-managed change - there's nothing for a tenant admin to configure.
Event ID catalog: Microsoft-Windows-WebAuthN/Operational
This log channel genuinely exists and is enabled by default on Windows 11 devices doing passkey/WHfB sign-ins. A real device in this series showed the following Event IDs occurring during normal passkey sign-in activity - useful for confirming the log is actively recording, without needing to inspect its sensitive content:
| Event ID | Level | Meaning |
|---|---|---|
| 1070 / 1071 | Information | WebAuthn authentication ceremony steps - request received and processed |
| 2000 / 2001 | Success | Assertion generation completed successfully - this is the step that (pre-patch) logged the full signature |
| 2100 / 2102 | Information / Success | Platform authenticator (Windows Hello) ceremony completion |
Proof it worked: confirming exposure safely, without ever reading sensitive content
Here is a real run of Test-WebAuthnLogExposure.ps1 from this series, against a genuine test device - it confirms the log exists, reports who can read it, and reports the build, without printing a single signature or assertion value:
Read this the way it's meant to be read: the log genuinely exists and has thousands of real entries (confirming it's actively logging passkey activity), a small, known set of accounts can read it on this device (the real, auditable blast radius), and the build number is what you'd cross-check against Microsoft's patch guidance - not something this script should guess at from log content it deliberately never touches.
References
- MSRC - CVE-2026-34348 Security Update Guide
- The Hacker News - New Passkey Attacks Can Recover Synced Private Keys or Bypass Phishing-Resistant MFA
- Cyber Security News - Pass-the-Passkey Attacks Expose Windows 11 and Microsoft Entra ID
- Microsoft Learn - Authentication strengths in Conditional Access (phishing-resistant MFA)
- Microsoft Learn - Windows WebAuthn API reference
Security researcher deep-dives
This research comes directly from the people who found it - both independently verified before citing here:
| Researcher | Source | What it adds |
|---|---|---|
| Michael Grafnetter (Principal Security Researcher, SpecterOps) | SpecterOps/pass-the-passkey on GitHub | The original Black Hat USA 2026 research - over 20 attack techniques across Windows 11, Entra ID, browsers, and password managers, of which the event log replay is one |
| Dirk-jan Mollema | Borrowing Windows Hello keys for authentication and persistence | A related, independent finding - Entra ID's WebAuthn challenge is itself a signed JWT valid for five minutes and not bound to a specific session, user, or tenant, which compounds the replay risk this post covers |
Script for this post is in Windows-Patching-Scripts.