Why do top-down digital identity programmes often miss the needs of grassroots users?

Top-down programmes often begin with a system design and then try to fit people into it. That approach can overlook how communities understand identity, what problems they are trying to solve, and which tools are actually available locally. The result is a solution that may be technically sound but poorly adopted, weakly trusted, or irrelevant to real-world use.

Why top-down identity programmes drift away from lived use

Top-down identity programmes usually optimise for consistency, compliance, and central control first. That works for the architecture, but not always for the people who need to use it. Grassroots users often judge identity by whether it helps them access services, prove who they are in context, and resolve real problems with the tools and documents they actually have.

When that local reality is ignored, the programme can become a policy layer that looks coherent on paper but fails at the point of use. A system built for universal rollout may miss community language, local trust relationships, mobile constraints, informal intermediaries, or the fact that some users do not fit the assumptions of a single national or enterprise identity model. The gap is not usually technical correctness, it is mismatched design intent.

This is why digital identity projects benefit from Digital Identity, eID and Identity Wallets Guide thinking as much as policy thinking: identity has to work in the settings where people actually transact, not only in the architecture diagrams.

What grassroots users need that central teams often miss

Grassroots users usually need identity to solve immediate, practical problems: getting access, proving eligibility, reducing repeat paperwork, or avoiding travel and wait times. They are less concerned with the elegance of the programme and more concerned with whether the process is understandable, affordable, and reliable on the devices and channels they already use.

That changes what “good” looks like. A strong central design may still fail if it assumes stable connectivity, current documents, high digital literacy, one official identity path, or a trusted institution at every step. It may also fail if it treats identity as a single credential event, when local use is often relational, repeated, and tied to specific services or intermediaries.

The practical lesson is that identity design must account for lifecycle and support conditions, not just enrolment. NHIMG’s Identity Security Programme Guide is useful here because it frames identity as an operating model, not only a technology stack, which helps explain why adoption depends on ownership, process, and service fit.

For programmes that include verification or onboarding, the issue is often not whether assurance exists in theory, but whether the assurance path is realistic for the target population. In practice, users drop out when the process is too rigid, too opaque, or too dependent on one channel. The stronger the assurance requirement, the more important it becomes to design the user journey around the real constraints of the population.

How to tell whether the programme is being designed from the top down alone

A top-down identity programme usually shows a few predictable symptoms. It standardises early, pilots narrowly, and treats exceptions as edge cases rather than signals that the model may not fit the population. It also measures success by policy completion, rollout coverage, or issued credentials, instead of by whether people can actually use identity to complete the intended task.

Another warning sign is when local actors are only asked to validate communication after the design is already fixed. At that point, they can confirm wording, but they cannot shape the underlying assumptions. If communities, service desks, frontline workers, or local delivery partners are not part of the requirement-setting stage, the programme may miss the workflows and trust relationships that determine adoption.

Programmes also drift when they treat identity as a back-office control problem rather than a public-facing service experience. Once that happens, usability failures are interpreted as resistance, when they may actually be evidence that the design is too remote from local reality.

Grassroots adoption improves when the programme treats local feedback as operational data, not as a communications issue. The most useful evidence is usually where people abandon the process, where they ask for help, and where they work around the official flow.

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 and GDPR define the regulatory obligations.

Framework	Control / Reference	Relevance
ISO/IEC 27001:2022	A.5.15 — Access control	Identity programmes need governance over who can access services and under what conditions.
Recommendation — Define access rules that match actual user journeys and service needs.
NIST SP 800-53 Rev 5	IA-8 — Identification and Authentication (Non-Organizational Users)	Grassroots digital identity questions center on external users and citizen-facing identity proofing.
	IA-12 — Identity Proofing	The question concerns whether identity systems fit how communities can actually prove identity.
	IA-5 — Authenticator Management	Adoption fails when credential and authenticator handling is unrealistic for local users.
Recommendation — Tailor external-user identity proofing to the population’s real constraints. Match identity proofing strength to user context and service risk. Design authenticator lifecycle to be usable for the intended population.
GDPR	Art.25 — Data protection by design and by default	Top-down identity systems must be designed around real users and data minimisation from the outset.
	Art.35 — Data protection impact assessment	Identity programmes that affect communities should assess practical harms and adoption impacts early.
Recommendation — Build user-centred identity flows into the design, not as a later patch. Assess identity journey risks and usability impacts before rollout.

Practitioner Guidance

What to prioritise: Start by mapping the identity journey from the user’s perspective, not from the programme’s governance model. Identify the exact point where people fail, delay, or rely on intermediaries, then redesign that step before adding more policy detail.

What to verify: Check whether the programme can support the lowest-capability but still legitimate user path, including low connectivity, shared devices, limited documentation, and local support constraints. If it cannot, the design is probably optimised for institutional convenience rather than adoption.

Common mistake: Treating low adoption as a communications problem. When uptake is weak, the first question should be whether the identity model matches how the target community actually establishes trust and completes transactions.

Practitioner takeaway: Top-down identity programmes succeed when they reduce friction for the people who must use them, not only when they satisfy central governance requirements. The design test is simple: if local users have to adapt heavily to make the programme usable, the programme is probably the thing that needs redesign.