Passkey Attacks Bypass MFA Without Breaking Cryptography

Passkeys were supposed to end this category of attack. The cryptography behind them still works exactly as designed. Three separate attacks disclosed this month reach past it anyway.

None of them factor a key or forge a signature. They read a log file, scrape process memory, and reuse a session that was already open.

What are the 2026 passkey attacks? Three implementation flaws disclosed around Black Hat USA 2026 that defeat passkey authentication without breaking its cryptography. One replays signatures Windows wrote into event logs, one extracts synced private keys from Chrome memory, and one reuses Windows Hello keys inside an already-compromised session.

Windows Wrote The Signatures Into A Log File

Windows 11 recorded complete, untruncated WebAuthn assertion responses in its event logs. The signature proving a passkey authentication happened sat there in readable form.

An attacker with local access can pull those assertions out of Event Viewer and replay them. No private key extraction is required, because the key never needs to leave the authenticator for this to work.

Microsoft Entra ID is what made the replay practical. It did not verify that each challenge was unique, did not bind challenges to a session, and did not track the authenticator’s signature counter. Those three omissions turn a logged signature into a working credential.

The result satisfied phishing-resistant MFA policy while granting access to privileged cloud accounts.

CVE-2026-34348 carries a CVSS 6.5 rating and was fixed in the July 14, 2026 security release. Patched systems truncate the logged signature field to six bytes, which preserves its diagnostic value and removes the replay.

What a Passkey Actually Is, and Why It Became Worth Attacking

Malware Can Lift The Master Key From Chrome Memory

The second attack targets synced passkeys in Google Password Manager on Windows.

Synced passkeys are protected by a 32-byte Security Domain Secret. Malware already running on the endpoint can read that value out of Chrome process memory during passkey re-registration. With it, an attacker recovers the private keys for every synced passkey tied to the account.

Google removed the secret from device logging after disclosure. The harder problem remains unsolved. There is no mechanism to rotate or revoke that secret. A stolen password can be changed. This cannot.

A Live Session Is Enough For Windows Hello

The third attack needs no key material at all.

Windows Hello for Business binds credentials to hardware, which is meant to make theft pointless. Inside an already-compromised Windows session, low-privilege software can invoke those hardware-bound keys without triggering a PIN or biometric prompt. It then produces valid WebAuthn assertions against Entra ID.

Two design details deepen the problem. Entra’s WebAuthn challenges stay valid for five minutes and are not bound to a session, user, or tenant. Tokens produced this way can also lack device ID claims, opening a route to Primary Refresh Token acquisition and durable persistence.

Nothing Cryptographic Failed

Passkey cryptography held in every case. What failed was the plumbing around it, a logging decision, a memory boundary, a session assumption.

That distinction shapes the correct response. “Passkeys are broken” is the wrong reading and leads somewhere unhelpful. The accurate reading is narrower and less comfortable. Phishing resistance removes one attack path, and leaves the endpoint exactly as important as it was before.

Two of the three attacks require unauthorized code already executing on the machine. Neither works against an attacker who cannot get a process running locally. This is where execution governance and identity control stop being separate conversations. The strongest authentication available is still issued to whatever happens to be running on that endpoint.

We covered the other side of this in early August, when a phishing service captured valid Microsoft 365 session tokens after MFA had already succeeded. Passkeys are the standard answer to that attack. These three findings mark the edge of that answer.

The Rollout Is Already Under Way

Timing gives this weight. Microsoft Entra begins auto-enabling passkeys on September 1, 2026. SMS and voice authentication retire on February 1, 2027.

Organizations are moving onto passkeys now, on a schedule the vendor set. The CVE-2026-34348 fix has been available since July 14. How widely it has actually been deployed is not publicly known, and the two memory-and-session attacks have no patch to deploy at all.

Conclusion: The Cryptography Held. The Endpoint Did Not.

The passkey attacks disclosed around Black Hat USA 2026 do not show that FIDO2 cryptography has failed.

They show something more operationally important. Strong authentication still depends on the device, software, memory, logs, and session state surrounding the credential.

One attack turns a previously logged WebAuthn assertion into something reusable. Another targets the secret protecting synced passkeys while it exists in browser memory. A third operates from an already compromised Windows session and invokes hardware-bound credentials without stealing the private key itself.

The attacker does not need to break the passkey.

They need control of the environment allowed to use it.

Why This Threat Matters

• Phishing resistance removes credential phishing, but it does not make a compromised endpoint trustworthy.
• Authentication artifacts can become reusable when implementations fail to enforce replay boundaries correctly.
• Synced passkeys increase convenience, but they also make protection of the credential manager and its runtime secrets critical.
• Hardware-bound credentials remain powerful, but an already compromised user session can create a different path to their use.
• Privileged accounts are especially sensitive because successful authentication may satisfy phishing-resistant MFA policy while the surrounding execution context is already hostile.
• A successful passkey authentication proves that the credential operation was valid. It does not independently prove that the process, session, or endpoint requesting it was trustworthy.

The security boundary therefore moves closer to the endpoint. Authentication strength and endpoint trust cannot be treated as separate control problems.

Where Defensive Control Must Operate

For the attack paths that require unauthorized local execution, Xcitium Advanced EDR, powered by Xcitium’s patented Zero-Dwell platform, applies Execution Governance before unknown code receives unrestricted execution rights.

Unknown processes should not gain unrestricted access to the system simply because they are running inside a session that already belongs to an authenticated user. Execution Governance constrains unknown execution at runtime before trust exists, reducing the opportunity for attacker tooling to freely interact with protected system resources or use the endpoint as an unrestricted credential-access environment.

Xcitium ITDR addresses the identity side of the same problem. Replayed assertions, unusual privileged access, unexpected session behavior, and follow-on authentication activity must be evaluated as identity risk even when the original authentication mechanism is classified as phishing-resistant.

Neither layer replaces passkeys.

They protect the environment in which passkeys are expected to remain trustworthy.

Patch the Implementation. Re-establish Device Trust.

Organizations should deploy the CVE-2026-34348 fix, investigate endpoints where unauthorized local execution may have occurred, review privileged authentication activity, and invalidate sessions or credentials when their surrounding trust state cannot be established.

The lesson is not to abandon passkeys.

It is to stop treating successful cryptography as proof that everything around it was secure.