Three weeks before Microsoft makes passkeys the default sign-in method for Entra ID, new research shows that the Windows dialog protecting them can be faked well enough to fool the people who build security products for a living — and that Microsoft has decided the underlying weakness isn't worth patching.
The finding comes from SpecterOps principal security researcher Michael Grafnetter, who presented Pass-the-Passkey Family of Attacks at Black Hat USA 2026 on August 5 and published a 72-page white paper alongside it.
The research documents three zero-days in Windows 11 and Microsoft Entra ID, more than 20 attack techniques, and a toolkit that SpecterOps has open-sourced so defenders and pentesters can reproduce the attacks.
Two of the three bugs have been fixed. The third has not, and it is arguably the one that matters most going forward.
The chain Microsoft closed
Grafnetter's team found that Windows 11 was writing complete WebAuthn assertions — the signed responses a passkey produces to prove who you are — into the Microsoft-Windows-WebAuthN/Operational event log in plaintext. Every field an attacker needs was there: challenge, authenticator data, signature, credential ID, and user handle.
Reading that log locally required nothing more than membership in the Users group. Remotely, membership in Event Log Readers, Remote Desktop Users, Remote Management Users, or Administrators was enough.
The logging applies to Windows Hello, YubiKeys, password-manager plugins, and phone-based hybrid flows alike. The only exceptions were private browsing sessions and password managers that autofill passkeys without touching the Windows API.
On its own, a leaked assertion is stale data. The second flaw made it live ammunition: Entra ID was not checking whether a challenge had already been used, was not binding challenges to a session, and was not tracking signature counters — three of the anti-replay checks the WebAuthn Level 3 specification assigns to the relying party. Entra ID's challenges are short-lived signed JWTs valid for five minutes, but the service accepted them for roughly ten.
Put together, a low-privileged user on a shared or managed machine could lift a Global Administrator's assertion out of the event log and replay it, satisfying the phishing-resistant MFA requirement in Conditional Access along the way. In testing against Microsoft 365 E5 tenants with Entra Identity Protection and Defender for Identity enabled, the researchers saw no alerts at all.
Microsoft patched the Windows side on July 14 as CVE-2026-34348, truncating the logged signature to six bytes so the events remain useful for debugging but useless for replay. It classified the issue as information disclosure at CVSS 6.5; SpecterOps had filed it as privilege escalation at 8.6.
The cloud fix arrived quietly in May — Grafnetter says he only noticed it while recording demos for the conference. Notably, that fix covers FIDO2 security keys, not Windows Hello on Entra-registered devices, which still reports a signature counter of zero.
The one that stayed open
The unpatched issue is smaller in scope and larger in practical consequence. The Win32 function WebAuthNAuthenticatorGetAssertion, documented in Microsoft's own header, takes a window handle (hWnd) that determines which application the credential dialog appears to belong to. Windows does not validate it. Malware can therefore render the "Sign in with a passkey" prompt as a modal child window of Microsoft Edge or Outlook — even when those apps are running under a different user account.
Pair that with a second trick from the paper: the publisher name shown in the prompt comes from the executable's version resource, which the attacker controls. Setting an assembly title of "Microsoft Edge" and an author of "Microsoft Corporation" produces a dialog that reads Requested by Microsoft Edge (Microsoft Corporation) — the exact string a cautious user would look for.
Because malware calling the API directly supplies its own origin, rather than having the browser fill it in from the page, it can request an assertion for any site it likes. Windows blocks two ceremonies at once, so overlaying a rogue prompt on a real one fails — but simply waiting for the legitimate login to finish and then prompting works fine, and a flooding mode re-prompts every couple of seconds until the challenge expires.
The paper is blunt about how effective this is, noting that colleagues admitted to confirming such prompts "reflexively," without checking what they were approving.
Microsoft's Security Response Center reviewed a proof of concept and closed the case on June 4 as low-severity "Defense in Depth." SpecterOps scored it 8.0 High.
Wider exposure
The white paper covers a lot more ground than the three CVE-class issues. Windows relays passkey prompts over RDP and Hyper-V enhanced sessions by default via MS-RDPEWA, so malware on a compromised jump host can raise a prompt on the administrator's own desktop.
Administrative passkey registration APIs in Microsoft Graph and Okta can be abused to plant a "shadow passkey" that survives a password reset. And synced passkeys are exportable in cleartext by design: KeePassXC writes .passkey files in the clear, Bitwarden's default JSON export is unencrypted, and the FIDO Alliance's Credential Exchange Format leaves transport protection to the provider. Any of those files is a working credential to anyone who finds it.
What to do now
Grafnetter is not telling anyone to abandon passkeys. "Passkeys are still a major improvement over passwords, but they are not magic," he told Dark Reading.
For IT administrators, the practical steps are: apply the July 2026 Windows updates; stop treating phishing-resistant MFA in Conditional Access as a sufficient control on its own; issue device-bound passkeys and enforce attestation for privileged accounts instead of synced ones; restrict remote event log access and use privileged access workstations for admin work; and audit passkey registrations through Graph and Okta APIs.
On the detection side, SpecterOps flags several signals worth hunting for: WebAuthn API calls from non-browser processes, unexpected reads of the WebAuthN operational log, enumeration of top-level window handles, and DLL injection into browsers. Any one of them is noisy on its own; correlated, they're a strong indicator.
For developers, the advice is simpler — bind challenges to sessions the way GitHub already does, enforce single-use challenges and signature counters, use a maintained WebAuthn SDK rather than rolling your own, and keep assertions out of your logs.
And for everyone else: if a passkey prompt appears when you weren't signing in to anything, cancel it. Twice, if you have to.