AxowlBlog
Identity Axowl

The passkeys held. The signals around them didn't.

Three August research releases defeated passkeys without breaking the cryptography. Each broke the plumbing around the key: logging, binding, and the audit trail.

Passkeys were supposed to be the end of the argument. Phishing-resistant, hardware-bound, no shared secret to steal — the credential the industry has spent five years telling everyone to adopt. In the first week of August, three separate research teams defeated them anyway.

None of the three broke the cryptography. The private keys stayed where they were, unexported, doing exactly what they were designed to do. What the researchers took apart was everything the key sits inside: where a signature gets written down, what a challenge is bound to, and whether the system can later tell a real authentication from a borrowed one.

That distinction is the whole story. When the math is sound and the account still falls, the failure has moved into identity, access, and the audit trail — which is the part most teams never instrumented, because the passkey was supposed to make it unnecessary.

The signature outlived the ceremony

SpecterOps found that Windows was writing complete WebAuthn assertion responses — cryptographic signatures and authenticator data — into the Windows Event Logging Service in cleartext, readable by an ordinary authenticated user. Microsoft tracks it as CVE-2026-34348, an information-disclosure flaw with a vendor CVSS of 6.5, patched on July 14.

Sit with what that log entry was. A passkey signature is the proof that a specific authenticator answered a specific challenge at a specific moment. The event log is meant to be the record of the ceremony — the thing you read afterward to reconstruct what happened. Here the record was the exposure. The artifact that proved the login also enabled the next one, because it was durable, replayable, and sitting in a place the security model treated as inert. Logging is supposed to be write-only witness. This was a log that handed back live credentials to anyone allowed to read it.

A challenge bound to nothing

Dirk-jan Mollema’s research on Windows Hello for Business turns on a smaller, sharper detail: the Entra ID sign-in challenge is valid for five minutes and, in his words, “not bound to a session, a user or even a tenant.” Malware already inside a signed-in session can invoke the hardware-bound key through the CNG interface without triggering a fresh PIN or biometric prompt, and answer a challenge the attacker requested from their own machine.

The credential never leaves the victim’s laptop. The approval it produces does. And because Windows Hello counts as phishing-resistant, that approval satisfies Conditional Access policies demanding strong MFA — and counts as fresh MFA, enough to register a new device and add another authentication method. The resulting token can arrive without a device ID claim, because the sign-in never carried the victim device’s normal registration state.

This is the approval-versus-presence gap in its purest form. The policy asked “did a phishing-resistant factor sign this,” got yes, and never asked the question that mattered: is the thing holding this key the same thing that requested the challenge. A five-minute window unbound to anything is an approval with no subject.

The record can’t tell the copies apart

Unit 42’s Pass-ta-key work is the one that should worry auditors most. Malware on a Windows machine can recover the Security Domain Secret — a 32-byte master key that encrypts every passkey synced through Google Password Manager — from Chrome’s process memory. There is, per the research, no way to rotate or revoke it: every current and future synced passkey stays protected by the same compromised key.

But the detail that matters for the audit trail is quieter. Synced passkeys report a constant signCount. That counter exists precisely so a relying party can notice a cloned authenticator — two copies of the same key drift out of sync, and the mismatch is the tell. Freeze it at a constant and you have removed the one signal that distinguishes an original from a copy. The stolen passkey and the real one produce identical, unremarkable authentications. The log shows a valid sign-in every time, because from the record’s point of view there is nothing to see.

Across all three, the same shape: the credential is fine, and the account is gone, because the surrounding system either wrote the proof somewhere reusable, approved without checking who was present, or lost the ability to tell a legitimate use from a replay.

What to check on Monday

None of this requires abandoning passkeys — they remain the strongest login primitive available. It requires not confusing “phishing-resistant credential” with “trustworthy record of what that credential did.”

  • Does a passkey or WebAuthn sign-in ever satisfy MFA on your side without a device ID claim? Can you write a query that finds those, the way Mollema’s detection isolates Windows Hello sign-ins where the device ID is empty?
  • Are you patched for CVE-2026-34348, and do you know what else your platform writes into event logs at authentication time? Assume any assertion material in a log is reusable.
  • Do you record and alert on signCount regressions or a frozen counter, or does your relying party ignore the field entirely?
  • When a new device or authentication method is added off the back of a fresh-MFA claim, is that enrollment a reviewable, sealed event — or just another row that dissolves into the sign-in logs?
  • If two machines presented the same passkey an hour apart, would anything in your telemetry notice, or would both simply read as valid?

The passkey is doing its job. The question these three attacks force is whether your audit trail is doing its own — whether, after the fact, your logs can prove which authentication was really the account holder, or only that the signature verified.

Sources

Axowl builds identity and audit infrastructure where a sign-in leaves a record the account holder can’t later dispute and an attacker can’t quietly forge. How it works.

#passkeys #webauthn #entra-id #audit-trail