The relationship between higher identity assurance and the effort required from the user to complete the journey. As assurance rises, so does the number of checks, which can improve confidence but also reduce completion if the design is not managed carefully.
How the trade-off works
Assurance to friction is a design tension, not a binary choice. Each extra identity check, step-up prompt, or proofing requirement can raise confidence that the right person is completing the journey, but it also adds time, cognitive load, and abandonment pressure.
The key issue is that users do not experience controls as abstract security value. They experience them as delay, interruption, and uncertainty, so the same safeguard can be helpful in one journey and harmful in another. The best outcomes usually come from aligning assurance level with the actual risk of the transaction, rather than applying the same bar everywhere.
Where friction becomes a security and business problem
Friction is not only a usability concern. When a journey becomes too hard, users may bypass it, reuse weaker paths, or request exceptions, which can quietly weaken the control environment. Overly heavy assurance can also push legitimate activity into channels that are less observable or less governed.
For high-value or sensitive actions, the cost of false acceptance is often greater than the cost of some user drop-off. For lower-risk actions, however, unnecessary checks can reduce completion without delivering meaningful security gain. That is why assurance design is really a control-sizing problem, not just an authentication problem.
Frameworks for digital identity make this balancing act explicit. NIST SP 800-63 Digital Identity Guidelines is useful here because it ties identity assurance to the strength of proofing, authentication, and the risk of the transaction being protected.
What drives the amount of friction
Friction comes from several sources: more factor prompts, stronger identity proofing, reauthentication at sensitive moments, device or session checks, and manual review where automation cannot confidently decide. The more exceptional the request, the more likely the journey needs step-up controls.
Context matters as much as control strength. A well-designed flow can preserve confidence while reducing disruption by only increasing assurance when the user, device, location, or transaction changes in a way that meaningfully increases risk. Poorly designed flows do the opposite, treating every action as equally dangerous.
This is why assurance design should be examined alongside broader governance and control selection. The Audit, Assurance and Compliance Guide is a useful reference point when teams need to connect identity decisions to evidence, control intent, and reviewability.
How to think about the trade-off in practice
The most effective approach is to decide where higher assurance is essential, where it can be adaptive, and where it is simply overkill. That usually means reserving the heaviest checks for actions with real security, financial, or data sensitivity, while keeping low-risk journeys as smooth as possible.
Practitioners should also remember that assurance is not just a technical property. It is a journey property. A control that is theoretically strong but routinely frustrates legitimate users may create a weaker real-world outcome than a slightly lighter control that is actually completed.
Good assurance design therefore aims for proportionality: enough friction to create trust in the decision, but not so much that the journey becomes unusable.
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 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IAL — Identity Assurance Level | Defines assurance strength for identity proofing and authentication. |
| AAL — Authenticator Assurance Level | Sets authentication strength appropriate to the required confidence level. | |
| FAL — Federation Assurance Level | Covers assurance in federated sign-in flows where trust and friction must be balanced. | |
| Recommendation — Match assurance requirements to transaction risk and step up only when the action justifies it. Select an authenticator level that fits the sensitivity of the journey and the protected action. Apply federation assurance requirements when the journey depends on an external identity assertion. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication, and Access Control | Addresses identity and access controls that shape user friction and trust decisions. |
| GV.RM-01 — Risk Management Strategy | Supports deciding where higher assurance is warranted based on business risk. | |
| Recommendation — Tune identity and access controls so they improve confidence without creating unnecessary drop-off. Use a risk strategy to decide which journeys deserve stronger checks and which do not. | ||