Executive Summary
This analysis revises our April 2026 assessment. That piece argued passkeys were shifting from a specialty project to a broad operating control, and that enrollment confusion, helpdesk social engineering, device change requests and fallback paths would absorb the attacker attention that credential phishing could no longer spend. Six months of research has confirmed that prediction more thoroughly than we expected — Microsoft documented an active campaign built entirely on passkey enrollment pretexts — and added a category we did not anticipate: direct attacks on synced passkey key material.
The headline conclusion has not changed. Passkeys remain the strongest authenticator most organisations can realistically deploy, and nothing published this year breaks WebAuthn's origin binding or produces a remote credential phish against a correct implementation. What has changed is the precision with which we can say where the remaining risk sits, and the answer is: everywhere except the protocol. The framing that best captures it comes from the research community's own summary — phishing resistance at the cryptographic protocol layer does not guarantee deception resistance across the operating system, browser, application and user interface layers.
AttackAttack Overview
It is worth being exact about what is and is not broken, because "passkeys defeated" headlines this year have been consistently misleading about threat models.
The WebAuthn protocol binds a credential to an origin. A passkey registered for your tenant will not assert against an attacker's domain, no matter how convincing the page. That property is intact. No 2026 research defeats it. An adversary-in-the-middle proxy that successfully relays a password and an OTP cannot relay a passkey assertion, which is precisely why passkeys remain the recommended control.
What researchers have found instead falls into three groups, none of which contest the protocol.
The first group targets key material on the endpoint, and requires malware already present. The second targets enrollment and recovery — the moments when an account transitions into or back into a passkey state, where weaker authentication is necessarily accepted. The third targets the human interface layer: what the user sees, what they think they are approving, and which window is actually asking.
A defender reading "39 passkey attacks" should understand that this is largely a statement about layers two and three, and that layer one carries a prerequisite most phishing campaigns cannot satisfy on their own.
AttackInfrastructure & Tradecraft
Unit 42's Pass-ta-key research is the most technically significant work of the year on this subject. It describes three attacks against Google's synced passkey ecosystem as implemented in the Google Cloud Authenticator used by Chrome on Windows with TPM devices. All three assume unprivileged malware already running on the victim's machine.
**Pass-ta-key** — device identity impersonation. Malware extracts the wrapped identity private key from disk or Chrome memory, then invokes Windows CNG APIs to generate the required signatures. No user interaction, no device unlock, no privilege escalation. The identity key is exported as an `NCRYPT_OPAQUE_KEY_BLOB`, which lets the malware call the same cryptographic operations Chrome itself calls. The result is account takeover without user consent or biometric verification.
**Silver Pass-ta-key** — user verification key bypass. The attacker invalidates the existing UV key, forces device re-onboarding, then exploits the `uv_key_pending` state to register an attacker-controlled UV key. The vulnerability is that the cloud authenticator did not validate the attestation of newly registered UV keys to confirm they originate from secure hardware. This yields reusable access from the attacker's own environment without further involvement of the victim device.
**Golden Pass-ta-key** — master key extraction, and the most serious of the three. The attacker forces re-onboarding, dumps Chrome process memory, and extracts the Security Domain Secret in plaintext during the recovery window. With the SDS, every synced passkey private key can be decrypted offline. The impact is not one account; it is all of them, persistently, regardless of later remediation of the individual credentials. Unit 42 notes the SDS appeared in Chrome's logs at `chrome://device-log/FIDO` before Google removed it following responsible disclosure.
The naming convention is deliberate and the analogy is apt — this is the Kerberos silver-ticket and golden-ticket distinction applied to a passkey sync domain, with the same escalation in blast radius.
The architectural lesson is the one worth carrying into policy. Synced passkeys are protected by a master key held in the cloud authenticator but recovered to the client during onboarding, and that recovery creates a window in which key material exists in client memory. Device-bound passkeys never expose the master key to client storage at all. That is not a minor implementation difference; it is the difference between a credential that can be stolen in bulk by endpoint malware and one that cannot.
Alongside this, the broader catalogue documented across the research community now runs to at least 39 publicly documented methods, attack paths and exploitation scenarios. The named classes include assertion mining, assertion replay, circuit breaker attacks, assertion phishing, browser hooking, assertion capture, challenge injection, detour replay, user verification manipulation and user presence manipulation. A further set targets the interface rather than the protocol: passkey prompt flooding, credential interface deception, application metadata spoofing, window handle spoofing, remote desktop passkey phishing and FIDO interface overlay attacks. Affected components span password managers including KeePassXC and Bitwarden, cloud synchronisation systems, mobile devices, browsers, and enrollment and recovery processes.
Then there is the social engineering layer, which needs no vulnerability at all. Microsoft's September analysis of Storm-3121 and Storm-3032 documents helpdesk impersonation calls using passkey enrollment urgency as the pretext — with the notable finding that passkey enrollment is usually not the actual objective. The passkey story is a convincing reason to walk a victim into an AiTM proxy or a device-code approval. We cover that campaign in detail separately; the relevant point here is that an organisation mid-rollout has handed attackers a plausible script, and the cost of that script is zero.
DetectionDetection Opportunities
Our April recommendation was to monitor enrollment anomalies, recovery abuse and risky fallback paths. That remains correct and can now be specified more precisely.
Authentication-method registration is the highest-value event. Every passkey enrollment, every added authenticator, and every change to registered methods should be logged, attributable, and reviewable — with particular attention to registrations occurring outside a known rollout window or from an unmanaged device.
AuditLogs
| where TimeGenerated > ago(30d)
| where Category == "UserManagement"
| where OperationName has_any ("Update user", "User registered security info",
"Admin registered security info",
"User changed default security info",
"Admin updated security info")
| extend Actor = tostring(InitiatedBy.user.userPrincipalName)
| extend Target = tostring(TargetResources[0].userPrincipalName)
| extend Method = tostring(TargetResources[0].displayName)
| project TimeGenerated, Actor, Target, OperationName, Method, Result
| where Actor != Target or isempty(Actor)That final filter is the interesting one: a security-info change where the actor and the target differ is either a legitimate administrative action or exactly the helpdesk-abuse pattern the Microsoft campaign relies on. Both deserve review.
The downgrade signal is the second priority. A user who holds a registered passkey but authenticates with a weaker method is either hitting a legitimate fallback or being steered into one.
let PasskeyUsers =
AuditLogs
| where TimeGenerated > ago(90d)
| where OperationName has "security info"
| where tostring(TargetResources[0].displayName) has_any ("FIDO2", "Passkey",
"Windows Hello")
| distinct UserPrincipalName = tostring(TargetResources[0].userPrincipalName);
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| where UserPrincipalName in (PasskeyUsers)
| mv-expand AuthDetail = AuthenticationDetails
| extend AuthMethod = tostring(AuthDetail.authenticationMethod)
| where AuthMethod !has_any ("FIDO2", "Passkey", "Windows Hello", "Certificate")
| summarize DowngradeCount = count(), Methods = make_set(AuthMethod),
IPs = make_set(IPAddress)
by UserPrincipalName, bin(TimeGenerated, 1d)
| order by DowngradeCount descFor the endpoint-malware class, the detection is not identity telemetry at all — it is endpoint telemetry on process access to Chrome's memory and passkey storage. Watch for non-Chrome processes opening handles to `chrome.exe` with memory-read rights, and for access to the Chrome sync database and `passkey_enclave_state` files. That is a standard credential-theft detection pattern applied to a new target, and organisations that already hunt for LSASS access have most of the machinery.
ValidationValidation Workflow
Validate in an authorized test tenant with disposable accounts.
Prove the enrollment rule end to end by registering a passkey for a test user and confirming the audit event appears with a populated method name. Then have a test administrator modify a second test user's security info and confirm the actor-target mismatch filter catches it. That second case is the one that matters operationally and the one most likely to be missing from your current alerting.
Prove the downgrade rule by registering a passkey for a test user and then deliberately authenticating with a password and OTP. Confirm the user appears in the downgrade summary. Then authenticate with the passkey and confirm they do not. Run this against a small pilot group before estate-wide deployment, because the first run in a real environment usually reveals that legitimate fallback is far more common than the identity team expected — which is itself the finding.
For the endpoint class, validate that your EDR actually alerts on foreign process memory access to the browser. A benign test tool reading `chrome.exe` memory in a lab is sufficient to prove the sensor fires; you are testing coverage, not building capability.
GapsEvasion & Gaps
The honest limitation of everything above is that the Pass-ta-key class is not detectable in identity telemetry. A Golden Pass-ta-key extraction produces a perfectly valid assertion from a perfectly valid credential. Entra sees a successful passkey sign-in, which is the single strongest positive signal in your entire identity stack, and it is correct — the assertion really was generated by that key. The compromise happened on the endpoint, before the protocol was ever involved. Any detection strategy that treats "authenticated with passkey" as a terminal trust decision inherits this gap completely.
The downgrade rule has a reporting-fidelity problem. `AuthenticationDetails` population varies by licensing tier and sign-in type, and the rule will silently under-report where the field is sparse. Confirm population before relying on it.
The enrollment rule cannot distinguish a legitimate helpdesk reset from a socially engineered one, because they are the same action performed by the same role for the same stated reason. The control for that is process — identity verification before the reset — not detection after it.
Interface-layer attacks, including overlay and window handle spoofing, leave essentially no server-side artifact. The user approved a prompt; the prompt was real; the context was fabricated. There is no telemetry for a misunderstanding.
And the social engineering entry point remains entirely outside enterprise visibility. A call to a personal phone followed by an SMS produces no enterprise log of any kind.
Defensive Recommendations
Keep deploying passkeys. Nothing in this revision argues otherwise, and the campaigns documented this year disproportionately target organisations that have not finished a rollout — because an incomplete rollout is what makes an enrollment pretext credible.
Choose device-bound credentials for high-value populations. This is the most consequential change to our April guidance. Finance approvers, administrators, developers and anyone with access to sensitive data should hold device-bound passkeys or hardware security keys, not synced credentials, specifically because the synced model exposes master key material to client memory during recovery. For the general population, synced passkeys remain a large net improvement over passwords and OTP, and the convenience is what makes the rollout finish.
Harden enrollment and recovery as first-class controls. Require strong identity verification before any helpdesk-initiated credential or MFA reset, alert on every such reset, and apply Conditional Access to security-information registration with sign-in frequency set to always. Restrict re-triggering of onboarding flows and treat unexpected device re-registration as an incident, since forced re-onboarding is the common precondition for two of the three Pass-ta-key attacks.
Set relying-party configuration correctly: require `userVerification=required`, validate the UV flag in authenticator data rather than trusting the client, and enforce approved authenticator classes through attestation so that an attacker-registered software key cannot silently join the trusted set.
Finish the rollout, then publish what the real enrollment looks like. The strongest defence against passkey-themed social engineering is a workforce that has already completed the genuine flow and knows the helpdesk never calls about it. The control this year's campaigns impersonate is still the control that stops them.
Our April framing was that passkeys are a better lock, not a finish line. That holds. The refinement six months of research adds is that the lock is sound and the attacks have moved to the door frame, the keyring, and the person who hands out spares.