Passkeys are sold on a specific promise: the private key never leaves the authenticator, so there is nothing for a phishing page to capture. That promise is about the credential. Three pieces of research published in early August 2026 go after everything around it — and one goes after the credential itself.
They are unrelated efforts by unrelated teams. That is the part worth noticing.
1. Pass-the-Passkey — SpecterOps
Michael Grafnetter, principal security researcher at SpecterOps, presented this at Black Hat USA on 5 August.
Windows stored YubiKey signatures in cleartext, in a location readable by unprivileged users. Those signatures were reused during Microsoft Entra ID passkey validation. An attacker who could read the event log could replay an assertion and satisfy a phishing-resistant MFA requirement without the key.
| Affected | Windows 10, Windows 11, Windows Server; Entra ID |
| CVE | CVE-2026-34348 — Windows Event Logging Service information disclosure, CVSS 6.5 |
| Fixed | July 2026 updates |
Microsoft's statement: "We have applied mitigations for the reported issue involving passkey relay assertions." The July updates make WebAuthn assertions in event logs unusable for replay.
CVSS 6.5 is a "medium". An information disclosure that yields an MFA bypass is not a medium in practice, and this is a good example of why severity scores and operational impact diverge.
2. Pass-ta-key — Unit 42
Unit 42 (Palo Alto Networks) published three variants against Google Password Manager's synced passkeys in Chrome on Windows.
- Signature without unlock. Abuses Chrome's device identity machinery to obtain signatures without the user unlocking anything.
- User-verification manipulation. Demonstrated against eBay.
- The Golden Pass-ta-key. Recovers the 32-byte Security Domain Secret — the master key — from Chrome process memory during re-registration. With it, the attacker recovers the victim's synced passkey private keys.
The third one is the outlier in this whole set. The other results defeat a check. This one takes the key.
And there is no rotation or revocation path for it. A stolen password gets changed. A stolen synced passkey private key, obtained through the master secret, does not have an equivalent remedy exposed to the user.
3. Windows Hello for Business — Dirk-jan Mollema
Independent researcher Dirk-jan Mollema showed that low-privilege processes inside a compromised user session can call Windows cryptographic interfaces to use the non-exportable Windows Hello for Business key — without a PIN or biometric prompt. The key then functions as a FIDO2 credential against Entra ID.
"Non-exportable" turns out to be a claim about extraction, not about use.
He also found that Entra WebAuthn challenges stay valid for five minutes and are not bound to session, user or tenant. A challenge can be generated on one system and answered on another. Tokens issued this way lack device ID claims.
No specific Microsoft statement accompanied this finding in the reporting.
The pattern across all three
| Research | What it defeats | What it does not defeat |
|---|---|---|
| Pass-the-Passkey | The MFA check | The key |
| Pass-ta-key (Golden) | The key itself | — |
| Windows Hello | The user-presence requirement | The key's storage |
Two of the three do not break WebAuthn. They break the plumbing around it — logging, challenge binding, process isolation — on a host the attacker already has a foothold on.
That precondition matters and should not be waved away. None of this is a remote phishing attack against a passkey. All of it assumes local presence.
But "assumes local presence" is precisely the scenario passkeys are often deployed to survive. The pitch for phishing-resistant MFA in an enterprise is that credential theft stops being catastrophic. If a compromised session yields a replayable assertion or a usable Hello key, the blast radius of that session is larger than the deployment assumed.
We covered the Teams vishing campaign that led to Chaos ransomware in under 17 hours in July. The route to a compromised session is not the hard part any more.
What to do about it now
- Take the July Windows updates if you have not. CVE-2026-34348 is fixed there.
- Audit who can read the security event log. The mitigation removed the usable assertions; the underlying "unprivileged users can read a lot" problem is a configuration question.
- Do not treat synced passkeys and hardware passkeys as the same control. The Golden Pass-ta-key result applies to the synced kind. For accounts where key recovery would be unrecoverable, that distinction is now load-bearing.
- Ask your IdP about challenge binding. Five minutes, unbound to session or tenant, is the detail that makes the Hello result portable across machines.
- Keep device ID claims in your conditional access policy — tokens generated through this path lack them, which makes it a detection opportunity rather than only a gap.
None of this makes passwords look better. Passkeys remain the stronger control. The correction is narrower: phishing-resistant is a statement about phishing, and these three results are not phishing.
