Passkeys were supposed to end password attacks. Research from SpecterOps shows that when the surrounding implementation is flawed, attackers can bring those old attacks right back—stealing and replaying authentication material to impersonate a legitimate user without ever touching a password. (Source: Dark Reading)

Michael Grafnetter, principal security researcher at SpecterOps, uncovered three nearly exploitable zero-day vulnerabilities in Windows 11 and Microsoft Entra ID. Two of them chain together into what he calls "Pass-the-Passkey," a technique that echoes older Windows attacks like pass-the-hash and NTLM Relay. The end result: an attacker can impersonate privileged cloud identities and bypass phishing-resistant multifactor authentication (MFA).

The core problem is not the cryptography behind WebAuthn, the technology that drives passkeys. It's how the pieces around it were built. SpecterOps found that Windows 11 was writing a complete copy of the digital key into the event log, and Entra ID failed to properly stop those authentication assertions from being reused.

"Passkeys are still a major improvement over passwords, but they are not magic. Our research shows that if surrounding implementation is flawed, attackers can still reintroduce replay, relay, and phishing-like attack paths even when the underlying WebAuthn cryptography is sound," Grafnetter told Dark Reading.

The main Windows flaw is tracked as CVE-2026-34348, described as a protection mechanism failure in the Windows Event Logging Service that could allow an attacker to disclose information over a network. Microsoft patched it on July 14, the last Patch Tuesday before the Black Hat USA conference where Grafnetter will present the findings.

This matters most if your organization uses Windows Hello or FIDO2 security keys such as Yubikeys with Entra ID. Microsoft has also announced that starting Sept. 1, passkeys become the default sign-in method for Entra ID—so the population of exposed accounts is about to grow considerably.

Attack Chain: From Exploitation to Unauthorized Access

The core weakness sits in how Windows 11 handled WebAuthn assertions during event logging. Rather than logging a reference or a sanitized record of the authentication event, the operating system wrote a complete copy of the digital key material to the Windows Event Log. That misstep is now tracked as CVE-2026-34348, described by Microsoft as a protection mechanism failure in the Windows Event Logging Service that could allow an attacker to disclose information over a network.

An attacker who can read those event logs gains access to the WebAuthn assertion itself—the cryptographic proof a user generates to authenticate. This is the entry point for the replay chain. For a security engineer, the implication is direct: authentication material you assumed lived only inside the secure enclave or the FIDO2 authenticator ended up sitting in a log file readable over the network.

The second half of the chain lives server-side, in Microsoft Entra ID. According to SpecterOps, Entra ID failed to properly reject reused assertions. The WebAuthn specification requires several validation checks on each assertion to confirm it is fresh and tied to a single authentication ceremony. When those checks are incomplete, a captured assertion can be presented again and accepted as valid.

Chaining the two flaws produces the impersonation path:

• Harvest the assertion: Read the copied WebAuthn key material from the Windows Event Log, reachable over the network because of the logging service flaw.
• Replay the assertion: Present the captured assertion to Entra ID, which does not consistently enforce the anti-replay validation steps the specification mandates.
• Assume the identity: Entra ID accepts the replayed proof and authenticates the attacker as the targeted user, including privileged cloud identities.

Because the session looks like a valid sign-in, the activity blends into normal authentication traffic. For your organization, that means an attacker operating with the permissions of an administrator without ever cracking, phishing, or brute-forcing a credential.

What makes this notable is that the underlying cryptography stayed sound. The private key never left the device, and the WebAuthn math was never broken. The failure was in the surrounding implementation—Windows exposing key material it should have protected, and Entra ID skipping validation steps required by the standard.

"One uncomfortable lesson from our research is that even Microsoft, one of the co-authors of the standard, missed some of the WebAuthn assertion validation steps required by the specification," said Michael Grafnetter of SpecterOps.

Grafnetter's own account of the exploitation path underscores why he labeled it a replay-and-relay technique reminiscent of older Windows credential attacks: the attacker steals and reuses authentication material rather than the underlying secret. The proof-of-concept behavior was demonstrable enough that he only discovered Microsoft's fix while recording the demos for his Black Hat presentation, after the company had quietly deployed a mitigation in its cloud services.

