Three Black Hat papers broke passkey deployments. None of them broke passkeys.

Three separate pieces of research presented around Black Hat showed passkey-protected identities being compromised. In all three cases the cryptography held. What failed was the machinery around it: how responses are logged, how devices are trusted, and what a piece of malware can ask an operating system to do on your behalf.

Pass-the-Passkey: replaying what should not be replayable

Michael Grafnetter, Principal Security Researcher at SpecterOps, presented his Pass-the-Passkey research, which targets failures in WebAuthn implementations rather than the standard itself.

Grafnetter found that Microsoft was writing WebAuthn authentication responses, including YubiKey signatures, into Windows event logs that were readable by authenticated but unprivileged users.

On its own that should be harmless. An old authentication response is supposed to be a spent ticket. But weaknesses in the wider WebAuthn validation process gave the researchers ways to replay those captured responses, letting them impersonate privileged users while still satisfying controls that were specifically configured to demand phishing-resistant MFA.

Microsoft has since patched the Windows event logging issue.

The detail worth carrying away is that the private key inside the YubiKey was never stolen and never needed to be. The hardware did its job perfectly. The flaw was in how the response it produced was stored and validated.

Pass-Ta-Key: convincing the cloud that a device is trusted

Unit 42 presented similarly named research, Pass-Ta-Key, at the same event.

Their work showed how malware already running on a compromised Windows machine could reach passkey information and convince Google Cloud Authenticator that a legitimate, trusted device was requesting the login.

That produced account takeover with no user interaction at all. In the most serious variant, the researchers were able to extract all of a user's synced passkeys, which turns a single compromised endpoint into a compromise of every account those passkeys protect.

The precondition matters and should be stated plainly: the attacker already needed malware running on the victim's machine. This is not a remote attack on the protocol. Some of the specific issues were fixed following disclosure.

Windows Hello without the biometric

Dirk-Jan Mollema, founder of Outsider Security, demonstrated the most awkward of the three, because it is the hardest to patch.

Malware inside an already logged-in Windows session can use the victim's Windows Hello for Business credentials without ever stealing the private key. The mechanism is almost mundane: code running as the user asks Windows to use the legitimate Windows Hello key to sign an authentication request, and no further biometric check or PIN is required.

That signed request can satisfy Entra conditional access policies demanding phishing-resistant authentication, and from there the attacker reaches cloud systems as a properly authenticated user.

There is no simple fix available for this behaviour today. The practical defences are preventing endpoint compromise in the first place, and monitoring Windows Hello sign-ins for missing device IDs or unexpected new device registrations.

The pattern across all three

Three unrelated research teams, three different targets, one shared conclusion: nobody attacked the passkey. They attacked logging, device trust and operating system behaviour, and in each case they arrived at privileged access anyway.

This follows directly from the enrolment attacks covered in the last issue, where a threat actor phoned users and walked them through a fake passkey registration flow. The passkey held up there too. The attacker simply picked a different part of the process.

There is a useful way to think about this. Passkeys move the weakest point in authentication. They do not remove it. Before, the weakest point was the user typing a secret into the wrong box. Now it is the endpoint the passkey lives on and the systems that decide whether a given response is genuine.

The endpoint consequence is the one most rollouts have not internalised. Two of these three attacks assume the attacker already has code running on the machine, and treat that as a starting position rather than a win condition. If your passkey business case implicitly assumed that phishing resistance reduced your dependence on endpoint security, that assumption is now published research.

Six questions for a passkey rollout

1. Are synced passkeys allowed, device-bound passkeys, or both? Pass-Ta-Key's worst case was extraction of an entire synced set, which is an argument the device-bound camp will be making for a while.

2. Should privileged accounts have different requirements? If admins and general staff have identical passkey policy, you have decided that they carry identical risk.

3. What happens when the endpoint itself is compromised? Write down the honest answer, not the policy answer.

4. Are your applications correctly validating WebAuthn responses? Grafnetter's work turned sloppy validation into privilege escalation.

5. Can you detect unusual passkey registrations and authentications? Mollema's practical defence is detection, because there is no patch.

6. What checks apply when someone needs a replacement credential? Recovery is still the enrolment path with the guardrails removed.

What actually changes on Monday

Not the strategy. Passkeys remain a substantial improvement over passwords and push-based MFA, and defaulting to them is still the right call.

What changes is the supporting work you schedule alongside the rollout. Patch the Windows event logging issue if you have not. Get Windows Hello sign-in telemetry into somewhere a human looks, with alerts on missing device IDs and new device registrations. Decide your synced-versus-device-bound position for privileged accounts deliberately rather than by default. And stop treating endpoint compromise as a separate programme from the identity one, because the research this fortnight treats them as the same programme.

Sources

• Pass-the-Passkey: a family of attacks, Black Hat US 2026 briefings

• Passwordless authentication security risks, Unit 42

• Malware can abuse Windows Hello for Business, The Hacker News