They fail because design choices made at the top can miss local barriers, especially for marginalised, migrant, refugee, indigenous, or last-mile communities. If practitioners do not understand real needs, incentives, and constraints, they risk building identity systems that are technically sound but practically unusable, poorly adopted, or misaligned with how services are actually accessed.
Why top-down identity design breaks down in practice
digital identity initiatives often fail when they are treated as architecture programmes first and service journeys second. A design can be elegant on paper, but if it assumes stable connectivity, ready access to documents, consistent literacy, or a single path into services, it will miss the constraints that shape real uptake. The result is usually not a technical failure, but a failure of fit.
That mismatch is especially visible in contexts where users are not starting from the same baseline. Marginalised, migrant, refugee, indigenous, and last-mile communities may face different device access, language needs, trust expectations, documentation rules, or intermediated service models. If those conditions are not part of the design input, the system may satisfy engineering goals while still failing the people it is supposed to serve.
Good identity design therefore has to describe not only the target architecture, but also the operating environment in which identity is actually claimed, verified, reused, and accepted. In practice, that means understanding where the identity proofing step happens, who helps or blocks the user, what fallback paths exist, and whether the identity can be used across the services that matter most.
What makes a technically sound identity system unusable
The main failure mode is over-optimising for uniformity. Centralised identity programmes often standardise credentials, onboarding rules, or verification thresholds, but then assume every user can meet those rules in the same way. When that assumption is wrong, the system can produce exclusion, repeated enrolment failures, or workarounds that push people back to paper, informal intermediaries, or duplicated records.
Another common issue is that identity systems are designed around the needs of the issuer, not the needs of the relying party or the end user. For example, a platform may support strong verification in theory, yet still fail where local service delivery depends on community agents, shared devices, or intermittent access. In those cases, usability is not a cosmetic concern, it is part of whether the identity is operationally real.
The issue is also organisational. Identity programmes can become detached from service design, frontline delivery, and local governance. When policy, technology, and service journeys are built separately, practitioners get a system that is compliant in structure but brittle in use. A useful comparison is the way Digital Identity, eID and Identity Wallets Guide shows that reusable identity only works when trust, presentation, and relying-party adoption line up across the full journey.
Why inclusion requires local constraint analysis, not just scale
Identity initiatives succeed when they are shaped by the conditions that determine actual access, not by the scale at which they are deployed. That means examining documentation barriers, language support, channel availability, device constraints, privacy concerns, and the social trust model around the service. Without that analysis, scale amplifies the same design flaw everywhere.
This is where operational detail matters. If a community cannot complete enrolment without travel, stable connectivity, or specific documents, then the initiative is not inclusive even if the core technology is robust. Similarly, if the identity cannot be recognised by local services, the user may have a credential that exists but cannot meaningfully function. Practitioners often underestimate how much adoption depends on these practical acceptance conditions, not just on issuance rates.
Identity governance also matters after launch. A programme that never measures drop-off, exception handling, or failed verification paths will not see exclusion early enough to correct it. The lifecycle perspective in NHI Lifecycle Management Guide is a useful reminder that identity value depends on provisioning, visibility, and offboarding across the full lifecycle, not just on initial creation.
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 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) | Identity initiatives for external populations must support real user onboarding and access. |
| IA-12 — Identity Proofing | Failure often comes from proofing requirements that do not fit local documentation or access constraints. | |
| AC-3 — Access Enforcement | An identity that cannot be accepted by downstream services is practically unusable. | |
| Recommendation — Design enrolment and authentication paths that work for the external users the service actually serves. Calibrate proofing requirements to the population and service context before rollout. Ensure relying services enforce access in ways that match the intended identity journey. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Identity programmes fail when access assumptions ignore who can actually use the service. |
| Recommendation — Align access rules with the real service journey and the identities that must use it. | ||
| NIST CSF 2.0 | GV.OC-03 — Mission and customer requirements are understood and inform cybersecurity risk management | The question is about design failing to reflect user and service requirements. |
| Recommendation — Capture community and service requirements before locking the identity architecture. | ||
Practitioner Guidance
What to prioritise: Start with the service journey and the exclusion points, not with the target architecture. Map where people fail to enrol, verify, recover, or reuse identity, then decide which design choices are acceptable only if alternative paths exist.
What to verify: Test the system against real population segments, including people with low connectivity, limited documentation, language barriers, or mediated access. If the identity only works for users with ideal conditions, it is not ready for broad deployment.
Common mistake: Treating adoption as a communications problem when it is actually a design and access problem. If the system depends on users adapting to the platform, rather than the platform adapting to real service conditions, failure usually shows up as avoidance, workaround behaviour, or low trust.
Practitioner takeaway: The core lesson is that digital identity is only successful when the architecture matches how people can actually enter and use services, especially where the last mile is constrained.
Related resources from NHI Mgmt Group
- How should organisations design digital identity systems for vulnerable communities in low-resource settings?
- What are the main signs that a charity is not ready to deploy digital identity at scale?
- How should business leaders evaluate AI and ML initiatives before they scale across the organisation?
- Why do identity programmes fail when they focus only on end-user experience?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