The technical indicators here center on two anomalies. First, WebAuthn assertion data appearing in full inside Windows Event Log entries—material that should never be written there. Second, the same assertion being accepted more than once by Entra ID, a signature of the missing anti-replay checks. Organizations running Windows Hello or FIDO2 security keys such as Yubikeys with Entra ID are the ones exposed to this specific chain.

The Windows-side flaw received its patch on July 14, the last Patch Tuesday before Black Hat USA, while the Entra ID validation gap was addressed through Microsoft's silent cloud-side mitigation.

Business and Compliance Impact of Passkey Authentication Failures

The most dangerous part of the Pass-the-Passkey chain is what it doesn't produce: no failed login attempts, no MFA push you can decline, no password reset requests hitting your help desk. When an attacker replays a stolen WebAuthn assertion to impersonate a privileged Entra ID user, the sign-in looks legitimate to your identity provider because, cryptographically, it is.

That changes the economics of detection for you. Traditional password attacks leave breadcrumbs—brute-force spikes, impossible-travel alerts, repeated MFA prompts that annoy a targeted user into reporting them. Here, an attacker impersonating a privileged cloud identity walks in through the front door with valid credentials and no noise.

Once inside a privileged account, the attacker inherits whatever that account can reach. In an Entra ID environment, a compromised privileged identity can mean access to administrative consoles, connected SaaS applications, and the ability to modify access policies. Consider what a single administrative account in your tenant can actually touch before assuming the blast radius is small.

The paths that follow are familiar even if the entry point is new:

• Lateral movement into other cloud resources the compromised identity is authorized to reach, using nothing but legitimate authenticated sessions.
• Privilege escalation by abusing the administrative rights the impersonated user already holds—no additional exploit required.
• Data exposure across mailboxes, document stores, and any system trusting the Entra ID sign-in, potentially including customer records and internal communications.

The compliance consequences follow the data. If the systems reachable through that account hold personal information, an incident like this can trigger breach notification obligations under GDPR, meaning you may need to notify regulators and affected individuals within tight statutory windows once you determine exposure occurred.

For audited environments, the implications are just as concrete. SOC 2 and ISO 27001 attestations rest on the assumption that your access controls work as designed. An authentication bypass that lets an attacker impersonate privileged users undercuts the control objectives your auditors signed off on, and you may face questions about whether your logging and access-review processes were adequate.

There's a reputational dimension you can't patch. You likely told your board, your customers, and your auditors that moving to phishing-resistant MFA raised the bar. When the "secure" method fails in a way that mirrors the password attacks it was meant to retire, that message becomes harder to defend—and the questions land on the people who championed the migration.

What makes this worse than a routine credential-stuffing incident is timing and expectation. Your monitoring and your staff are calibrated for password-era attacks. A privileged impersonation that produces valid sign-in telemetry can sit inside the window where nobody is looking, because the whole point of adopting passkeys was that this class of attack was supposed to be off the table.

None of this argues against passkeys. It argues that the account behind a passkey is now the target, and the value of a privileged cloud identity in your tenant is exactly what an attacker is after.

Detecting Passkey Bypass Attempts and Compromised Accounts

Your first move is to pull authentication logs for every privileged Entra ID account and correlate sign-in events against the Windows Event Log entries that recorded WebAuthn assertions. Because the flaw tracked as CVE-2026-34348 was patched on July 14, 2026, any privileged sign-in activity before that date on Windows 11 endpoints using Windows Hello or FIDO2 security keys falls inside the exposure window and deserves scrutiny.

Following the NIST Cybersecurity Framework's Detect function, start with the systems that generate and consume passkey material rather than the identity provider alone. The assertion had to be read from a log before it could be replayed, so endpoint log access is where the earliest indicators live.

Where to look in your logs

Focus your first review on read access to the Windows Event Logging Service on machines used by administrators and other high-value accounts. An attacker who never triggered a failed login still had to reach those logs over the network.

• Remote log access: Query for network-based reads of the Security and Application event logs, particularly access originating from hosts that are not administrative workstations or your SIEM collectors.
• Assertion reuse in Entra ID: In sign-in logs, look for authentication events where the same passkey credential authenticated a privileged user from a device or IP that does not match the enrolled hardware. Because the replayed assertion is cryptographically valid, filter on device fingerprint and network origin rather than on failed-attempt counts.
• Geographic and timing anomalies: Flag passkey sign-ins for privileged accounts from new geographies, at hours outside the user's baseline, or from device identifiers that were never enrolled through your normal Windows Hello or FIDO2 provisioning process.

