How should identity programmes start when local trust, access, and community needs are unclear?

Identity programmes should begin with the people and context, not the technology stack. A bottom-up approach asks why communities want a digital identity, what concerns they have, and what tools are missing locally. That framing helps teams design identity solutions that are more usable, more trusted, and better matched to real service delivery conditions.

Start with local trust, not the identity stack

When trust, access, and community needs are unclear, the first job is to understand the service relationship the programme is meant to support. That means clarifying who needs to be recognised, what they need to do, what breaks trust, and which local constraints shape adoption. A programme that starts with technology usually optimises for implementation convenience instead of real-world use.

That is why a programme should begin with discovery, not tooling. In practice, this means engaging the intended users and operators early enough to surface whether identity is being asked to solve access, portability, accountability, inclusion, or service eligibility. The shape of the programme should follow those answers, because the wrong starting assumption can create a system that is technically sound but operationally rejected.

The same principle is reflected in the Identity Security Programme Guide, which frames identity work as a programme with scope, ownership, roadmap, and governance rather than a product purchase. For local or community-facing identity efforts, that programme view matters because it keeps the design anchored to outcomes instead of architecture.

What bottom-up identity design is trying to uncover

A bottom-up approach tries to expose the conditions that make identity usable in the first place. That includes whether people have reliable documentation, whether service points can verify them fairly, whether access needs are shared or individual, and whether the local environment supports online, offline, or assisted flows. If those conditions are not known, identity design becomes guesswork.

This is also where governance and lifecycle questions begin to appear. If identities are created without knowing who owns them, who can recover them, or who can update them when circumstances change, the programme will accumulate friction and exceptions. The IAM and IGA Basics guide is useful here because it highlights that identity programmes are not only about authentication, but also about provisioning, access review, entitlement management, and joiner-mover-leaver handling.

In community settings, those lifecycle questions often matter more than the choice of identifier or login method. A programme can only become trusted if people believe identity is revocable, recoverable, and governed in a way that matches the services they actually need. The local context determines whether the main risk is exclusion, duplication, misuse, or inability to sustain the service over time.

For teams dealing with machine, service, or platform identities alongside people, the same bottom-up logic still applies. The question is not only how to issue an identity, but how to manage it across its life so that access does not drift away from the original service purpose. The NHI Lifecycle Management Guide is relevant as a lifecycle model for provisioning, visibility, rotation, and offboarding.

How to judge whether the programme is ready to scale

Readiness is not measured by how quickly identities can be issued. It is measured by whether the programme can explain its trust model, service boundaries, and exception handling in terms local stakeholders accept. If there is no shared answer to who should be onboarded, how they should be verified, and what happens when access must be changed or removed, the programme is still in the design phase.

The Zero Trust Identity Guide is a useful reference for the broader principle that identity policy should be explicit, phased, and aligned to verification rather than assumption. Even when a local programme is not pursuing a full zero trust model, the discipline of defining trust boundaries and verifying access conditions helps avoid overconfident deployment.

At scale, bottom-up design should produce fewer arbitrary exceptions, clearer recovery paths, and a stronger relationship between identity and actual service delivery. If the programme cannot support those outcomes, then it is not yet mature enough to expand, regardless of how polished the login experience may look.

Risk and Threat Considerations

The main risk in starting from technology is that the programme creates an identity layer that is formally complete but socially unusable. That can lead to exclusion, shadow processes, weak workarounds, and identities that are granted or shared outside policy because the official path does not fit local reality.

Failure mechanism: The programme assumes a fixed trust model before understanding local verification needs, access patterns, and recovery constraints, so the resulting identity process cannot support normal service delivery and gets bypassed.

Impact: The organisation inherits brittle onboarding, poor accountability, inconsistent access decisions, and a higher chance that users or operators will invent unofficial methods to get work done.

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, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	Identity programmes must define who is authenticated and under what trust assumptions.
	IA-5 — Authenticator Management	Bottom-up identity programmes still need lifecycle control over credentials and recovery.
Recommendation — Define user authentication requirements after mapping the local trust model and service needs. Manage credential issuance, rotation, and recovery as part of the programme lifecycle.
CIS Controls v8	CIS-5 — Account Management	The question is about starting an identity programme, which requires governed account provisioning and removal.
Recommendation — Standardise account lifecycle ownership and review before scaling access.
ISO/IEC 27001:2022	A.5.15 — Access control	Access decisions must follow locally understood trust and service requirements.
	A.5.16 — Identity management	The programme is fundamentally about establishing who should be recognised and governed.
Recommendation — Align access policy to the actual service context and local trust conditions. Define identity governance rules that reflect the community and operating context.
NIST Zero Trust (SP 800-207)	3.1 — Zero Trust fundamentals	The answer relies on explicit trust boundaries and verification rather than assumed access.
Recommendation — Use explicit verification and trust boundaries to guide phased identity design.

Practitioner Guidance

What to prioritise: Start with discovery interviews, workflow mapping, and a plain-language trust model before selecting an identity platform. The early output should be a description of who needs access, under what local conditions, and what failure modes the programme must tolerate.

What to verify: Verify that the programme can answer three questions consistently: who is being identified, who can vouch for them, and what service outcome identity is meant to enable. If any of those answers differ by stakeholder group, document the differences before standardising.

Practitioner takeaway: The safest identity programme is the one that earns legitimacy from the community it serves first, then translates that trust into controls and tooling, not the other way around.