Security teams should use step-up verification only when risk justifies it, instead of forcing every return user through the same friction. The goal is to recognize trusted devices early, reduce repeated logins, and preserve checkout flow while still adding extra checks for sensitive actions. That approach improves conversion without abandoning account takeover and payment fraud controls.
How return-user friction should be shaped
For customer-facing apps, the right balance is usually not “more controls” or “less controls,” but controls that adapt to the transaction. A returning user who is on a familiar device and performing low-risk activity should move quickly, while the same user should face stronger checks when the request changes risk, value, location, device trust, or account state. That keeps authentication proportional to the actual exposure.
The practical test is whether the user journey gets harder only when the app has a reason to doubt the session or the action. If every return visit is treated like first-time access, teams create unnecessary abandonment. If every return visit is trusted by default, they create a path for account takeover, payment abuse, and fraud escalation.
- Use stable device recognition and session continuity to avoid re-prompting users who have already established trust.
- Reserve step-up checks for high-impact actions such as payout changes, password resets, new payees, card changes, or unusual login patterns.
- Design the policy so that the strongest friction appears at the highest-risk moments, not at the start of every journey.
This is one of the places where identity assurance and fraud control overlap in practice: the app needs enough certainty to reduce repeat prompts, but not so much trust that it cannot challenge suspicious behaviour when the session changes shape.
What good control design looks like in practice
Good customer-facing fraud control is context-aware. It should use a combination of device history, session age, behavioural signals, transaction sensitivity, and account risk to decide when to challenge the user. That makes the experience feel smoother for legitimate customers while still forcing an attacker to cross additional hurdles when a session or device does not fit the expected profile.
Teams should also separate “recognition” from “approval.” Recognizing a trusted device can reduce login friction, but it should not automatically grant full action authority. A returning user may be allowed to browse, add items, or resume checkout with minimal interruption, yet still be challenged before irreversible or financially sensitive actions are completed.
That distinction matters because fraud rarely presents as a single event. It often begins with a tolerated session, then moves into credential reuse, session hijack, or low-friction account manipulation. For that reason, the control objective is not to eliminate friction entirely, but to place it where it changes the attacker’s economics most.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 — Identity and Credential Management | Balances user convenience with controlled access decisions. |
| PR.AC-4 — Access Permissions and Authorizations | Step-up checks should gate sensitive actions and elevated access. | |
| Recommendation — Apply PR.AC-1 to manage trust in returning users without weakening access decisions. Use PR.AC-4 to require stronger verification before high-risk transactions. | ||
| CIS Controls v8 | 5.1 — Establish and Maintain an Inventory of Accounts | Returning-user journeys depend on accurate account and session recognition. |
| 6.3 — Require MFA for Externally-Exposed Services | Strong verification is needed when user risk rises or exposure increases. | |
| Recommendation — Maintain account inventory so trusted-user handling stays accurate and reviewable. Require MFA or step-up verification when exposure or risk crosses the threshold. | ||
Practitioner Guidance
What to verify: Measure whether step-up prompts are tied to a documented risk signal, not just to login count or page type. If your controls challenge low-risk returning users more often than suspicious ones, the policy is probably too blunt.
What to measure: Track checkout completion, repeat-login rate, step-up challenge frequency, and fraud loss or account takeover rate together. A smoother journey that raises fraud is not a win, and a strict control that destroys conversion is usually miscalibrated.
Common mistake: Treating “trusted device” as a permanent trust decision. Device familiarity should reduce friction, but it should expire, degrade, or be re-evaluated when the user changes device posture, network, or action sensitivity.
Decision rule: If the action can move money, change recovery paths, or weaken future access, require stronger verification even when the user appears to be returning normally. If the action is low impact, avoid forcing a challenge that adds no meaningful protection.
Practitioner takeaway: The best balance is dynamic trust, not static convenience, because the user experience should stay smooth until the request becomes valuable enough to justify friction.
Related resources from NHI Mgmt Group
- How can security teams balance user experience with stronger identity controls?
- How should security teams balance fraud prevention with customer conversion?
- How should security teams balance fraud friction with user experience?
- How should security teams implement strong authentication controls across web apps and pipelines?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
