Passkeys were supposed to end the phishing era. For credential replay and password theft, they largely have — FIDO2's origin-bound, public-key cryptography is not something attackers can brute-force or replay. But new research from Token has cataloged 39 distinct methods for compromising passkey-based authentication, and the finding every security leader needs to internalize is this: none of them break the cryptography. They break everything around it.
The research maps attacks across the full passkey lifecycle — enrollment, authentication prompts, synced credential flows, account recovery, cross-device sign-in, and the human trust boundaries in between. Attackers don't need to defeat FIDO2 when they can trick a user into approving a prompt, hijack the session after a legitimate passkey assertion, abuse a weak recovery path to re-enroll an attacker-controlled key, or proxy the entire ceremony through an adversary-in-the-middle (AitM) phishing kit.
If your organization has deployed — or is deploying — passkeys as your phishing-resistant MFA strategy, this research is your wake-up call: the credential is strong, but the ecosystem is only as strong as your enrollment governance, recovery controls, session protection, and monitoring. This post breaks down the attack surface, what defenders can realistically observe, and how to harden each trust boundary.
Technical Analysis
What's Actually Being Attacked
Token's research is deliberately scoped: the 39 methods do not include cryptographic attacks against FIDO2/WebAuthn itself. Instead, they target the operational and human layers of a passkey deployment. For defenders, the techniques cluster into five abuse categories:
1. Authentication prompt abuse. Passkeys still rely on a human approving a prompt on a device. Attackers use real-time phishing pages, push-style fatigue, and social engineering to get victims to approve WebAuthn ceremonies on attacker-initiated sessions. The credential does exactly what it was designed to do — for the wrong session.
2. Synced passkey exposure. Consumer passkeys increasingly live in cloud-synced credential managers (platform keychains and third-party password managers). The security of the passkey then inherits the security of the sync account and its session tokens. Compromise the sync account — via infostealer-harvested session cookies, token theft, or account takeover — and you inherit the synced credentials or the ability to approve prompts from an attacker-registered device.
3. Enrollment and re-enrollment abuse. The highest-impact category for enterprises. If an attacker can add their own passkey (or security key) to a victim's account — through a compromised recovery flow, a help-desk social engineering call, weak identity proofing during onboarding, or a session hijacked post-authentication — they own the account with a cryptographically strong credential your controls will happily trust. This mirrors the TTPs seen in help-desk-targeting campaigns (Scattered Spider-style) where MFA enrollment, not MFA itself, is the pivot point.
4. Recovery and fallback path exploitation. Every passkey deployment has a recovery story, and it is almost always weaker than the passkey itself: SMS OTPs, email magic links, knowledge-based questions, or a help-desk override. Attackers route around the strong control by attacking the fallback — SIM swapping, mailbox compromise, or abusing self-service reset portals that downgrade authentication assurance.
5. Post-authentication session theft. A successful passkey assertion produces a session token or cookie. AitM phishing frameworks and infostealers don't care how you authenticated — they steal the session artifact and ride it. Malicious browser extensions with broad host permissions can observe or manipulate WebAuthn flows and siphon session material, and browsers launched with remote debugging enabled allow full session and ceremony manipulation by a local attacker or malware.
Affected Platforms and Scope
This is ecosystem-level research, not a product vulnerability — there is no CVE and no single patch. The affected surface includes any relying party (IdP or application) accepting WebAuthn assertions, platform authenticators on Windows (Windows Hello), macOS/iOS (iCloud Keychain), Android (Google Password Manager), third-party credential managers, hardware security keys, and the enterprise IdPs (Microsoft Entra ID, Okta, Ping, and others) that broker passkey enrollment and authentication.
Exploitation Status
These are technique classes, not a single exploit — and several are already standard practice in the wild. AitM phishing kits proxying WebAuthn flows, help-desk social engineering for MFA/passkey enrollment, infostealers harvesting session tokens and password-manager vaults, and SIM-swap-driven recovery abuse are all actively observed techniques. The research's contribution is systematically cataloging 39 variations so defenders can stop treating passkey compromise as theoretical. Treat the classes as confirmed-in-the-wild; treat the full 39-method taxonomy as a threat-modeling checklist for your deployment.
Detection & Response
Passkey attacks rarely generate a single high-fidelity alert. The winning strategy is correlation across identity telemetry and endpoint behavior: watch enrollment events, watch for session anomalies after strong authentication, and watch endpoints for the tooling (remote debugging, extension sideloading, infostealer behavior) that enables session and ceremony hijacking.
The rules below are grounded in the observable behaviors described above. The identity rules assume Microsoft Entra ID telemetry ingested into Sentinel; adapt the logic to your IdP's audit schema.
---
title: Passkey or Security Key Registration from Untrusted Network
id: 3f8c2a71-9b4d-4e6a-b1c7-5d9e0f2a8c31
status: experimental
description: Detects registration of a new passkey/FIDO2 security key in Entra ID originating from an IP address or ASN not previously observed for the user, consistent with enrollment-abuse techniques documented in Token's 39-method passkey attack research.
references:
- https://www.bleepingcomputer.com/news/security/39-new-methods-that-compromise-passkey-authentication/
- https://attack.mitre.org/techniques/T1556/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.persistence
- attack.t1556
logsource:
product: azure
service: auditlogs
detection:
selection:
OperationName|contains:
- 'Register security info'
- 'passkey'
- 'fido2'
filter_known_ip:
IpAddress|cidr:
- '10.0.0.0/8'
- '172.16.0.0/12'
- '192.168.0.0/16'
condition: selection and not filter_known_ip
falsepositives:
- Legitimate users enrolling new devices while traveling or on home networks
- Expected during initial passkey rollout waves — scope to post-rollout or alert at lower severity during enrollment campaigns
level: high
---
title: Browser Launched with Remote Debugging Port Enabled
id: 6e1d4b92-7c3a-4f58-9d2b-8a4e1c6f0d55
status: experimental
description: Detects Chrome or Edge launched with remote debugging flags. Malware and AitM tooling use the DevTools protocol to hijack authenticated sessions and manipulate WebAuthn/passkey prompts without breaking FIDO2 cryptography.
references:
- https://www.bleepingcomputer.com/news/security/39-new-methods-that-compromise-passkey-authentication/
- https://attack.mitre.org/techniques/T1539/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.credential_access
- attack.t1539
logsource:
category: process_creation
product: windows
detection:
selection_img:
Image|endswith:
- '\chrome.exe'
- '\msedge.exe'
- '\brave.exe'
selection_cli:
CommandLine|contains:
- '--remote-debugging-port'
- '--remote-debugging-pipe'
filter_parent:
ParentImage|endswith:
- '\chrome.exe'
- '\msedge.exe'
condition: selection_img and selection_cli and not filter_parent
falsepositives:
- Legitimate web developers and QA automation (Selenium, Playwright) — baseline developer workstations and exclude known automation parent processes
level: high
---
title: Suspicious Browser Extension Force-Installed via Policy Registry
id: 91a5e0c4-2d7b-4c68-b3f1-0e8d5a9c7b24
status: experimental
description: Detects registry-based force-installation of browser extensions, a technique used to deploy malicious extensions capable of observing WebAuthn flows, stealing post-authentication session tokens, and injecting phishing content into authentication prompts.
references:
- https://www.bleepingcomputer.com/news/security/39-new-methods-that-compromise-passkey-authentication/
- https://attack.mitre.org/techniques/T1176/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.persistence
- attack.t1176
logsource:
category: registry_set
product: windows
detection:
selection:
TargetObject|contains:
- '\Policies\Google\Chrome\ExtensionInstallForcelist'
- '\Policies\Microsoft\Edge\ExtensionInstallForcelist'
filter_admins:
Image|endswith:
- '\powershell.exe'
- '\msiexec.exe'
condition: selection and not filter_admins
falsepositives:
- Managed extension deployment via GPO/MDM — baseline the management tooling process and extension IDs in your environment
level: medium
The following Sentinel hunt correlates a new passkey registration with a subsequent sign-in from an unfamiliar IP — the enrollment-abuse kill chain in a single query. Tune the lookback window to your environment's baseline travel and remote-work patterns.
// Correlate passkey/FIDO2 registration events with sign-ins from unfamiliar IPs
// Hunts enrollment-abuse techniques from Token's 39-method passkey attack research
let lookback = 14d;
let PasskeyRegistrations = AuditLogs
| where TimeGenerated > ago(lookback)
| where OperationName has_any ("Register security info", "passkey", "fido2")
or tostring(AdditionalDetails) has "passkey"
| extend UserPrincipalName = tostring(parse_json(tostring(InitiatedBy.user)).userPrincipalName)
| extend RegIP = tostring(parse_json(tostring(InitiatedBy.user)).ipAddress)
| project RegTime=TimeGenerated, UserPrincipalName, RegIP, OperationName, Result = tostring(Result.description);
let UserHistory = SigninLogs
| where TimeGenerated > ago(30d) and TimeGenerated < ago(lookback)
| summarize KnownIPs = make_set(IPAddress) by UserPrincipalName;
PasskeyRegistrations
| join kind=leftouter UserHistory on UserPrincipalName
| extend IsNewIP = iff(KnownIPs has RegIP, 0, 1)
| join kind=inner (SigninLogs
| where TimeGenerated > ago(lookback)
| project SigninTime=TimeGenerated, UserPrincipalName, SigninIP=IPAddress,
AppDisplayName, ResultType, RiskDetail, Location
) on UserPrincipalName
| where SigninTime between (RegTime .. RegTime + 24h)
| extend IPSuspicion = iff(KnownIPs has SigninIP, 0, 1)
| project RegTime, UserPrincipalName, RegIP, IsNewIP, SigninTime, SigninIP, IPSuspicion, AppDisplayName, RiskDetail, Location
| sort by IsNewIP desc, IPSuspicion desc
For endpoint forensics, this Velociraptor artifact hunts the two endpoint behaviors most relevant to passkey ceremony and session hijacking: browsers running with remote debugging exposed, and recently modified browser credential/passkey stores that may indicate vault access by an infostealer.
-- Hunt: Passkey/session hijack precursors — debug-enabled browsers and credential store access
-- Covers endpoint behaviors enabling Token-documented passkey compromise techniques
-- Part 1: Browsers with remote debugging enabled (DevTools session/ceremony hijack)
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)chrome|msedge|brave'
AND CommandLine =~ '--remote-debugging'
-- Part 2: Recently modified browser credential/passkey stores (potential vault access)
SELECT FullPath, Size, Mtime, Atime
FROM glob(globs=[
'C:/Users/*/AppData/Local/Google/Chrome/User Data/*/Login Data',
'C:/Users/*/AppData/Local/Google/Chrome/User Data/*/Web Data',
'C:/Users/*/AppData/Local/Microsoft/Edge/User Data/*/Login Data',
'C:/Users/*/AppData/Local/Google/Chrome/User Data/*/Network/Cookies'
])
WHERE Mtime > now() - 86400
ORDER BY Mtime DESC
The PowerShell script below is a verification and audit tool for Entra ID environments: it pulls recent passkey/FIDO2 registration events from the audit log for analyst review. Run it on a scheduled basis or after any suspected enrollment-abuse incident.
#Requires -Modules Microsoft.Graph.Reports
# Passkey enrollment audit — review recent passkey/FIDO2 registrations for abuse
# Run with an account holding AuditLog.Read.All
Connect-MgGraph -Scopes "AuditLog.Read.All" -NoWelcome
# Pull the last 7 days of authentication-method registration activity
$start = (Get-Date).AddDays(-7).ToString("yyyy-MM-ddTHH:mm:ssZ")
$events = Get-MgAuditLogDirectoryAudit -Filter "activityDateTime ge $start" -All |
Where-Object {
$_.ActivityDisplayName -match "security info|passkey|fido" -or
($_.AdditionalDetails | Out-String) -match "passkey|fido2"
}
# Surface registrations for analyst review — flag off-hours and new IPs
$report = foreach ($e in $events) {
[pscustomobject]@{
Timestamp = $e.ActivityDateTime
Activity = $e.ActivityDisplayName
User = $e.TargetResources[0].UserPrincipalName
InitiatedBy = $e.InitiatedBy.User.UserPrincipalName
SourceIP = $e.InitiatedBy.User.IpAddress
Result = $e.Result
OffHours = (([datetime]$e.ActivityDateTime).Hour -lt 6 -or ([datetime]$e.ActivityDateTime).Hour -gt 22)
}
}
$report | Sort-Object Timestamp -Descending | Format-Table -AutoSize
$report | Export-Csv -Path "PasskeyRegistrationAudit_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation
Write-Host "`nReview any registration where OffHours=True, SourceIP is unfamiliar, or InitiatedBy != User (help-desk enrollment)." -ForegroundColor Yellow
# Also verify: passkey registrations should trigger email/notification to the user.
# Confirm your tenant has 'Authentication methods' change notifications enabled and
# that Conditional Access requires phishing-resistant MFA for the enrollment action itself.
Remediation
There is no patch for this — the fixes are architectural and procedural. Prioritize in this order:
1. Lock down enrollment — this is the primary attack surface.
- Require phishing-resistant authentication (an existing passkey or FIDO2 key, not SMS/voice) to add a new authentication method. In Entra ID, use Conditional Access authentication strengths scoped to the "Register security information" user action.
- Enforce attestation and an AAGUID allowlist for FIDO2 keys so only approved hardware can be registered in enterprise tenants.
- Alert on every passkey/security-key registration (rule and KQL above), with out-of-band user notification on any credential change.
2. Harden account recovery.
- Eliminate SMS and voice OTP as recovery factors for any account with privileged access; audit what fallback methods your IdP permits today.
- Require live identity proofing (document verification or in-person/manager attestation) for help-desk-driven passkey resets, and log these as high-severity events.
3. Protect the session after the assertion.
- Deploy token-binding protections: Microsoft token protection (Continuous Access Evaluation with sign-in session binding), or equivalent session-binding controls at your IdP, so stolen cookies can't be replayed from attacker infrastructure.
- Shorten session lifetimes for sensitive applications and revoke sessions on any credential-change or risk event.
4. Govern synced passkeys.
- Decide by policy whether synced (multi-device) passkeys are acceptable for your assurance level, or whether device-bound passkeys/hardware keys are required for privileged and workforce accounts. Document which credential managers are approved and enforce device compliance on the sync account.
5. Reduce endpoint exposure.
- Block or alert on browsers launched with remote debugging flags outside developer workflows; manage browser extension allowlists and monitor force-install registry paths.
- Keep infostealer coverage current in your EDR — session-cookie and password-manager theft is the most common precursor to these techniques.
6. User awareness, updated for 2026. Train users that passkeys are not self-defending: never approve an unexpected authentication prompt, treat any "re-register your passkey" request as phishing, and verify passkey reset requests through a known channel.
Review the full Token research write-up via the source reporting and map each of the 39 methods against your own deployment's enrollment, sync, recovery, and session architecture — most organizations will find at least one trust boundary with no compensating control.
Related Resources
Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.