How should security teams use passkeys to reduce account takeover fraud?

Why This Matters for Security Teams

Passkeys help most when account takeover is really a transaction takeover. Password resets, OTP relay, and session theft often succeed because the backend treats a logged-in user as trusted for too long. A device-bound passkey assertion changes that by forcing a fresh cryptographic check before the highest-risk action is committed. That aligns with the broader move toward stronger identity assurance in NIST Cybersecurity Framework 2.0 and with NHIMG guidance on narrowing the blast radius of compromised identities in the Ultimate Guide to NHIs.

The practical mistake is deploying passkeys only at login while leaving payout, reroute, recovery, and export paths protected by weaker, reusable session state. In fraud-heavy environments, that gap matters more than the initial sign-in method. NHIMG research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a useful reminder that attackers prefer the weakest downstream credential or control, not the strongest one at the front door.

In practice, many security teams encounter passkey failures only after a hijacked session has already authorized the damaging step, rather than through intentional step-up design.

How It Works in Practice

Use passkeys as a step-up control tied to business-critical actions, not as a blanket replacement for every authentication event. The backend should request a fresh passkey assertion when the user attempts something that changes money movement, account ownership, recovery settings, contact details, or data export. That assertion should be device-bound, phishing-resistant, and short-lived enough to confirm real user intent at the moment of risk.

That pattern works best when combined with transaction context. For example, the policy engine can require a passkey only if the action exceeds a threshold, originates from a new device, occurs in a new geography, or touches a high-risk recipient. This is consistent with modern identity guidance from NIST CSF 2.0, which emphasizes risk-aware control selection rather than one-size-fits-all authentication.

• Bind the passkey challenge to the exact action, amount, destination, or recovery event.
• Require a fresh assertion after sensitive state changes, not just at initial login.
• Prefer passkeys for high-risk steps over SMS or email OTP, which can be relayed or intercepted.
• Log the attestation, device posture, and decision outcome for fraud and incident review.
• Use rate limits and anomaly detection so repeated failures trigger containment, not endless retries.

NHIMG’s GitLocker GitHub extortion campaign is a reminder that attackers often exploit the weakest adjacent control after access is gained, so passkeys should gate the action itself, not merely the session. These controls tend to break down when legacy workflows depend on unattended browser sessions, shared support tooling, or recovery paths that cannot prompt for a fresh assertion.

Common Variations and Edge Cases

Tighter passkey enforcement often increases user friction, so organisations must balance fraud reduction against help-desk load, checkout abandonment, and accessibility requirements. Best practice is evolving, but current guidance suggests using passkeys selectively where the fraud cost is highest instead of forcing them on every low-risk interaction.

Shared devices, call-centre assisted recovery, and customer environments without passkey-capable hardware are the hardest cases. In those scenarios, teams may need fallback controls such as device reputation, transaction signing, or supervised recovery workflows, but those fallbacks should be narrower and more heavily monitored than the primary passkey path. This is especially important when attackers try to move from one verified session into password reset or account recovery, because the fraud objective often shifts from access to irreversible change.

Passkeys also do not solve poor authorization design. If a stolen session can still export data, add a new payee, or disable alerts without a new challenge, the fraud window remains open. That is why security teams should pair passkeys with step-up authorization, session revalidation, and short-lived trust. NHIMG’s Ultimate Guide to NHIs is relevant here because the same least-privilege logic applies: reduce standing trust, require reauthentication for high-impact actions, and avoid long-lived credentials wherever possible.

Related resources from NHI Mgmt Group

• How should security teams use browser controls to reduce account takeover risk?
• How should security teams use SCIM to reduce account sprawl?
• How should security teams reduce fraud risk in account recovery workflows?
• How should security teams reduce help desk account takeover risk?