On 5 August 2026, at Black Hat USA, SpecterOps principal security researcher Michael Grafnetter presented the firm’s Pass-the-Passkey research: a family of more than 20 attack techniques affecting Windows 11, Microsoft Entra ID, web browsers, password managers, and enterprise authentication workflows.

The headline result is the one that matters for control frameworks. The researchers demonstrated a chain that impersonated privileged users while satisfying phishing-resistant multi-factor authentication. It did not steal the authenticator’s private key. It reused signed authentication material that the platform had already produced — and the relying party accepted it.

Two concrete weaknesses anchor the research:

  • CVE-2026-34348 (CVSS 6.5): the Windows Event Logging Service was writing complete copies of passkey-related key material to event logs in cleartext, readable by any authenticated, unprivileged user on the machine. Microsoft has issued a security update.
  • WebAuthn anti-replay enforcement gaps in Entra ID: inadequate enforcement of challenge uniqueness, session binding, and signature-counter verification — the three controls in the WebAuthn specification that are supposed to make a captured assertion useless the moment it is replayed. Microsoft has stated it applied mitigations for the passkey relay assertion issue.

For anyone who has written “phishing-resistant MFA deployed” into a control narrative and considered the identity workstream closed, this is the week to reopen it.

Why this is a compliance story and not just a vulnerability story

Passkeys and FIDO2 have had an unusual regulatory trajectory. In roughly four years they went from an emerging technology to a control that multiple frameworks name specifically, and in some cases privilege above all alternatives:

  • NIST SP 800-63B treats phishing-resistant authenticators as the requirement at AAL3, and the revised guidance elevates them substantially at AAL2.
  • CISA guidance has consistently directed agencies and critical infrastructure operators toward phishing-resistant MFA as the preferred and, in several contexts, expected form.
  • PCI DSS v4.0.1 Requirement 8.5.1 requires that MFA systems be not susceptible to replay attacks — language that maps directly onto what this research targets.
  • CMMC and the underlying NIST SP 800-171 controls push toward replay-resistant authentication mechanisms for privileged and network access (3.5.4).
  • Executive Order 14028 and its successor directives made phishing-resistant MFA a federal baseline expectation.

The consequence is that a large number of organisations wrote the same sentence into their assessments: we have deployed phishing-resistant MFA, therefore credential replay and adversary-in-the-middle phishing are mitigated.

The Pass-the-Passkey research does not invalidate passkeys. What it invalidates is the terminal form of that sentence. Phishing resistance is a property of a correctly implemented protocol operating on an uncompromised endpoint with a relying party that enforces the specification. Remove any one of those three and the property degrades — silently, without generating a control exception, and while continuing to produce a green result in every dashboard the compliance function reads.

The three failure surfaces

The research is best understood as targeting three distinct layers, each of which is a separate control owner in most organisations.

1. The endpoint: key material in the wrong place

CVE-2026-34348 is the simplest and most instructive finding. Windows was writing passkey-related material into event logs in cleartext, and those logs were readable by any authenticated user on the host.

The implication is that the security of the authenticator depended on a logging configuration — a subsystem that identity teams do not own, that security operations teams treat as a source rather than a secret store, and that endpoint hardening baselines rarely evaluate for confidentiality of contents.

This is the recurring pattern in credential-material exposure: the secret is properly protected in the component designed to protect it, and then copied by an adjacent component that was never in scope for the threat model. Diagnostic channels, crash dumps, telemetry pipelines, and event logs are all in this category.

The control question is not “is our authenticator secure.” It is “what other subsystems on this endpoint can observe authentication material, and who reviewed them?“

2. The relying party: anti-replay controls that were not enforced

The Entra ID findings are more consequential architecturally. WebAuthn defines specific anti-replay mechanisms:

  • Challenge uniqueness — every authentication ceremony must use a fresh, unpredictable challenge, and the relying party must reject a re-used one.
  • Session binding — the resulting assertion must be bound to the session it was produced for, so it cannot be lifted into a different session.
  • Signature counter verification — authenticators increment a counter with each assertion; a relying party seeing a counter that does not advance is seeing a clone or a replay and is supposed to reject it.

Where those are not fully enforced, a captured assertion becomes reusable. The attacker never needs the private key, never needs to phish a user into approving a prompt, and never triggers the user-visible signals that phishing-resistant MFA is supposed to produce.

For compliance purposes this is the critical distinction: the control was configured; the control was not enforced. No configuration audit of the tenant would have surfaced this, because the setting was correct. The gap was in the relying party’s implementation of the specification behind that setting.

3. The synced-credential model: portability as attack surface

The broader research covers techniques against synced passkeys — credentials that replicate across a user’s devices through a platform account or password manager. Synchronisation is what made passkeys viable for consumer adoption and for enterprise rollouts that could not tolerate the recovery burden of hardware-bound credentials.

