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

At a glance

What this is: This is an analysis of how passkeys and step-up authentication reduce fraud by binding high-risk actions to the registered device and origin.

Why it matters: It matters because IAM and security teams need controls that prove action legitimacy, not just password possession, across human login flows and sensitive transactions.

By the numbers:

• Supply chain crime losses surged to nearly $725 million in 2025, a 60% jump from the year before.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.

👉 Read Descope's analysis of passkeys for fraud prevention and step-up auth

Context

Passkeys are a fraud control because they replace shared secrets with device-bound cryptographic assertions. That matters for IAM teams because passwords and OTPs can be reused, relayed, or phished, while a passkey response is tied to the registered origin and the registered hardware.

The article frames a common problem that crosses consumer identity, enterprise login, and high-risk transaction approval: an attacker gets a legitimate session and uses it to complete a costly action. The governance question is not whether authentication happened, but whether the action was still being performed by the original user on the original device.

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 passkeys reduce fraud better than passwords or SMS codes?

A: Passkeys reduce fraud because they bind the authentication ceremony to the registered device and the registered origin. Passwords and SMS codes can be phished, relayed, or replayed from another machine. A passkey response cannot be completed without the original device, which sharply limits remote misuse.

Q: What breaks when high-risk actions rely only on login authentication?

A: The workflow assumes that the person who logged in is still the person initiating the sensitive action. That fails when an attacker takes over the session from another device and waits until the user reaches a valuable action. The fix is not stronger login alone, but action-level verification.

Q: Who should require step-up authentication for sensitive transactions?

A: Any team that handles irreversible actions should require step-up authentication, including payments, logistics, privileged admin work, and sensitive data changes. The right owner is the team that can quantify the loss from a fraudulent commit, because that is where assurance should increase before execution.

Technical breakdown

How passkeys bind authentication to device and origin

Passkeys use FIDO2 and WebAuthn so the private key stays on the user’s device and the server only stores the public key. During authentication, the device signs a server challenge, and the browser enforces origin matching so a spoofed domain cannot reuse the ceremony. That removes the shared secret from the login flow and makes replay from another machine materially harder. The security property is not just stronger password replacement, it is a proof of possession plus origin binding that survives phishing attempts only when the attacker has the registered device. Practical implication: treat passkeys as an authentication primitive with fraud value, not just a login convenience feature.

Practical implication: map passkey enrollment to the applications where credential theft causes direct financial or operational loss.

Step-up authentication for high-risk actions

Step-up authentication adds a second assertion only when the user reaches a sensitive action such as a transfer, reroute, or privileged data change. In this pattern, the initial login can be ordinary, but the backend requires a fresh passkey assertion before committing the action. The session then carries an explicit signal, such as an upgraded claim, that the protected endpoint checks before execution. This is a better fit for fraud than uniform MFA because the control is aligned to action risk, not just login risk. Practical implication: design step-up around irreversible actions and verify the claim on every sensitive endpoint.

Practical implication: place the trust check at the transaction boundary, not only at the authentication boundary.

Why device presence matters more than knowledge factors

Passwords and SMS OTPs fail because they prove knowledge of a secret, not the presence of the registered device. That distinction matters when an attacker is operating from a different machine after phishing the user or replaying an OTP in real time. Passkeys raise the cost of remote fraud because the private key cannot be lifted from a credential dump and cannot be replayed elsewhere. The result is a narrower fraud surface for account takeover, payment abuse, and privileged action abuse. Practical implication: use device-bound factors where the consequence of a stolen session is a high-value action, not just a login.

Practical implication: reserve lower-assurance methods for low-risk access and move sensitive actions to device-bound verification.

Threat narrative

Attacker objective: The attacker wants to authorize a financially or operationally damaging action while appearing to be the legitimate user.

1. Entry occurs when an attacker phishes a legitimate user and captures credentials on a fake login page or through a relayed OTP flow.
2. Escalation happens when the attacker uses the stolen session from a different device and reaches a sensitive action such as a reroute, transfer, or privileged change.
3. Impact follows when the platform cannot distinguish the impostor from the real user and allows a costly, irreversible action to complete.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Passkeys shift fraud prevention from secret protection to action legitimacy. The article is right to treat login as only the first half of the problem. For identity programmes, the decisive control is whether a high-risk action can still be linked to the same device that performed the authentication. That moves the discussion from password replacement into transaction assurance, which is where fraud actually materialises. Practitioners should evaluate authentication by what it proves at the point of action, not by how many factors a login screen collects.

Device-bound verification weakens the entire replay economy. Passwords, SMS OTPs, and relayed codes all depend on a secret being transferable. Passkeys break that assumption because the private key is non-exportable and origin-bound, so the attacker’s stolen artefact is no longer enough to complete the ceremony. That changes fraud economics across consumer identity, privileged access, and high-value workflow approvals. IAM teams should treat device binding as a control that collapses remote reuse, not just as a stronger authenticator.

