They should treat the choice as a control balance, not a trade-off between security and convenience. Overly aggressive checks can drive abandonment, while weak workflows can invite fraud. The right approach is to collect only necessary data, keep the process understandable, and preserve strong validation underneath.
Why this is not a simple UX-versus-security choice
identity verification works best when user experience and assurance are designed together. If a flow is too friction-heavy, legitimate users abandon it or fail at the point of onboarding. If it is too loose, fraudsters gain a cheap path through the same funnel. The decision should therefore be made around the level of risk being accepted, not around convenience alone.
Strong verification is not only about adding more checks. It is about choosing the right evidence, in the right order, with enough clarity that honest users can complete the process and attackers cannot easily game it. Good flow design reduces confusion without reducing the strength of the underlying validation.
For teams building remote onboarding or KYC journeys, the practical benchmark is whether the flow still works for the intended user population while holding up under document fraud, impersonation, replay, and synthetic-identity abuse. NHIMG’s Identity Proofing and KYC Guide is the clearest internal reference point for balancing assurance levels, document checks, and liveness controls.
What stronger checks should actually be optimised for
Stronger checks should reduce fraud and impersonation, but they should not create unnecessary collection, unnecessary retries, or opaque rejection logic. In practice, the best flows collect only what is needed for the assurance level being targeted, explain why each step exists, and avoid asking users to repeat evidence that does not improve the decision.
This is where many programmes fail: they add steps because they are available, not because they materially improve confidence. The result is a longer path with little extra security value. A better approach is to separate the visible user journey from the strength of the verification engine underneath, so that the user sees a simple process while the decisioning remains robust.
That principle is consistent with the broader identity-verification market, where vendors are evaluated on proofing strength, fraud signals, liveness, and privacy. Teams comparing providers should anchor the evaluation to the actual control objective, not to the number of screen prompts. NHIMG’s Identity Verification Buyer’s Guide helps frame that vendor selection around document checks, liveness, and injection defence rather than cosmetic UX claims.
For regulated onboarding, stronger checks also need to map to a defensible assurance standard. That is why identity verification decisions should be tied to the accepted level of confidence for the transaction, account type, or fraud exposure rather than treated as a single universal workflow. External reference points such as NIST SP 800-63 Digital Identity Guidelines and FATF Recommendations are useful because they connect assurance and customer due diligence to the level of risk being managed.
How to balance conversion, assurance, and fraud resistance
The right balance is usually achieved by making the flow adaptive. Low-risk journeys can use lighter verification, while higher-risk cases trigger stronger checks, manual review, or step-up evidence. That avoids forcing every user through the most expensive path and keeps the strongest controls where they matter most.
Three design choices matter most. First, the flow should minimise unnecessary data collection, because extra data increases user resistance and privacy exposure. Second, the experience should remain understandable, because confusion drives abandonment and support load. Third, the verification engine should still enforce strong validation, because a smoother interface does not make a weak decision model safe.
When identity verification relies on digital documents, biometrics, or remote proofing, the threats are often not obvious to end users. Document spoofing, presentation attacks, camera injection, and deepfake-assisted onboarding can all bypass simplistic checks if the process is tuned only for speed. The user experience should therefore reduce friction without reducing the quality of the anti-fraud decision beneath it.
NHIMG’s broader identity guidance on lifecycle and governance also matters here, because onboarding is only one part of the control plane. NHI Lifecycle Management Guide and Identity Security Programme Guide are useful reminders that onboarding, ownership, review, and deprovisioning should be designed as one system, not as isolated steps.
Risk and Threat Considerations
Weak identity verification flows create a direct fraud path, while overly strict flows can create an operational control failure by pushing legitimate users to abandon signup or seek workarounds. The security problem is therefore not only false acceptance, but also false rejection at scale when the process becomes too burdensome to use reliably.
Failure mechanism: Attackers target flows that are easy to exhaust, spoof, or social-engineer, while legitimate users fail flows that are ambiguous, repetitive, or overly sensitive to image quality, device differences, or edge-case documents.
Impact: The organisation may see higher account-opening fraud, higher manual-review load, lower conversion, more support escalation, and weaker trust in the verification funnel overall.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS, 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 |
|---|---|---|
| OWASP ASVS | V6 — Authentication | Identity verification flows depend on robust authentication and evidence quality. |
| Recommendation — Apply V6 to keep authentication strong without adding unnecessary user friction. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | The question is about tuning verification strength to risk and assurance needs. |
| Recommendation — Set the assurance level to match the account or transaction risk. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Verification flows exposed through APIs can fail when auth checks are weakened for UX. |
| Recommendation — Harden authentication paths so convenience changes do not weaken trust decisions. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Strong identity proofing flows require reliable authentication before access is granted. |
| IA-8 — Identification and Authentication (Non-Organizational Users) | Customer-facing verification flows need assurance for external users. | |
| Recommendation — Use IA-2 to enforce strong user authentication before granting access. Use IA-8 to authenticate external users at the needed assurance level. | ||
Practitioner Guidance
What to prioritise: Start with the risk tier of the journey. A payment account, regulated onboarding flow, or privileged access request should justify more assurance than a low-value signup, even if the visible experience becomes less convenient.
What to verify: Test whether the flow still completes for genuine users with normal devices, normal lighting, and normal documents, then confirm that fraud patterns such as injection, replay, and synthetic identity are still being rejected at an acceptable rate.
Decision rule: If a control step does not materially improve fraud resistance or assurance, remove it; if removing it lowers confidence in who is being admitted, keep it and improve the presentation instead of weakening the check.
Practitioner takeaway: The best identity verification flow is not the shortest one, it is the one that gives users a clear path while preserving enough assurance that the organisation can trust the result.
Related resources from NHI Mgmt Group
- How should organisations design progressive identity verification so low-risk actions stay fast while higher-risk actions get stronger checks?
- When should organisations use stronger liveness checks instead of lighter verification in digital identity journeys?
- How should organisations choose between lower friction liveness checks and stronger presence assurance for remote identity verification?
- How should organisations design identity verification flows for higher fraud risk?