Three independent disclosures in one week attacked passkeys from both ends — the cryptography on a compromised endpoint and the enrolment on the phone — and the enterprise path, borrowing a signed-in session's Windows Hello key to authenticate to Entra ID, carries no CVE and no fix

Passkeys are the control European public-sector identity programmes are being pushed toward, on the correct premise that a credential which cannot be replayed to the wrong origin defeats remote phishing. Three independent disclosures inside ISO week 2026-W32 attacked that control from different directions, and the useful reading is neither that passkeys are broken nor that this is coincidence: it is that the residual attack surface has moved entirely onto the endpoint and the enrolment, and this week three separate parties published against it.

The enterprise path is the new one, and it is unpatched. At Black Hat USA 2026, Dirk-jan Mollema showed that malware running in an already-signed-in Windows session can call the Passport key-storage provider to sign data with the Windows Hello for Business private key — and that "calling these native functions from for example PowerShell does not prompt the user for a PIN or biometric authentication at all, but works based on cached data" (Dirk-jan Mollema, 2026-08-05). The second half is what makes it a remote-usable attack rather than a local curiosity: the WebAuthn challenge Entra ID issues "is not bound to a session, a user or even a tenant, so we can request it on our attacker host and then use the WHFB key on the victim machine," after which the signed assertion is replayed from the attacker's own host. Where the resulting token carries no device-ID claim, the attacker can register a device of their own and obtain a long-lived refresh token. No CVE was assigned and the behaviour was left as it is — a characterisation the reporting attributes to Mollema himself rather than to the vendor, noting that its own requests for comment to Microsoft and to Mollema were still outstanding at publication (The Hacker News, 2026-08-07). For a defender the practical position is the same either way: there is no patch to wait for and no identifier to track it by.

The consumer-synced path was published two days earlier and reaches further. Unit 42's three attacks against Google Password Manager's cloud-synced passkeys in Chrome on Windows all require only unprivileged malware already on the endpoint: driving the TPM-wrapped device identity key through standard Windows cryptography calls to sign a forged assertion with the User Verified flag unset, which succeeds against any relying party that does not validate that flag; forcing device re-enrolment and registering an attacker-generated user-verification key, because the cloud authenticator does not check attestation on new user-verification keys; and dumping the 32-byte security-domain secret from Chrome's memory during recovery, which decrypts every synced passkey private key (Palo Alto Networks Unit 42, 2026-08-03). The third has no remediation path at the user's disposal — Google has no mechanism to rotate or revoke that secret.

The third direction needs no software flaw at all. Google's threat-intelligence group reports that UNC6671, the operator behind the BlackFile extortion brand and four later brands, runs an identity-centric intrusion chain whose current pretext is precisely the control being rolled out: a call to an employee's personal mobile impersonating the IT helpdesk, sometimes spoofing the real helpdesk number, demanding an urgent FIDO2 passkey or MFA re-enrolment into an adversary-in-the-middle panel (Google Threat Intelligence Group, 2026-08-06). Enrolment is the moment the phishing-resistance property does not yet exist, and an organisation that has just deployed passkeys is an organisation whose staff have been told to expect exactly such a call.

Triage: the telemetry these attacks produce is authentication that succeeds, which is why the discriminator has to be positional rather than a failure signal. Look for a successful passkey or WebAuthn sign-in from a network location or device that has never previously held that key, and for Windows Hello key use with no corresponding interactive logon that would have prompted for a PIN or biometric — a genuine user's assertion is preceded by an unlock event, a borrowed one is not. On the tenant side, the sequence to alert on is a device-registration event followed closely by a long-lived refresh-token issuance for an account whose enrolment state changed within the preceding hours; legitimate device onboarding produces the same events, but not usually within minutes of a helpdesk-initiated credential reset.