What are the signs that a digital identity programme is not inclusive enough for underserved populations?

A digital identity programme is likely falling short when onboarding requirements are too rigid, when paper-based or in-person steps create delays, or when people in rural or displaced communities cannot satisfy verification rules. Other warning signs are poor cross-channel access, limited adaptability to local workflows, and designs that fit institutions better than the people they are meant to serve.

When a digital identity programme stops working for the people it should reach

In practice, exclusion usually shows up as process friction rather than a single failure event. If the programme assumes stable documents, easy travel, reliable connectivity, or a narrow set of device and language conditions, underserved users are the first to fall out. The question is whether the design still works when people do not fit the institution’s preferred workflow.

Signs become clearer when identity proofing and verification are treated as one-size-fits-all. That is why programmes aligned to eIDAS 2.0, the EU Digital Identity Framework need to be judged not only by technical capability, but by whether ordinary people can actually complete enrolment, use the wallet, and recover access without unrealistic prerequisites.

A second warning sign is that the programme relies on a single “ideal” channel. If mobile-only onboarding fails on low-end devices, if in-person fallback is scarce, or if paper-assisted routes are slow and degrading, then the programme is not inclusive enough. Poor localisation, limited disability support, and rigid step ordering often reveal the same problem: the journey was designed around institutional convenience, not user reality.

What exclusion looks like across onboarding, verification, and recovery

The most visible symptom is attrition during enrolment. People drop out when they cannot supply the required documents, cannot travel to a centre, cannot complete biometric capture, or are asked to restart after a failed check. For displaced populations, rural users, older adults, and people with limited digital literacy, the issue is often cumulative friction rather than a single hard refusal.

Another sign is that exception handling is weak or absent. If an applicant with address instability, name variation, damaged documentation, or intermittent connectivity is simply rejected instead of routed into an alternative verification path, the programme is effectively filtering out underserved groups. A sound identity proofing and KYC approach needs recovery paths, not just a high-assurance front door.

Cross-channel inconsistency is also a strong indicator. When a person can start online but must finish in person, or when support staff cannot see or repair what the digital flow did, the programme becomes brittle. If help desks, local agents, and digital self-service do not produce the same outcome, users with fewer resources bear the cost of the mismatch.

Why programme design, not just fraud control, determines inclusion

Inclusive identity programmes balance assurance with accessibility. If every control is optimised for fraud prevention without considering who is most likely to fail the process, the burden shifts to the user and exclusion rises. The same design choices that improve accuracy for one population can become barriers for people without stable documents, transport, devices, or time away from work.

That is why practitioners should look for evidence that the programme can support multiple assurance paths, not only a single rigid one. Guidance on standards and trust frameworks is useful here because it reinforces a broader principle: controls should be strong enough to protect the service, but not so narrow that they collapse under real-world variation.

From an operating-model perspective, the programme is also failing if it cannot learn from rejected or abandoned attempts. If there is no review of drop-off points, no segmentation by geography or population type, and no route to adjust local workflows, the exclusion becomes invisible. A programme cannot claim inclusivity if it only measures successful completions and ignores who never makes it through the process.

Risk and Threat Considerations

Exclusion is not only a social or service-quality issue. When legitimate users are forced out of the intended flow, they often seek workarounds, depend on intermediaries, or abandon the service altogether. That creates operational risk, trust erosion, and in some settings a larger fraud surface because people are pushed toward weaker verification paths or unsupported informal access routes.

Failure mechanism: Rigid proofing rules, weak fallback channels, and poor recovery design turn ordinary user variation into systematic denial of access. The programme then misclassifies underserved users as non-compliant or unverifiable, instead of recognising that the process itself is excluding them.

Impact: Eligible people remain locked out, service uptake drops, support costs rise, and the organisation may accidentally privilege users with easier documents, stable connectivity, or greater institutional familiarity. In identity programmes with public or regulated service implications, that can also undermine fairness and legitimacy.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5, NIST SP 800-63 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-8 — Identification and Authentication (Non-Organizational Users)	Digital identity programmes for underserved populations depend on accessible external-user proofing and authentication.
Recommendation — Design external-user identity flows with alternate proofing and recovery paths that still meet assurance needs.
NIST SP 800-63	Digital Identity Guidelines	This question is about identity proofing, assurance, and equitable enrolment across populations.
Recommendation — Align proofing and lifecycle decisions to assurance levels while preserving accessible fallback channels.
ISO/IEC 27001:2022	A.5.34 — Privacy and protection of PII	Inclusive identity programmes handle sensitive identity data and must minimise discriminatory or excessive collection.
Recommendation — Review identity-data collection and retention so required evidence is proportionate and user-accessible.
NIST CSF 2.0	GV.OC-03 — Cybersecurity Roles, Responsibilities, and Authorities	Programme inclusivity depends on clear ownership for exception handling, support, and user remediation.
Recommendation — Assign ownership for onboarding exceptions, recovery, and channel consistency across the identity journey.

Practitioner Guidance

What to verify: Check where users abandon the journey, not just where they complete it. Segment drop-off by geography, device type, language, disability support needs, documentation type, and channel, because exclusion often appears only after those cuts are visible.

Decision rule: If a user can be expected to be legitimate but cannot satisfy one rigid path, the programme needs an alternate route, a human-assisted exception, or a different proofing method. A programme that has no safe fallback is not inclusive enough, even if its pass rate looks strong for the users it already serves.

Practitioner takeaway: The clearest sign of exclusion is repeated failure at the edges of the journey, especially where the service assumes stability, connectivity, and documentation that underserved populations do not consistently have.