Teams should apply step-up authentication selectively, based on risk signals such as device change, location anomaly, or suspicious transaction behaviour. The goal is to challenge only higher-risk sessions while keeping trusted returning users moving quickly. That balance reduces account takeover exposure without creating unnecessary abandonment, churn, or support burden for legitimate customers.
Why Step-Up Authentication Needs a Risk Threshold, Not a Blanket Rule
Financial services teams use step-up authentication to add friction only when the session, transaction, or device profile no longer looks ordinary. That matters because a broad challenge policy can protect against account takeover but also disrupt returning customers at exactly the point where speed, confidence, and completion rate matter most. The practical question is not whether to challenge users, but when the signal quality is strong enough to justify it. NIST’s identity guidance helps teams distinguish assurance decisions from routine sign-in handling, while still leaving room for policy judgement across channels and customer journeys. In practice, many teams discover the cost of over-challenging only after abandonment, support calls, and false-positive review queues have already grown.
How Risk-Based Challenge Decisions Work Across the Customer Journey
Step-up authentication works best when it is tied to a small set of measurable signals that meaningfully change confidence in the session. Typical triggers include device novelty, geolocation change, impossible travel patterns, new payee setup, unusual transfer size, credential reset history, or a transaction that deviates from the user’s normal behaviour. The control goal is not to inspect every event equally, but to route only the uncertain cases into a higher assurance path.
In practice, teams usually design this as a decision layer above the ordinary login or payment flow. Low-risk returning users move through with minimal interruption. Medium-risk sessions may see a softer challenge such as an out-of-band approval or a biometric check. Higher-risk events can be stepped up further, especially when the action is irreversible, high-value, or likely to be targeted by fraud. This is where the distinction between authentication and transaction approval becomes important: the user experience should reflect the risk of the action, not just the act of signing in.
Well-run programs also limit repeated challenges within a trusted window, because constant prompting teaches customers to expect friction and can undermine trust in the control itself. A useful design pattern is to separate identity confidence, device trust, and transaction sensitivity rather than treating them as the same thing. That allows teams to keep returning users moving while still escalating when the environment changes or the request becomes materially more sensitive. For control structure, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful when teams want to anchor adaptive access and monitoring decisions in a broader control set.
- Use step-up only when the signal changes the assurance level in a defensible way.
- Treat high-risk transactions differently from routine sign-in activity.
- Keep trusted-session rules short enough to preserve user confidence.
- Review false positives by journey stage, not just by authentication event.
This approach breaks down when risk scoring is opaque, when the challenge is more expensive than the transaction, or when the organisation cannot distinguish a genuinely risky event from normal customer behaviour.
Where Returning-User Convenience Can Undercut Security, and Where It Shouldn’t
Tighter authentication often increases abandonment and support load, requiring organisations to balance fraud reduction against customer effort. The hard part is not applying friction, but deciding where friction is justified and where it becomes self-defeating. For example, a returning customer on a familiar device may deserve a near-seamless path for balance checks or low-value activity, but the same user should not necessarily bypass a challenge for a new payee, a profile change, or a high-value transfer. NIST SP 800-63 Digital Identity Guidelines is the clearest reference here because it frames assurance and reauthentication as policy decisions linked to the transaction, not just the login.
There is also a real design tradeoff between step-up frequency and attack resilience. Too little friction makes account takeover easier to monetise once a session is stolen. Too much friction encourages password resets, help-desk dependency, and customer habituation to prompts. The best balance is usually contextual: increase friction when the user, device, or action meaningfully departs from normal, and keep the default path light when the risk signal remains stable. That is especially important in financial services, where a returning user may behave predictably for months and then suddenly perform a different action that deserves more scrutiny.
Teams should also recognise where consensus is still uneven. Some institutions prefer silent risk scoring with occasional challenge, while others use more visible progressive verification. The right choice depends on fraud exposure, customer expectations, and regulatory posture, not on a universal best practice. ISO/IEC 27001:2022 Information Security Management can help when the question is how to govern that policy consistently across business lines rather than how to tune one specific challenge screen.
Practitioner judgement matters most when convenience and assurance appear to conflict. If the control is meant to reduce abandonment but the same users are still being challenged repeatedly for routine behaviour, the policy is miscalibrated rather than merely strict.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | AAL — Authentication Assurance Levels | Maps step-up decisions to assurance proportional to risk and transaction sensitivity. |
| IAL — Identity Assurance Levels | Supports separating identity confidence from session convenience in financial journeys. | |
| Recommendation — Set reauthentication strength to match the action’s assurance need, not every returning login. Confirm identity confidence before allowing higher-risk account or profile actions. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | Covers adaptive access decisions and controlled challenge escalation in operations. |
| Recommendation — Apply adaptive access rules that increase challenge only when session risk rises. | ||
| CIS Controls v8 | 5 — Account Management | Relevant to managing authentication triggers, trusted sessions, and access lifecycle. |
| Recommendation — Tune account access controls so trusted users avoid unnecessary repeated prompts. | ||
| PCI DSS v4.0 | 8 — Identify Users and Authenticate Access to System Components | Applies where financial services flows must authenticate users before sensitive access. |
| Recommendation — Enforce stronger authentication when access or actions become materially more sensitive. | ||
Practitioner Guidance
What to prioritise: Separate routine returning-user access from risky transaction moments. Teams get the best outcome when they reserve stronger challenge for actions that change the customer’s financial exposure or the institution’s fraud exposure, not for every login.
What to verify: Check whether the trigger logic is actually detecting meaningful risk change, or simply reacting to noisy signals. A useful test is whether a challenge would still make sense if the user were already authenticated on a trusted device and only the transaction context changed.
What good looks like: Legitimate returning users complete ordinary tasks with minimal interruption, while higher-risk actions reliably encounter a stronger control path. The control should feel selective to the customer and defensible to the fraud team.
Common mistake: Treating step-up as a blanket anti-fraud measure. That usually produces more friction than protection, because it fails to distinguish ordinary continuity from genuinely elevated risk.
Practitioner takeaway: The strongest designs make friction invisible when confidence is high and unmistakable when confidence drops; once that balance is lost, both security and conversion suffer.
Related resources from NHI Mgmt Group
- How should financial services teams balance identity verification security with user experience?
- How should security teams balance fraud friction with user experience?
- How should security teams implement zero trust authentication without adding too much user friction?
- How should financial institutions balance DORA compliance with customer authentication experience?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
