Passkeys are closing the fraud gap in high-risk login flows

At a glance

What this is: This article argues that passkeys and step-up authentication reduce fraud by binding sensitive actions to a registered device and a fresh passkey assertion, not just to a login secret.

Why it matters: IAM, fraud, and PAM teams should treat high-risk action approval as an authentication design problem, because device-bound proof changes what a compromised session can do.

Context

The security gap here is not login friction, it is the assumption that a successful sign-in proves the right actor is now operating the account. In fraud-heavy flows, that assumption fails because phishing, credential stuffing, and replayed OTPs can still produce a valid session from the wrong device.

Passkeys change the identity signal by binding authentication to the original device and origin, which makes them relevant wherever a compromised account can trigger a costly action. For identity governance teams, that pushes the control discussion from password replacement toward proof of device presence at the moment of action.

Key questions

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

A: Use passkeys first on the actions that create the most damage if a session is hijacked. They work best when the backend requires a fresh device-bound assertion before a transfer, reroute, export, or recovery step is committed. That way, a stolen password or relayed OTP cannot complete the transaction.

Q: Why do passwords and OTPs fail to stop account takeover fraud?

A: They prove knowledge of a secret, not presence on a specific registered device. Passwords can be phished, leaked, or stuffed, and OTPs can be relayed in real time. If the attacker can log in from another machine, the account can still be used for harmful actions unless a stronger, device-bound control is required at the action layer.

Q: What breaks when email authentication is not enforced for sensitive workflows?

A: When email authentication is weak, attackers can spoof trusted senders, hijack password resets, and manipulate approvals or payments. The result is not only mailbox compromise but business-process compromise, because recipients act on messages that appear legitimate. Organisations should treat authenticated email as a control for both fraud prevention and operational integrity.

Q: What should teams do immediately when a passkey-based step-up flow is not available?

A: Treat the action as too risky to inherit the base login state alone. Add a separate proof requirement before the request can commit, and keep the elevated state short-lived. If the application cannot re-check device-bound assurance at the decision point, the safer choice is to slow or block the action until that control exists.

Technical breakdown

Why phishing-resistant authentication changes the fraud model

Passkeys use public-key cryptography through FIDO2 and WebAuthn, so the private key never leaves the registered device. The server challenges the device, the device signs the challenge, and the server verifies the signature against the stored public key. That means there is no reusable shared secret for attackers to steal, relay, or stuff into another session. In fraud terms, this removes the usual remote path from credential capture to action execution. The important distinction is that passkeys do not merely strengthen login. They change the evidentiary value of authentication by making proof dependent on possession of the registered hardware and the browser origin where the key was enrolled. Practical implication: treat passkeys as an assurance upgrade, not a cosmetic login replacement.

Practical implication: Use passkeys where a valid login can directly enable irreversible or high-value actions.

How device binding and origin binding block replay

Two properties do most of the work here. Device binding makes the private key non-exportable, usually backed by secure enclave or TPM hardware, so the credential cannot be copied into a phishing kit or a fresh VM. Origin binding means a passkey registered for one domain will not answer a challenge from a lookalike domain, because the browser enforces the origin check in the protocol itself. That is why passkeys are materially different from passwords and OTPs. A stolen password can be replayed anywhere, and an OTP can be proxied in real time. A passkey assertion only succeeds when the request originates from the correct site on the correct device. Practical implication: target spoofed-domain and session-replay fraud paths first when defining where passkeys matter.

Practical implication: Prioritise flows where phishing pages and relay attacks are the dominant compromise pattern.

Why step-up auth belongs at the action layer

Step-up authentication works because not every action carries the same risk. A low-risk browse session can continue with the base login, but a transfer, reroute, or privileged data export should require a fresh assertion before the action is committed. In this pattern, the backend checks for a step-up claim, such as su:true, before allowing the request through. If the attacker is operating from a different device, the passkey challenge fails and the action stops even though the session exists. This is where fraud control becomes more precise than generic MFA. The relevant security question is no longer whether the user logged in, but whether the actor can re-prove possession of the registered device at the decision point. Practical implication: move authentication checks to the exact endpoint where loss occurs.

