They should prioritise whichever combination reduces overall risk without shifting the burden onto legitimate users. The decision should be based on conversion, fraud capture and assurance quality together, not on friction alone. If the architecture can verify both the person and the session in one flow, that usually outperforms adding extra manual steps.
How to choose between friction and assurance
Fraud and IAM teams should treat friction as a cost to be justified, not a goal to be minimised by default. The right choice depends on whether an added step measurably improves assurance, reduces fraud loss, and still preserves legitimate conversion. In practice, the best outcome is usually the one that increases confidence in the transaction or session without adding a separate user burden.
A useful decision rule is to ask whether the control improves digital identity assurance enough to change the fraud outcome. If the answer is yes, some friction may be warranted; if it only adds delay or abandonment, it is probably the wrong trade-off. Stronger assurance is most defensible when it reduces loss on high-value or high-risk journeys, or when the extra step can replace manual review rather than sit on top of it.
Another practical lens is whether the architecture can verify both the person and the session in one flow. That is usually better than layering multiple disconnected checks, because it reduces ambiguity about who acted, under what context, and with what continuity of trust. Where teams can bind login strength, device context, and transaction step-up together, they often get better assurance than from isolated friction points that do not improve decision quality.
Where friction becomes productive, and where it becomes waste
Friction is productive when it blocks a realistic fraud path, supports a decision that would otherwise be too uncertain, or allows the business to keep the transaction while raising confidence. It becomes waste when it is applied uniformly to low-risk users, when it does not change the verification outcome, or when it creates abandonment without meaningfully reducing exposure. CSA Cloud Controls Matrix is useful here because it frames identity and access controls as part of a broader trust and governance model, not as a standalone UI problem.
In fraud programmes, the distinction matters because “more friction” can hide weak assurance design. A second factor, a knowledge challenge, or a manual checkpoint only helps if it is matched to the threat path being defended against. If the attacker can reuse a session, hijack a recovery flow, or bypass a one-time prompt, the control may feel harder without being stronger.
For IAM teams, the key question is whether the added control changes the assurance level in a way the downstream fraud engine or policy can actually use. If it does not feed a better decision, the user pays the price and the organisation gets little back. That is why teams should evaluate friction alongside fraud capture, assurance quality, and operational cost in the same decision, not as separate conversations.
What good operating practice looks like
The strongest pattern is risk-based orchestration: use the lightest path that is still sufficient for the current risk, and reserve heavier verification for moments that truly need it. That usually means different treatment for new devices, anomalous sessions, high-value actions, account recovery, and step-up events. It also means using signal quality, not just policy strictness, to decide when to challenge the user.
Where identity controls are part of the answer, teams should align on a few measurable outcomes, such as fraud capture rate, false positive rate, conversion impact, and review load. The right balance is rarely revealed by friction metrics alone. A flow that feels smooth but misses fraud is not successful, and a flow that stops fraud but suppresses revenue or overwhelms support is also failing. Identity Security Programme Guide and IAM and Identity Provider Buyer’s Guide are helpful references when teams need to align identity design with business and risk outcomes rather than single-control optics.
Practitioner Guidance: Start by defining the transaction classes where assurance really changes loss, then measure whether each extra step improves that outcome more than it harms conversion. If a control does not materially improve fraud capture or confidence in the session, remove it or reserve it for higher-risk paths.
Practitioner takeaway: The best decision is rarely “more friction” or “less friction” in the abstract, but the control combination that gives the highest assurance per unit of user burden.
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, CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Assurance levels and authentication strength directly shape fraud-versus-friction trade-offs. |
| Recommendation — Use assurance targets to decide when stronger verification justifies added user friction. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | IAM controls govern how identity assurance and access decisions are balanced in practice. |
| Recommendation — Align IAM controls so step-up checks improve assurance without unnecessary user burden. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Authentication strength is central when deciding whether extra friction adds real assurance. |
| IA-5 — Authenticator Management | Credential and authenticator management affects whether assurance can rise without repeated friction. | |
| Recommendation — Strengthen authentication only when it measurably reduces fraud risk or improves decision quality. Manage authenticators so stronger assurance can be delivered with fewer repeat challenges. | ||
Related resources from NHI Mgmt Group
- How do IAM teams decide whether wallet-based age assurance is ready for production?
- How can IAM teams decide whether to prioritise continuous identity state?
- How do IAM and IGA teams decide whether to prioritise cross-system coverage?
- How should security teams prioritise NHI remediation in cloud environments?