Michael Grafnetter's Black Hat USA 2026 research and the Pass-the-Passkey paper show that WebAuthn's cryptography did not break. The implementations did. Entra passkeys resist phishing at the moment of login. That is not the same as being phishing-proof.
Two MFA 2.0 controls answer this family. The first is how the login challenge is bound and discarded. That is why none of Group 1 reaches MFA 2.0. The second is certificate binding enforcement, which stops an attacker working from their own machine. That is the RDP case in Group 3.
The sixteen techniques assessed here are not equivalent, and treating them as one list is what makes the research hard to act on. Some are failures of the identity provider. Some are questions of credential policy. Six need the attacker's code on the victim's PC, and no identity provider can prevent those. Microsoft patched two of the sixteen and classified the rest as by-design. This post separates them into three groups, because the answer to "are we exposed?" is different in each.
| Group | Attacks | Who owns the control |
|---|---|---|
| 1. Identity provider | 6 | How the IdP issues, binds, and discards a challenge |
| 2. Passkey misuse | 3 | Enrolment policy and what happens after a successful login |
| 3. Malware on the box | 7 | Infection, except RDP, which CBE stops off-box |
Group 1: Attacks on the identity provider
These six are the identity provider's job. The outcome depends on how it issues, binds and verifies a WebAuthn challenge. Entra was vulnerable to all six. Microsoft patched two: the event-log leak and the user-verification flag. The other four are product choices rather than bugs. Entra challenges are short-lived JWTs, so they are neither tied to a session nor discarded once used.
MFA 2.0 was never exposed, because it does both. Each challenge is bound to the device and user session that started it, and discarded the moment it is used.
Assertion Mining
Windows wrote usable WebAuthn assertions into the event log. Unprivileged accounts could read them, including over the network in some group-membership cases. Microsoft closed this on 14 July 2026 as CVE-2026-34348. Signatures in the log are now truncated. Even without the patch, a mined assertion still cannot complete an MFA 2.0 login, because the challenge is bound to the session that requested it, and the attacker is not in that session. On unpatched machines the log can still contain an assertion for any relying party, MFA 2.0 included. What differs is that it cannot be used against MFA 2.0.
Replay
Entra challenges remain short-lived JWTs. They are not bound to the device and user session, and are not discarded on first use. Since May 2026 Entra tracks signature counters for some hardware authenticators, but Windows Hello still reports a signature counter of 0, so a captured Hello assertion can be presented again. Microsoft treats that as design, not a CVE. SpecterOps now regards the full Windows-to-Entra chain it originally demoed as broken after the July log patch, and has not retested Entra's JWT behaviour since June. The Entra-side gap is unchanged. MFA 2.0 binds the challenge to the device and user session, checks it, then discards it the moment it is used. A second submission has nothing to match.
Circuit Breaker
Malware pauses the browser and steals the assertion mid-ceremony. Microsoft will not treat that intercept as a product bug. The real gap was Entra accepting the stolen assertion in another session. An assertion can only complete the session that holds its challenge. Another host fails even if the signature is valid.
Detour Capture
The paper treats Detour as one technique with three modes. Capture and Replay belong here. Inject belongs in Group 3. Capture hooks webauthn.dll and takes the assertion off the box. Microsoft will not patch user-mode API hooking. Off-box replay only worked because Entra accepted the stolen assertion. A hook can still see a signature. The operator has no session to replay it into.
Detour Replay
This uses the same hook. The dual-login trick needed Entra to leave the challenge alive after first use. Microsoft left that as design. MFA 2.0 discards the challenge the moment it is used, so a replay has nothing to bind to.
User Verification Bypass
Entra historically ignored authenticator user-verification flags. That was a relying-party bug, now patched. It was not a Windows Hello CVE. MFA 2.0 login has always required user verification and validates the flag on every assertion. Removing the flag does not weaken the login. It fails it.
Group 2: Passkey misuse
These three happen either side of the login, not during it. Two are how an attacker gets a passkey that keeps working. One is how a captured Entra passkey assertion is turned into Microsoft tokens. Microsoft classifies all three as product features. None of them depend on the identity provider checking an assertion correctly, which is why the answers here look different from Group 1. None of them reach MFA 2.0 either, for three separate reasons.
Software Authenticators
Synced and exportable passkeys are an intentional FIDO and Microsoft direction. Device-bound versus syncable is a tenant policy choice. Microsoft will not ban vault export in a security update. MFA 2.0 enrolment asks for a platform authenticator, so on Windows the key is created in Windows Hello and held by the TPM. There is no exportable copy for a password manager to lift.
Shadow Passkey
Administrative FIDO registration through Microsoft Graph is an Entra feature so IT can pre-enrol keys. Microsoft will not remove it. Graph cannot write an MFA 2.0 credential. There is no equivalent API either: no administrative endpoint registers a passkey on someone else's behalf, and enrolment happens on the device that holds the key. That is the zero-knowledge enrolment rule, not an admin convenience.
Passkey to Token
The technique is redeeming a captured Entra passkey assertion at Entra for ESTS cookies, then exchanging those for access and refresh tokens through a known public client. It is not a passkey ceremony bug, and Microsoft will not stop issuing tokens for a login it has accepted. TokenTactics-style exchange is an Entra-native shortcut. Once the domain is federated to MFA 2.0, or MFA 2.0 is the External MFA provider, that shortcut has nothing to run against: an MFA 2.0 assertion is signed for MFA 2.0's relying-party identifier, origin and challenge, so Microsoft will not honour it. Ordinary SAML and OIDC tokens after a successful login are federation working as designed, and Entra still issues its own session once it accepts that federated result, as it does after any sign-in it accepts.
Group 3: Malware on the box, and one RDP exception
Six of these require the attacker's malicious code on the victim PC. Past that point the machine is theirs. The session cookie can be taken. No passkey, no certificate, no MFA is involved. Entra, Okta, Ping, and MFA 2.0 are the same here. An identity provider that claims otherwise should not be believed on anything else it says. The infection is the finding. Patch management, application control, and EDR sit upstream. Login design does not substitute.
The seventh is different. RDP Passkey Phishing runs from the attacker's own host. Certificate binding enforcement is the control that answers that case.
UI Overlay
Windows already allows one ceremony at a time. Waiting for it to finish, then showing a rogue prompt, remains allowed. Fake dialogs sit in the OS interface trust model. Microsoft left this as design. It does not log anyone in by itself. UI Overlay, HWND Spoofing, and Metadata Spoofing dress Assertion Phishing, Prompt Flooding, and Detour Inject.
HWND Spoofing
Windows does not validate that the caller owns the parent window handle it supplies. MSRC assessed case VULN-185216 in June 2026 as Low / defence in depth and closed it. Microsoft will not fix it. It is a costume, not a login.
Metadata Spoofing
"Requested by…" text comes from the EXE version resource. Microsoft did not treat spoofing that string as a vulnerability. Older Windows 11 builds used the digital signature instead; that check was dropped on purpose. It is a costume, not a login.
Assertion Phishing
Any Windows application may call WebAuthNAuthenticatorGetAssertion. Microsoft will not stop third-party code from requesting a passkey. This is the same class as a push prompt: the OS prompts when it is asked to. It needs malware on the box.
Prompt Flooding
Windows will not rate-limit repeated WebAuthn prompts from an application. Microsoft declined to treat prompt spam as a product bug. It is the same class as MFA fatigue, except that the caller is already local.
Detour Inject
This is the third Detour mode. An in-process hook of webauthn.dll swaps the challenge inside a live session on the user's machine. Capture and Replay are Group 1. Inject is on-box. Microsoft will not patch user-mode hooking.
RDP Passkey Phishing
WebAuthn pass-through is documented in [MS-RDPEWA] and on by default. The user is lured into Remote Desktop on a host the attacker controls. Windows relays the passkey prompt back to the local machine. Microsoft will not disable pass-through in a security update. Administrators can turn it off in the RDP client. That is operational, not a CVE.
This is the only attack in Group 3 launched from the attacker's own machine rather than the victim's. With certificate binding enforcement on, that host presents no matching client certificate, so it never obtains a challenge. Disabling RDP WebAuthn pass-through closes it at the endpoint as well.
The boundary is simple. Malware on the victim's PC defeats every identity provider. From their own machine, an attacker never reaches the login to get a challenge.
If you want the control-side walkthrough of phishing-proof, device-bound authentication, start at prevention, not detection. For a conversation with IDEE, use Book Demo.
FAQ
Are all sixteen Pass-the-Passkey techniques the same bug?
No. Six attack how the identity provider binds and discards a challenge. Three are enrolment policy and redeeming a captured Entra assertion for tokens. Six need malware on the victim PC. RDP Passkey Phishing is the one Group 3 path that runs from the attacker's machine, and certificate binding enforcement stops that host from receiving a challenge.
Did Microsoft patch Pass-the-Passkey?
Microsoft patched two Group 1 issues: the event-log assertion leak as CVE-2026-34348 on 14 July 2026, and the user-verification flag on the relying party. Replay, Circuit Breaker, Detour Capture, and Detour Replay remain by-design on Entra. Nothing in Group 2 or Group 3 was closed as a product bug.
Would phishing-proof MFA 2.0 have stopped the Entra replay chain?
For Group 1, yes. MFA 2.0 binds the challenge to the device and user session, accepts it once, then discards it. A signature from an event log or a webauthn.dll hook has nowhere to be replayed. That is phishing-proof session binding, not merely phishing-resistant login. It does not stop cookie theft after malware already runs on the enrolled PC.
Why does RDP sit with malware if CBE stops it?
RDP Passkey Phishing is in Group 3 because SpecterOps listed it with the Windows WebAuthn-abuse family. It is not infection. The attacker stands on their own host and lets Windows relay the prompt. With certificate binding enforcement on, that host has no client certificate, so the login cannot be initiated. The six infection techniques remain endpoint problems.
Where is the primary research?
The overview is at specterops.io/passkeys. Tools are on GitHub under SpecterOps/pass-the-passkey. Grafnetter presented the family at Black Hat USA on 5 August 2026.