Practical implication: Require a fresh passkey assertion before approving sensitive transactions or administrative changes.

NHI Mgmt Group analysis

Passkeys close a fraud gap, but they do so by changing the assurance model rather than by solving identity on their own. The key shift is from secret possession to hardware-backed, origin-verified proof at the moment of action. That matters because fraud losses usually happen after login, not at login. Practitioners should stop evaluating authentication controls only by sign-in strength and start measuring whether the actor can still authorise the consequential transaction.

Step-up authentication is the right control shape for high-risk actions because the risk is not uniform across the session. Login, browsing, and transaction approval are different trust moments, so they should not share the same assurance bar. Passkeys fit this model because they are fast enough to be used at the decision point and strong enough to break replay-based fraud. The implication for governance is that access policy has to distinguish session establishment from action authorization.

Device-bound authentication creates an identity blast radius limit that passwords and OTPs cannot provide. When the proof is tied to a single registered device, a stolen credential does not automatically become a reusable enterprise-wide access token. That narrows the blast radius of account takeover and makes the compromised session materially less useful to the attacker. The practical conclusion is that fraud prevention should be designed around what an attacker can do after authentication, not only how they got in.

Fraud teams and identity teams are converging on the same control problem. A reroute, transfer, or privileged export is now both an access decision and a fraud decision, which means the control owner cannot live only in application security or only in IAM. Passkey step-up patterns force that convergence into the architecture itself. Organisations that keep these controls separate will continue to leave the highest-risk action path underprotected.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• U.S. fraud losses are projected to reach $40 billion by 2027.
• Read next: AI Agent Authorisation Guide

What this signals

Action-level assurance is becoming the real boundary for fraud prevention: login success is no longer a sufficient signal when the loss happens later in the workflow. Teams should review where their applications still treat session validity as permission to commit value-bearing actions, because that is where passkeys and step-up controls matter most.

The practical shift is architectural, not cosmetic. Identity programmes that only modernise authentication at sign-in will keep missing the point if they do not also govern sensitive actions, elevated session state, and backend enforcement together.

For practitioners

• Map high-risk actions first Identify the endpoints where a valid session can create irreversible loss, such as transfers, reroutes, exports, role changes, or approval workflows.
• Require fresh passkey assertion at the action boundary Trigger a step-up challenge before the sensitive commit, and deny the request unless the backend receives the expected step-up claim.
• Separate login assurance from transaction assurance Keep base authentication lightweight for routine access, but enforce a stricter proof state only when the user crosses into fraud-sensitive activity.
• Tune session validity to the value of the action Use short step-up windows for high-stakes operations so the elevated state does not outlive the decision it was meant to protect.

Key takeaways

• Passkeys reduce fraud by making authentication device-bound and origin-verified, which removes the reusable secret that phishing and replay attacks depend on.
• The control gap is usually not login itself but the high-risk action that follows, such as a transfer, reroute, or privileged export.
• Fraud-resistant identity design should require fresh proof at the transaction boundary, because that is where stolen access turns into loss.

Key terms

• Passkey: A passkey is a passwordless credential based on public key cryptography. A private key stays on the user’s device, while a public key is stored by the service. During login, the device signs a challenge after local unlock, which reduces phishing and eliminates shared secret reuse.
• Step-up Authentication: Step-up authentication is an additional verification step triggered when a session becomes higher risk or a user attempts a sensitive action. It is used to reduce exposure without forcing extra friction across every interaction, which makes it useful for runtime access governance.
• Origin binding: A cryptographic property that ties an authentication response to the legitimate site or service being accessed. It reduces the value of fake login pages because a credential response generated for one origin cannot be reused on another without failing verification.
• Device binding: A control that links an authenticator or key pair to a specific endpoint so the same secret cannot be copied and reused elsewhere. It strengthens assurance, but the binding step itself becomes a high-value target if attackers can intercept the enrollment process.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.