A bottom-up approach starts with the needs, concerns, and lived experience of people affected by a digital identity system. In practice, it uses local context and community input to shape design choices, rather than assuming the technology should lead the programme.
What a Bottom-Up Approach Means in Identity Program Design
A bottom-up approach begins with the people and communities affected by a digital identity system, then shapes policy, process, and user experience around their local realities. It is especially useful when trust, adoption, and practical usability matter as much as technical correctness.
In identity programmes, this approach usually means validating assumptions with the people who must enrol, recover access, prove who they are, or use the system in constrained environments. It can expose friction that would be invisible in a top-down design, such as language barriers, shared devices, inconsistent documentation, or uneven connectivity.
How Bottom-Up Design Changes the Result
Bottom-up design changes not just the interface, but the decisions that surround it. Requirements may shift when a community explains which identifiers are stable, which proofing steps are realistic, or which trust signals carry meaning locally. That can affect enrolment flows, exception handling, support models, and even whether a proposed control is workable at all.
This is different from treating user feedback as cosmetic input after the system is already fixed. The point is to let lived experience shape the programme early enough that the final design fits the operational environment instead of forcing the environment to adapt to the design.
For identity teams, this often pairs well with role and access modelling that reflects real responsibilities rather than abstract organisational charts, as explored in the Role Mining and Role Design Guide. The same principle helps teams avoid role models that look neat on paper but fail in practice.
Why It Matters for Trust, Inclusion, and Control Quality
Bottom-up approaches matter because identity systems fail when they are correct in theory but mismatched to how people actually live and work. A design that ignores local context can create avoidable exclusion, push users toward unsafe workarounds, or reduce confidence in the system even when the underlying technology is sound.
It also improves control quality. A community-informed design is more likely to reflect real identity proofing constraints, realistic recovery paths, and the support burden created by exceptions. The outcome is often stronger adoption and fewer hidden failure modes than a purely centralised design would produce.
That same practitioner lens is consistent with broader security control thinking in NIST SP 800-53 Rev 5 Security and Privacy Controls, where access and governance decisions are expected to be deliberate and measurable rather than assumed.
Bottom-Up Approach Versus Top-Down Programme Design
Top-down design starts from institutional goals and then asks how people should comply. Bottom-up design starts from the conditions people actually face and then works back toward a system that can be governed, supported, and trusted at scale. In practice, mature programmes often need both.
The useful distinction is not ideological, it is architectural. If the system is highly standardised and the operating context is uniform, top-down control may dominate. If the system must work across diverse communities, constrained environments, or varied trust relationships, bottom-up input becomes essential to avoid brittle assumptions.
That balance is one reason the term remains relevant in identity governance and access design. Even in cloud and policy-heavy environments, local operational reality can determine whether a control is accepted, understood, and actually used. For identity and access programmes that also touch non-human actors, OWASP Non-Human Identity Top 10 remains a useful complement when machine access patterns are part of the picture.
Risk and Threat Considerations
Bottom-up design reduces the risk of building identity systems that look secure but fail under real-world conditions. When local constraints are ignored, users are more likely to route around controls, lose access, or rely on informal exceptions that weaken governance.
Failure mechanism: A top-down identity programme may optimise for policy completeness while missing practical barriers such as language, documentation gaps, shared credentials, or limited recovery options, which creates brittle controls and inconsistent enforcement.
Impact: The result can be exclusion, unsafe workarounds, weaker assurance, and a higher chance that the programme fails at adoption even if the technical architecture is formally sound.
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 | AC-2 — Account Management | Identity programmes depend on governed account lifecycle decisions. |
| IA-2 — Identification and Authentication (Organizational Users) | Bottom-up design affects how users can realistically prove identity and authenticate. | |
| IA-5 — Authenticator Management | Community-informed identity design often changes credential recovery and support realities. | |
| Recommendation — Align account design with real user needs and enforce lifecycle ownership. Design authentication flows around user reality and operating context. Manage authenticators so recovery and support paths remain practical. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access decisions must reflect how people actually use and experience the system. |
| Recommendation — Set access rules that match real operating conditions and user needs. | ||
Practitioner Guidance
Why practitioners should care: Bottom-up input is most valuable when identity decisions affect people who have different access conditions, support needs, or trust relationships. It helps teams design for actual use, not idealised process diagrams.
Governance implication: Treat community feedback, frontline operations, and exception handling as design inputs, not just deployment concerns. If those voices are absent, the programme may be compliant on paper but operationally fragile.
Practitioner takeaway: Use bottom-up discovery to test whether the identity model can survive contact with the real environment before it is locked into policy.
Related resources from NHI Mgmt Group
- How should security teams respond to bottom-up SaaS adoption that bypasses procurement and expands access to company data?
- When should organisations use a blended top-down and bottom-up risk assessment instead of relying on one model alone?
- What is the difference between a top-down and a bottom-up IT risk assessment?
- Bottom-up deprovisioning
