They should base the decision on the sensitivity of the service, the measured error profile, and the harm caused by both false accepts and false rejects. Higher assurance usually means more friction, but not every use case needs the same balance. The key is to document the policy, test it against real performance, and revisit it as model quality changes.
How to choose the right assurance level without making the experience unusable
The best IDV teams treat assurance as a design choice, not a slogan. The right level depends on the sensitivity of the service, who can be harmed if identity is wrong, and how much inconvenience the business can tolerate before abandonment or support burden starts to outweigh the gain.
That means the decision should start with the transaction, not the channel. A high-value account recovery flow, payment authorization, or regulated onboarding step usually justifies more friction than a low-risk newsletter signup or a low-privilege self-service action.
It also means “more friction” is not automatically “better security.” The goal is to make the verification step proportionate to the downstream impact of an error, while keeping the experience simple enough that legitimate users can complete it reliably.
How error rates should shape the trade-off
Two error types matter, and they do not carry the same business cost in every context. False accepts can create fraud, account takeover, compliance exposure, or unauthorized access. False rejects create drop-off, manual review load, customer frustration, and sometimes exclusion from critical services.
Teams should evaluate the measured error profile of each assurance method in the real environment, not just the vendor demo. A control that looks strong on paper may fail in practice if it creates too many retries, cannot handle edge cases, or performs poorly for the actual population being served.
That is why the most useful question is not “Which method is strongest?” but “Which failure mode is more damaging here, and at what rate does it occur?” If the cost of a false accept is severe, stronger checks are justified. If false rejects dominate and the service is low risk, a lighter path may be the better control.
What good policy looks like in practice
Good IDV policy is explicit, testable, and tied to evidence. It defines which user journeys need stronger checks, what minimum assurance is acceptable, and what happens when the system cannot reach confidence with enough reliability.
For service owners, that policy should be backed by measurement rather than intuition. Review completion rates, fallback usage, manual override rates, and post-verification incident data together, because a single metric rarely captures the full balance between assurance and friction.
The policy also needs a review cycle. Model quality, fraud patterns, user behaviour, and business tolerance all change over time, so the chosen balance should be revisited when the observed error profile changes materially. If the service becomes more sensitive, or if abuse rises, the friction budget should change with it.
Risk and Threat Considerations
When assurance is set too low, identity proofing and step-up checks become an easy target for fraudsters, impostors, and account takeover attempts. When it is set too high, legitimate users may be pushed into workarounds, abandonment, or support channels that create their own operational and security exposure.
Failure mechanism: The control fails when teams optimise for either conversion or security in isolation, rather than comparing the real cost of false accepts and false rejects for the specific use case. In that situation, attackers exploit weak assurance, or the organisation creates avoidable friction that users bypass or cannot complete.
Impact: The result can be fraud loss, unauthorized access, higher manual-review costs, regulatory problems, or exclusion of legitimate users from critical services. Over time, poorly tuned assurance also erodes trust in the identity process because users learn where it can be gamed or where it is unnecessarily hard to complete.
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 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 | Sets assurance and verification trade-offs for identity proofing and authentication. |
| Recommendation — Use assurance levels to match verification strength to the sensitivity of the identity event. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Identity assurance decisions depend on how strongly users are authenticated before access is granted. |
| IA-8 — Identification and Authentication (Non-Organizational Users) | External user identity proofing and authentication are central when balancing friction against assurance. | |
| IA-9 — Service Identification and Authentication | Service-to-service assurance must balance stronger trust with operational complexity and friction. | |
| Recommendation — Apply stronger user authentication where the service impact of a wrong identity decision is high. Calibrate external-user identity verification to the risk of the specific journey. Use stronger service authentication only where the operational risk justifies it. | ||
Practitioner Guidance
What to prioritise: Start with the highest-consequence journeys, especially recovery, enrollment, payment, and privilege changes. Those are the places where a stronger check usually pays for itself, because a single identity mistake can have outsized impact.
What to verify: Make sure the team is using real operational data, not only assumed threat models. You should be able to show measured completion rates, escalation rates, false accept indicators, and the business rationale for the chosen threshold.
Decision rule: If the service can tolerate a mistaken deny more than a mistaken allow, keep friction lower and rely on step-up controls where needed. If a mistaken allow creates material harm, accept more friction, but only for the flows that actually need it.
Practitioner takeaway: The right balance is usually not one global setting, it is a tiered policy that matches assurance to transaction risk and is revised when actual performance changes.
Related resources from NHI Mgmt Group
- How should organisations choose between lower friction liveness checks and stronger presence assurance for remote identity verification?
- How should teams decide between passwordless convenience and stronger identity assurance?
- How should fraud and IAM teams decide whether to prioritise friction or stronger assurance?
- How should security teams implement stronger authentication without creating more user friction?