High-risk workflows need authentication at the transaction boundary, not only at login. The article’s step-up pattern captures the right governance idea: not all actions deserve the same assurance level. A user can authenticate once and still require fresh proof before a wire, reroute, or privileged data export. That is a stronger model than assuming session trust is uniform across the application. Practitioners should redesign sensitive workflows so the protected action, not the login event, determines the control.

Fraud control and IAM control are converging on the same question: who is actually acting? This is why passkeys matter beyond consumer authentication. The same assurance gap appears whenever a valid session can be reused from a different device or channel to trigger irreversible work. NIST CSF and ZT-NIST-207 both push continuous verification logic, but the practical lesson is sharper here: identity assurance must survive the handoff from user presence to action execution. Teams should align governance, risk, and product decisions around that handoff.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• That same report found that only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For the next step, compare this fraud-control pattern with the Ultimate Guide to NHIs to see how device-bound assurance fits broader identity governance.

What this signals

Device-bound step-up is becoming a governance control, not just an authentication upgrade. Once fraud moves from login theft to action theft, programmes need to decide where the sensitive boundary actually sits. That means authentication, transaction approval, and session assurance can no longer be managed as separate concerns. Teams that still measure success only at sign-in will miss the real control failure at commit time.

Passkeys also expose a broader identity pattern: the more valuable the action, the less tolerance there is for reusable secrets. The article’s logic aligns with wider NHI governance lessons from the Ultimate Guide to NHIs, where shared credentials create reusable attack paths. Human identity and machine identity teams should converge on the same principle when the consequence of reuse is irreversible loss.

Action assurance will matter more as AI agents and automated workflows touch human transactions. If a workflow can be initiated by software and completed by a human session, organisations will need to prove both who authenticated and what actually authorised the action. That is where device presence, step-up claims, and transaction-bound controls become part of the identity architecture, not just the fraud stack.

For practitioners

• Prioritise passkey step-up for irreversible actions Start with workflows where a fraudulent commit creates direct loss, such as payment release, shipment reroute, privileged export, or account recovery. Require a fresh passkey assertion before the backend accepts the action, and make the protected endpoint check the upgraded session claim every time.
• Map your fraud model to the action boundary Identify where attackers gain value after login rather than during login. Then place the strongest control at that point, because the real risk is not authentication success alone but unauthorised completion of a consequential action.
• Use device-bound assurance for high-value accounts Reserve passkey-based step-up for users or roles where stolen sessions can trigger payment, logistics, data export, or privileged changes. That gives you stronger friction only where the business consequence justifies it.
• Review which legacy factors still allow replay Trace whether SMS OTP, recovery codes, or shared secrets can be relayed from another device and still satisfy the workflow. Where replay is possible, move those paths behind stronger device presence checks.

Key takeaways

• Passkeys matter most when they are tied to sensitive actions, not only to sign-in.
• The main fraud problem is reusable secret abuse, and device-bound authentication directly narrows that attack path.
• Teams should place step-up controls at the transaction boundary where a stolen session can still cause loss.

Key terms

• Passkey: A passkey is a phishing-resistant authentication method that uses public-key cryptography instead of a shared secret. The private key stays on the user’s device and the server verifies a signed challenge with the public key, which makes credential replay and phishing far harder than password-based login.
• Step-up authentication: Step-up authentication is a pattern that requires extra proof only when a user reaches a sensitive action. It is not a different login system. It raises assurance at the transaction boundary so high-risk actions can be blocked unless the current session proves stronger device or user presence.
• Device binding: Device binding means the authentication proof is tied to a specific device or hardware-backed key and cannot be reused from another machine. In practice, it reduces the value of stolen credentials because the attacker still lacks the registered device needed to complete the ceremony.
• Account takeover: Account takeover is the misuse of a legitimate user account after an attacker gains access to the login flow or session. It matters because the attacker can look like the real user while authorising actions that the user did not intend, which is why action-level controls are often required.

What's in the full article

Descope's full blog post covers the operational detail this post intentionally leaves for the source:

• A step-by-step passkey step-up flow for Descope implementations, including the sign-up and challenge sequence.
• Backend checks for the su:true claim that determine whether a sensitive action can proceed.
• Flow editor and SDK implementation details for registering passkeys and triggering step-up.
• Examples of how the pattern applies to freight reroutes, bank transfers, and privileged admin actions.

👉 The full Descope post shows the passkey step-up flow, backend verification logic, and freight fraud example in detail.

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 responsible for identity security strategy or governance maturity in your organisation, it is worth exploring.