How should identity programmes handle people without formal identity documents?

Why This Matters for Security Teams

People without formal identity documents are often excluded by systems that assume every applicant can be matched to a birth certificate, passport, or national ID. For security teams, the issue is not only access but assurance: identity programmes must decide how to establish trust when standard evidence is missing. Current guidance suggests treating this as an identity proofing design problem, not a blanket exception.

That distinction matters because exclusion creates operational and safety risks, while over-permissive exception handling creates fraud and account takeover risk. The better model is to define alternative evidence paths, document the decision rules, and apply the same assurance standard consistently across cases. This is aligned with broader identity governance practices in the NIST Cybersecurity Framework 2.0, which emphasises risk-based control design and accountable process ownership.

NHIMG research shows how quickly weak identity controls become enterprise risk: the Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, a reminder that identity decisions must be explicit, not implicit. In practice, many security teams encounter abuse of exception handling only after enrolment shortcuts or manual approvals have already been exploited.

How It Works in Practice

A workable programme separates identity evidence from identity assurance. Instead of requiring one specific document, policy should define acceptable evidence categories and the confidence each one contributes. That may include community attestation, supervised enrolment, biometrics, or cross-checking with civil or institutional records. The key is that the organisation must decide in advance what combinations are sufficient for each risk tier.

Practitioners should use a risk-based proofing model with clear triggers for escalation. Low-risk services may accept a narrower evidence set, while high-risk financial, healthcare, or government workflows may require stronger corroboration. The 52 NHI Breaches Analysis is a useful reminder that weak identity proofing and weak lifecycle controls often compound over time, especially when exceptions are not reviewed.

• Define which evidence sources are acceptable and which are prohibited.
• Assign assurance levels to each evidence type rather than treating all substitutes equally.
• Require supervisor review or trusted third-party validation for high-risk enrolments.
• Log every exception, including who approved it and why.
• Set review and revocation rules so temporary accommodations do not become permanent gaps.

Where possible, use step-up verification for later transactions so the initial enrolment does not carry all future risk. Identity teams should also separate inclusion policy from fraud policy: a person can be included without granting immediate high assurance. These controls tend to break down in distributed, paper-based environments because record quality, local discretion, and inconsistent review standards make assurance hard to measure.

Common Variations and Edge Cases

Tighter proofing often increases enrolment friction and administrative overhead, requiring organisations to balance access against assurance. There is no universal standard for this yet, so best practice is evolving toward documented alternative evidence frameworks rather than one-size-fits-all rules.

Some contexts need special handling. Refugee, displaced, or stateless populations may have fragmentary records but still be vulnerable to exclusion if identity programmes insist on a single source of truth. In those cases, policy should permit supervised enrolment with layered evidence and later uplift to stronger assurance when additional records become available. Conversely, high-impact uses such as benefits disbursement or regulated access may justify stricter thresholds and narrower exception paths.

Programmes should also avoid assuming that biometrics alone solve the problem. Biometrics can help with uniqueness and re-verification, but they do not replace governance around consent, fallback procedures, accessibility, and appeal. The NIST identity and cyber guidance are useful starting points, but local law, privacy constraints, and population context still drive final design choices.

For practitioners, the practical test is simple: can the organisation prove why this person was accepted, what evidence was used, and how long the exception remains valid? If not, the identity programme is relying on discretion instead of assurance.

Related resources from NHI Mgmt Group

• When does a machine identity become a compliance problem?
• Why is it important to integrate identity and data governance?
• When does secret exposure become a broader identity risk?
• How should security teams handle risks from AI browser extensions?