How should fraud teams and IAM teams share responsibility for step-up decisions?

Why This Matters for Security Teams

Step-up decisions sit at the point where fraud prevention, identity assurance, and access governance meet. If fraud analysts can flag suspicious behaviour but cannot influence access policy, the organisation may detect risk too late to stop account takeover, payment abuse, or recovery fraud. If IAM can challenge users without risk evidence, step-up becomes noisy, frustrating, and easy to bypass through exceptions.

The practical issue is not whether to challenge more often, but how to make the challenge decision defensible, consistent, and reversible. Current guidance across identity and security programmes points toward shared decisioning with clear accountability: fraud owns the signal quality and case context, while IAM owns the control action and the policy lifecycle. That division supports auditability and avoids informal decisions made in chat threads or manual overrides that never reach policy. NIST’s control expectations around access enforcement and monitoring are a useful baseline here, especially when mapped through NIST SP 800-53 Rev 5 Security and Privacy Controls.

In practice, many security teams encounter weak step-up governance only after an account recovery abuse case, rather than through intentional policy design.

How It Works in Practice

A workable model starts with a shared decision matrix that separates evidence from enforcement. Fraud teams define the risk inputs, thresholds, and case enrichment that justify a higher-friction action. IAM teams translate those thresholds into policy outcomes such as step-up authentication, transaction challenge, temporary block, session revalidation, or manual review. The key is to make the action deterministic enough for operations, but flexible enough to respond to evolving fraud patterns.

In mature environments, the two teams typically agree on a control catalogue and the lifecycle for each decision. That includes how signals are scored, how long a challenge remains valid, what events retrigger evaluation, and when a user can self-remediate versus being routed to an analyst. The model should also define who can override a decision, under what evidence, and how overrides are logged for audit and tuning. For access and privilege boundaries, the zero trust model is often a useful reference point, particularly when challenge decisions need to be tied to session risk rather than static identity state. CISA’s guidance on identity-centric security is helpful when shaping those boundaries, and NIST’s digital identity guidance reinforces the need for assurance-aligned authentication decisions through NIST SP 800-63 Digital Identity Guidelines.

• Fraud owns the detection logic, case metadata, and outcome severity.
• IAM owns the authentication policy, orchestration, and access enforcement.
• Both teams agree on thresholds, review SLAs, and escalation paths.
• All overrides, exceptions, and manual approvals are logged and periodically reviewed.
• Metrics should track false positives, challenge abandonment, recovery abuse, and downstream loss.

In payment and recovery flows, the best practice is to tie step-up to the highest-risk action rather than the first suspicious signal, because over-challenging low-risk activity creates user friction without improving loss prevention. These controls tend to break down when fraud signals arrive after the session has already been issued, because the IAM policy engine has no live mechanism to re-evaluate trust mid-flow.

Common Variations and Edge Cases

Tighter step-up control often increases customer friction and analyst workload, requiring organisations to balance loss prevention against conversion, support cost, and recovery time. That tradeoff is especially visible in consumer banking, fintech, and marketplace environments where false positives directly affect revenue and retention.

There is no universal standard for how often fraud should be allowed to trigger step-up, but current guidance suggests using risk-based triggers with clearly bounded authority. Some organisations let fraud request a challenge while IAM decides whether the request is enforceable based on authentication state, device trust, and session context. Others move to a shared policy board for high-impact changes, especially when recovery, high-value payments, or privileged account access are involved.

Edge cases often appear when the user is legitimate but high-risk, such as a new device after travel, an unusual recovery request, or a payment from a previously unseen channel. In those cases, teams should prefer graduated responses: verify first, limit transaction scope second, and block only when confidence is high. For regulated environments, the logging and review process should support accountability under broader control frameworks such as NIST SP 800-53 Rev 5 Security and Privacy Controls and identity assurance expectations from NIST SP 800-63 Digital Identity Guidelines.

Best practice is evolving for how much real-time fraud telemetry should directly mutate IAM policy, but the consistent requirement is clear: if the teams cannot explain who can trigger a challenge, who can approve an exception, and how the decision is audited, the operating model is too ambiguous to trust.

Related resources from NHI Mgmt Group

• How should IAM teams respond to multi-step identity fraud?
• How should security and IAM teams share responsibility for in-person identity checks?
• How do IAM and platform teams share responsibility for API security?
• How do platform and IAM teams share responsibility for workload identity?