A sign-in that uses a passkey but lacks a corresponding enrollment record is the clearest behavioral signal you have. It means the credential material was presented by something other than the device that generated it.

Threat hunting across the exposure window

Build a query that lists every privileged account that authenticated via passkey between whenever those accounts were first enabled for passwordless sign-in and the July 14 patch. Cross-reference each of those sessions against the actions taken afterward, because a replayed assertion produces a session that looks legitimate to Entra ID from that point forward.

• Enumerate privileged sign-ins that used Windows Hello or FIDO2 credentials, then isolate any where the source device is unfamiliar.
• Review directory changes, role assignments, and consent grants tied to those sessions, since impersonation of a privileged identity is most valuable when used to expand access.
• Check whether device-bound passkeys and attestation were enforced during each session; a synced or non-attested credential authenticating a privileged account is worth investigating on its own.

In environments Capstone manages, Adlumin monitors authentication patterns and flags privileged sign-ins from unenrolled devices or unexpected locations, which is exactly the deviation a replayed WebAuthn assertion produces. That behavioral baseline matters here because the sign-in itself carries no failed attempts or declined prompts to catch.

Once you have your hunt results, turn them into standing detections: alert on network reads of event logs from non-administrative hosts, on passkey sign-ins without matching enrollment, and on privileged authentications from new device fingerprints. Restrict remote log access so the assertion material cannot be read off an endpoint in the first place, and confirm the July 14 update is present on all Windows 11 systems that handle privileged sign-ins.

Remediation and Patching Strategy for CVE-2026-34348

Start by confirming which Windows 11 endpoints in your environment authenticate to Microsoft Entra ID using Windows Hello or FIDO2 security keys such as Yubikeys. Those are the systems that generated and logged the WebAuthn assertions exposed by CVE-2026-34348, so they define the scope of your urgent work.

The good news on timing: Microsoft patched CVE-2026-34348 on July 14, 2026, and separately deployed a mitigation to its Entra ID cloud services that closes the assertion-reuse side of the chain. You do not control the cloud fix, but the Windows patch is yours to roll out.

Identify and Protect (first hours)

Inventory every affected Windows 11 machine against Microsoft's advisory for CVE-2026-34348, which describes the flaw as a protection mechanism failure in the Windows Event Logging Service. Confirm each device is running a build that Microsoft lists as fixed rather than assuming a version number—check the advisory for your specific update channel.

While you stage the patch, restrict who can read event logs remotely on those endpoints. Limiting remote log access shrinks the window in which an attacker who is already positioned on the network can pull assertion material before your patch lands.

Protect (first days)

Apply the July 14 update across all identified endpoints, prioritizing machines used by privileged Entra ID accounts—global administrators, identity administrators, and anyone with standing access to sensitive cloud resources.

• Deploy the patch to privileged-user workstations before general-population devices.
• Force re-enrollment of passkeys on patched systems for privileged accounts, so any assertion material that may have been captured pre-patch is retired.
• Audit every privileged sign-in that occurred before July 14, 2026, on the affected endpoints, since that period falls inside the exposure window.

Treat the pre-patch window as a period of possible compromise rather than assuming the logs were never read. Because a replayed assertion produces a sign-in that is cryptographically valid, patching alone does not tell you whether an account was already abused—validate account integrity independently.

Protect and Detect (coming weeks)

For privileged users specifically, Grafnetter recommends preferring device-bound passkeys and enforcing attestation, which ties the credential to a known, verified authenticator rather than one that can roam. That reduces the value of any single stolen assertion.

Layer conditional access policies so phishing-resistant MFA is not your only control. Add device-trust verification and restrict privileged sign-ins to compliant, managed devices, so a valid assertion presented from an unknown endpoint is still denied.

Adlumin ITDR correlates authentication behavior across managed environments and flags privileged sign-in anomalies that a purely cryptographic check would treat as legitimate—useful for catching post-patch replay attempts that slip past identity-provider logic. Pair that monitoring with tighter code-execution controls and privileged-access workstations, since endpoint security and server-side validation carry as much weight here as the strength of the passkey itself.

