# Windows stores WebAuthn assertions in cleartext event logs

Source: https://startwithidentity.com/cves/cve-2026-34348/
Last updated: 2026-08-29
License: content by Start with Identity. Cite the source URL.

---

## What broke

Windows Event Logging wrote [WebAuthn](https://startwithidentity.com/glossary/webauthn/) assertion material in cleartext. An unprivileged local user, and in some configurations a remote reader of forwarded logs, could recover it. SpecterOps and Roman Grafnetter showed at Black Hat USA 2026 that the recovered assertion can be replayed against [Entra ID](https://startwithidentity.com/vendors/iam/microsoft-entra/) ("Pass-the-Passkey"). Microsoft patched in July 2026.

## Why it matters

Passkeys are supposed to be the phishing-resistant endgame. They fail if the platform logs the assertion the way it used to log passwords. This CVE does not break WebAuthn cryptography. It breaks the operating system's handling of the ceremony. Combine it with FIDO downgrade techniques (PoisonSeed / Proofpoint, no CVE) and you have the 2026 passkey lesson: the protocol can be fine and the surrounding telemetry still gives the attacker a replay.

## What to do

- Patch Windows for July 2026 on workstations and on any collector that stores forwarded Security / Operational logs.
- Treat WebAuthn debug logging as secret. Do not ship raw assertion bytes to a SIEM without redaction.
- Bind WebAuthn challenges to the session the way GitHub does, so a stolen assertion is useless elsewhere.
- Read the [WebAuthn / FIDO2 deep dive](https://startwithidentity.com/standards/webauthn-fido2/) and the [passkey](https://startwithidentity.com/glossary/passkey/) glossary entry before you brief this as "passkeys are broken." They are not. Logging is.

## After you patch

Flaws in the phishing-resistant layer are serious precisely because the resulting authentication satisfies your strongest policy.

- **Hunt for authentications with an empty device ID** or with no matching interactive session on the originating host, accepting that some legitimate traffic looks similar.
- **Review registered authenticators and devices** for enrolments you did not expect, which is the persistence step in this class.
- **Re-enrol credentials for privileged accounts** if assertion material may have been exposed, and prefer device-bound hardware authenticators for those users.
- **Verify server-side [user verification](https://startwithidentity.com/glossary/phishing-resistant-mfa/) checks**, since accepting an assertion with the flag unset removes the property you deployed passkeys for. See [WebAuthn and FIDO2](https://startwithidentity.com/standards/webauthn-fido2/).

## Sources

- [NVD: CVE-2026-34348](https://nvd.nist.gov/vuln/detail/CVE-2026-34348)
- SpecterOps / Grafnetter, Black Hat USA 2026, Pass-the-Passkey