Identity inclusion means designing identity services so people are not excluded by device ownership, connectivity, language, documentation, or geography. It goes beyond technical rollout and addresses whether the intended population can realistically enrol, authenticate, and benefit from the system in everyday conditions.
What Identity Inclusion Means in Practice
Identity inclusion is not just about whether a platform exists, it is about whether real people can actually use it under everyday constraints. A design that assumes always-on connectivity, one device per person, or a narrow documentation model can still exclude the intended population.
For that reason, identity inclusion sits at the intersection of security, accessibility, and adoption. It asks whether the control model works for the whole audience, not just for users who already have ideal conditions or a preferred channel.
What Identity Inclusion Changes About Identity Design
The term pushes teams to treat enrolment, authentication, recovery, and support as part of the identity experience, not as optional extras. If users cannot complete those steps because of geography, language, mobility, cost, or document barriers, the system may be secure on paper but unusable in practice.
That matters because identity programs often inherit assumptions from the implementing organisation rather than from the population being served. Identity inclusion forces those assumptions into the open, especially where device access, connectivity, and identity evidence are uneven across users.
In mature programmes, inclusion also affects channel choice and fallback design. A single authentication path can be efficient, but it becomes a barrier when it fails for people who cannot use that path reliably.
Common Exclusion Patterns
Identity exclusion usually shows up in ordinary operational decisions, not in a single obvious failure. A policy that depends on a smartphone, a stable broadband connection, one legal document format, or a local language that is not widely supported can lock out legitimate users.
Exclusion can also come from identity proofing or recovery processes that are too rigid for real-world conditions. If recovery assumes possession of a current device, a permanent address, or continuous access to the same number or email, then account loss can turn into long-term loss of access.
These issues are especially visible when identity services are deployed across diverse populations, distributed workforces, or cross-border communities. The technical control may be sound, but the service boundary is narrower than the human boundary it is meant to cover.
For a broader view of how identity services can fail at lifecycle and ownership boundaries, NHIMG’s NHI Lifecycle Management Guide is useful for understanding how identity systems need visibility, recertification, and offboarding discipline.
Why Identity Inclusion Matters for Trust and Usability
Identity inclusion is ultimately a trust issue as much as a usability issue. When a legitimate user cannot enrol, authenticate, or recover access, the organisation has created a barrier to service delivery and, in some cases, a path to operational inequality.
It also affects security outcomes. Poorly designed inclusion can drive people toward workarounds, shared access, or repeated support exceptions, all of which weaken assurance. The goal is to keep the system both usable and trustworthy for the population it actually serves.
That is why inclusion is not a soft requirement layered on later. It is part of the quality of the identity control itself, alongside assurance, resilience, and supportability.
NHIMG’s Identity Security Programme Guide is helpful where inclusion has to be governed as part of broader identity strategy rather than as an isolated UX concern.
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 sets 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 inclusion concerns whether external users can actually enrol and authenticate. |
| IA-2 — Identification and Authentication (Organizational Users) | Internal identity services must work for employees regardless of access constraints. | |
| IA-12 — Identity Proofing | Inclusion depends on proofing requirements that people can realistically satisfy. | |
| Recommendation — Design external-user identity flows that remain usable across varied device, connectivity, and documentation conditions. Validate that workforce authentication paths do not exclude users through unnecessary device or channel assumptions. Set proofing steps that achieve assurance without creating avoidable access barriers for legitimate users. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Identity inclusion is part of ensuring access rules work for the intended user population. |
| Recommendation — Define access control requirements that account for practical user access constraints and service reachability. | ||
Practitioner Guidance
Why practitioners should care: Identity inclusion is a design constraint, not a cosmetic improvement. Teams should evaluate whether their chosen enrolment and authentication paths work for the full intended population, including people with limited connectivity, shared devices, or non-standard documentation.
Common misunderstanding: A system can be technically secure and still fail its purpose if people cannot practically use it. Practitioners should treat exclusion as a control weakness because it often shifts behaviour into less secure fallback patterns or support exceptions.
Governance implication: Ownership should extend beyond the build team to policy, support, and service operations, so inclusion failures are visible in review, not discovered only after users are locked out.
Practitioner takeaway: The right question is not only “is the identity control strong?”, but also “can the intended population actually complete the journey without being excluded?”
Related resources from NHI Mgmt Group
- How should public-sector teams balance identity inclusion with fraud resistance?
- How do teams balance financial inclusion with identity risk?
- Why do centralized identity systems struggle to support financial inclusion at scale?
- Why does digital identity adoption improve financial inclusion and fraud prevention at the same time?