It also means the credential exists in more than one place, protected by the security of the sync fabric and the account that controls it. An organisation that migrated from hardware security keys to synced platform passkeys to reduce cost and support burden made a real security trade-off. Whether that trade-off was documented, risk-assessed, and approved is a question an assessor is now entitled to ask.

What assessors will start asking

Expect the following questions to appear in identity control testing over the next assessment cycle. Organisations should be able to answer them before they are asked.

“Is your phishing-resistant MFA hardware-bound or synced?” These are materially different controls with different threat models. If your control narrative says “FIDO2” without specifying, it is under-described. NIST’s authenticator taxonomy distinguishes them, and framework mappings increasingly follow.

“How do you verify the relying party enforces anti-replay?” For a SaaS identity provider, this is a vendor assurance question — one you cannot test directly and must therefore obtain in writing, along with the vendor’s disclosure and patch commitments.

“What is your detection for assertion reuse?” Signature-counter anomalies and impossible-travel on authenticated sessions are the observable signals. Most organisations do not alert on either.

“Which accounts are exempt?” As with the Snowflake campaign, the exception population is where the risk concentrates. Break-glass accounts, service principals, and legacy integration paths frequently sit outside the phishing-resistant flow entirely, and an attacker who can reach them does not need any of this research.

“What compensating controls exist when the authenticator assurance degrades?” This is the question the research really poses. If phishing-resistant MFA is your single strongest identity control, what happens on the day it is bypassed?

The compensating control layer

The practical answer is that phishing resistance has to become one layer in a defence-in-depth identity posture, not the terminating control. Specifically:

  1. Conditional access on device compliance. An assertion replayed from an unmanaged or non-compliant device should fail regardless of how valid the assertion is. Device-bound session credentials (token protection / token binding) close the gap between “the authentication was valid” and “the session belongs to the authenticated device.”

  2. Continuous access evaluation. Session revocation on risk signal — rather than waiting for token expiry — limits the window in which replayed material remains useful.

  3. Privileged access separation. Administrative access from dedicated, hardened workstations means that a compromise of a general-purpose endpoint’s logging subsystem does not reach material that authenticates privileged sessions. This single architectural control neutralises most of the endpoint-side findings.

  4. Sign-in log monitoring for authentication-method anomalies. A privileged account whose authentication method, device, or signature counter behaves inconsistently is a high-fidelity signal that almost nobody alerts on.

  5. Hardware-bound credentials for the highest tier. Where the risk assessment supports it, tiered authenticator requirements — synced passkeys for general workforce, hardware-bound FIDO2 for privileged roles — align the assurance level with the blast radius.

  6. Patch discipline on the identity path. CVE-2026-34348 has a Microsoft security update. The August 2026 Patch Tuesday cycle is the delivery vehicle for identity-adjacent fixes of exactly this kind, and identity infrastructure patching should not be sitting in the same queue as general workstation patching.

The narrative that needs rewriting

There is a specific sentence in a great many control documents that should be revised this quarter. It reads approximately:

The organisation has deployed phishing-resistant multi-factor authentication across all user accounts, mitigating the risk of credential theft and adversary-in-the-middle attacks.

The revised version needs to specify the authenticator type (hardware-bound or synced), the enforcement scope including the exception population, the relying party assurance obtained regarding specification conformance, the detective controls that would surface an assertion replay, and the compensating controls that constrain a session established with replayed material.

That is a longer sentence. It is also the difference between a control claim that survives contact with this research and one that does not.

What this does not mean

It is worth being precise about the limits of the finding, because the reflex response to research like this is a retreat that makes things worse.

Passkeys remain substantially stronger than passwords, OTP codes, and push notifications. Nothing in this research suggests otherwise. The techniques presented require a meaningful position — typically code execution or read access on the endpoint, or a specific relying party implementation gap — that password phishing does not. An organisation that responds to this by pausing a passkey rollout and staying on SMS-based one-time codes has made its position considerably worse.

The vendor response was appropriate and timely. Microsoft issued a CVE and a security update for the logging exposure and applied mitigations for the relay assertion issue. That is the process working.

The research was disclosed at a conference, not weaponised in the wild. No exploitation campaign has been attributed to these techniques.

The lesson is narrower and more durable than “passkeys are broken.” It is that a control’s compliance value is not fixed at deployment. Phishing resistance was true when the control narrative was written and became conditional when the research landed. The organisations that will handle this well are the ones whose control documentation records the assumptions a control depends on, so that when an assumption is challenged, the affected claims can be located and re-evaluated rather than quietly continuing to appear as satisfied.

Two things follow. For identity teams: the strongest authentication control in your environment still needs a detective layer behind it and a blast-radius limit around it, because the day it degrades is the day you find out whether it was your only control. For compliance functions: “we implemented the framework’s preferred control” is a snapshot, not a standing conclusion — and the assumptions under that snapshot belong in the documentation alongside the control itself.

This article is provided for informational purposes only and does not constitute legal advice.