Finally, standardize on well-tested WebAuthn frameworks for any in-house authentication work rather than building assertion validation yourself. Microsoft, a co-author of the standard, missed some of the required validation steps—an indication that this cryptography is easy to implement incompletely.

Incident Response: Validating Account Integrity After Bypass Exposure

The fastest way to know whether an account was actually compromised is to line up authentication records against the exposure window for CVE-2026-34348. Any privileged sign-in that occurred on a Windows 11 endpoint before the July 14, 2026 patch, where the WebAuthn assertion could have been read from an event log, is a candidate for further review. Start with those accounts and work outward.

Because a replayed assertion produces a cryptographically valid login, you cannot rely on failed-login signals to sort clean accounts from compromised ones. You are looking instead for the same assertion being used in ways that don't fit the user—two geographically separate sessions, a sign-in from an endpoint that never generated the passkey, or activity outside the user's normal hours.

Validate and reset exposed accounts

For every account that authenticated via passkey during the vulnerable period, treat the credential as potentially copied and act on it:

• Force a password reset on the underlying account, even though the attack targeted passkeys—privileged identities often retain a fallback password that becomes the next target.
• Revoke and re-enroll the passkey. Delete the existing FIDO2 or Windows Hello registration in Entra ID and require the user to enroll a fresh credential from a known-good device.
• Invalidate active sessions and refresh tokens so any session an attacker established with a replayed assertion is terminated rather than left running.
• Review recent account activity—consent grants, added authentication methods, mailbox rules, and role assignments—for changes the legitimate user did not make.

Adlumin ITDR correlates these sign-in and identity events across managed environments, so a replayed assertion showing up on an unexpected endpoint surfaces as an anomaly rather than sitting unnoticed in raw logs.

Trace what the attacker did next

Impersonating a privileged cloud identity is a means to an end. Once you confirm a suspect sign-in, pivot to what that identity touched afterward. Check for lateral movement into other tenants or resources, new privileged role assignments or group memberships, and application registrations or service principals created under the compromised account.

Then look for data access that fits exfiltration—large or unusual downloads, sharing links created for sensitive files, or mailbox export activity. Document each finding with timestamps so the scope of the incident is defensible if regulators or clients ask what was reached.

Notify affected users clearly

Re-enrollment only works if users act on it, so the notification matters as much as the technical steps. Keep it factual and specific: what they need to do, by when, and why. A short template you can adapt:

As a security precaution, we are asking you to reset your password and re-register your sign-in passkey before [date]. A recently patched flaw could have allowed your authentication data to be copied from an affected device. There is no confirmed misuse of your account—this is a preventive step. Instructions to re-enroll are here: [link]. Contact the IT service desk if you have questions.

Prioritize speed and completeness over a perfect investigation. This is a high-visibility incident affecting privileged identities, and getting every exposed account reset and re-enrolled quickly reduces risk more than waiting to close every open question first. Record what you did and when, so the response holds up under later scrutiny.

Key Takeaway: Validate Passkey Implementation Before Relying on It

The most important thing to understand about the SpecterOps research is where the weakness actually lives. The WebAuthn cryptography that powers passkeys held up fine. What failed were the implementation choices surrounding it—how Windows 11 recorded authentication material and how Entra ID checked whether an assertion had already been used.

If a co-author of WebAuthn can miss required checks, your assumption that any passkey product is correct by default no longer holds. Secure by design does not mean secure by default. The concept protects you only to the extent the code behind it does what the specification says.

Grafnetter's own guidance points at the practical fix: developers should build on well-tested WebAuthn frameworks rather than write their own validation logic, because passkey verification involves non-trivial cryptography and several checks that are easy to skip.

For you as a buyer or operator, that translates into a verification habit. As passkeys become the default across your identity stack, the questions you ask vendors about assertion validation, replay protection, and how authentication material gets logged will carry the same weight that password complexity and rotation policies once did. Treat implementation quality as something you confirm, not something you assume.

Passkeys remain a real improvement over passwords, and the attack paths described here are more complex than a typical credential-stuffing run. The takeaway is not to walk away from passkeys—it is to check the work behind them before you rely on it.