They often rely on narrow document checks, rigid rules, and risk models that treat whole groups as suspicious. When support is not accessible, users with outdated IDs, limited digital literacy, or non standard identities are screened out even if they are genuine. The result is exclusion driven by process design, not proven fraud.
Why This Matters for Security Teams
High-friction identity verification often fails because it treats identity proofing as a one-time gate instead of a service design problem. When the workflow is built around a narrow set of documents, fixed risk thresholds, and opaque review queues, legitimate users are excluded for reasons that have little to do with fraud. Current guidance suggests that identity assurance must be proportionate and accessible, not merely strict.
That matters because exclusion is not just a user experience issue. It can delay account recovery, block onboarding, and push support teams into manual exception handling that creates inconsistency and audit gaps. The challenge is especially visible when organisations rely on legacy KYC patterns that do not fit diverse populations or modern digital channels. The FATF Recommendations — AML and KYC Framework set baseline expectations, but implementation still varies widely.
NHI Management Group has also documented how identity controls fail when process design outruns operational reality in the Ultimate Guide to NHIs. One relevant signal: only 5.7% of organisations have full visibility into their service accounts, which is a reminder that weak identity operations often start with poor visibility and rigid control assumptions. In practice, many security teams encounter exclusion only after legitimate users have already been filtered out of the funnel, rather than through intentional design review.
How It Works in Practice
Identity verification systems exclude legitimate users when the verification path is too brittle to handle real-world variation. A person may have an expired document, a name mismatch across records, a limited internet connection, assistive technology needs, or a non-standard identity history. If the system requires exact document matches, repeated selfie checks, or device signals that are not consistently available, the workflow turns into a hard denial rather than a risk-based decision.
Operationally, the best-performing programs separate assurance from access. They use step-up checks only where risk justifies it, offer multiple proofing paths, and preserve a humane fallback for cases the automated model cannot confidently resolve. That can include document + liveness checks, support-assisted review, alternative verification via trusted records, or deferred completion after partial onboarding. The point is not to remove controls, but to prevent a single control from becoming an exclusion point.
Practitioners should also watch for policy drift between teams. Fraud teams tend to optimise for blocking false positives, while product and support teams absorb the cost of legitimate-user fallout. Where those incentives are not aligned, the result is “secure” flows that are difficult for real users to complete. NHI Management Group’s Top 10 NHI Issues highlights how weak governance and poor lifecycle design produce operational failure even when the control intent is sound. These controls tend to break down when verification depends on a single document class, because edge cases become indistinguishable from fraud to the automation layer.
Common Variations and Edge Cases
Tighter verification often reduces fraud exposure, but it also increases abandonment, support load, and the risk of unfair denial. Organisations have to balance assurance against accessibility, especially where onboarding supports regulated services, cross-border users, or populations with limited documentation access. There is no universal standard for the exact mix of checks yet, so best practice is evolving toward risk-tiered proofing instead of one rigid journey.
Edge cases matter most in sectors where identity data is fragmented. Name changes, address instability, rural connectivity, non-binary gender markers, lost documents, and culturally diverse naming conventions all create false mismatches if the verification engine is too literal. The eIDAS 2.0 — EU Digital Identity Framework points toward more interoperable identity models, but adoption is uneven and implementation details still vary by jurisdiction.
Where available, organisations should measure drop-off by reason code, not just completion rate, and review denials that occur at the same step repeatedly. The 52 NHI Breaches Analysis is useful here because it reinforces a broader security lesson: controls fail when they are treated as static gates instead of adaptive systems. For identity proofing, that means building exception handling, appeal paths, and accessible support into the flow from the start.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, NIST AI RMF and NIST SP 800-63 set the technical controls, and NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Identity proofing failures map to improper access control decisions. |
| NIST AI RMF | MAP | Risk models must account for exclusion, bias, and user harm. |
| NIST SP 800-63 | IAL2 | Identity assurance levels shape how strict proofing can be. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Rigid identity workflows mirror weak lifecycle governance patterns. |
| NIS2 | Article 21 | Operational resilience includes reliable access and recovery paths. |
Review onboarding controls so access is granted only after appropriate assurance and exception handling.
Related resources from NHI Mgmt Group
- How should government agencies implement identity verification at high-risk service moments without creating unnecessary friction for legitimate users?
- How should security teams assess an identity verification provider before trusting it with onboarding flows?
- How should fintech teams reduce onboarding friction without weakening identity verification?
- What breaks when organisations rely on document-free verification in high-risk onboarding flows?
