Identity design is the way an organisation structures identities, roles, permissions, and lifecycle rules before they are deployed into production. It shapes how access is requested, granted, reviewed, and removed. Strong design reduces administrative complexity and makes governance controls easier to operate consistently.
Expanded Definition
Identity design is the pre-production architecture of how non-human identities, human identities, permissions, and lifecycle rules are organised so access behaves predictably at scale. In NHI programs, this includes deciding which identities are persistent, which are ephemeral, how roles are inherited, when approvals are required, and what evidence supports access decisions. The concept overlaps with IAM architecture, but identity design is more specific because it governs the shape of trust before accounts, service principals, API keys, or agent identities are created. That distinction matters in Zero Trust environments, where identity is treated as a control plane and not just an onboarding record. NIST SP 800-53 Rev. 5 frames this through access enforcement, account management, and least-privilege controls, which are only effective when the underlying identity model is coherent. Where definitions vary across vendors, the practical consensus is that identity design must cover issuance, privilege boundaries, ownership, and revocation logic together, not as separate afterthoughts. The most common misapplication is treating identity design as a documentation exercise, which occurs when teams model roles after deployment instead of before production access is provisioned.
Examples and Use Cases
Implementing identity design rigorously often introduces upfront governance overhead, requiring organisations to weigh faster delivery against reduced access sprawl and easier revocation.
- A platform team defines a standard service-account pattern with short-lived credentials, clear ownership, and automated expiration instead of creating one-off accounts per application.
- A security team maps engineering roles to a limited set of permission bundles so code pipelines, secrets managers, and production systems can be reviewed consistently, informed by the patterns described in the Ultimate Guide to NHIs.
- An enterprise establishes lifecycle rules for AI agents so tool access is granted only after approval, bounded by task scope, and removed when the agent is retired.
- A cloud governance team aligns account creation with account management guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls to reduce exceptions during audits.
- A DevOps group redesigns CI/CD permissions after a token exposure event, using lessons from JetBrains GitHub plugin token exposure and the broader breach patterns in 52 NHI Breaches Analysis.
Why It Matters in NHI Security
Identity design determines whether NHI governance is enforceable or merely aspirational. When identities are created without clear ownership, privilege boundaries, or revocation paths, organisations accumulate standing access that is difficult to audit and even harder to remove. That is why NHIMG reports that 97% of NHIs carry excessive privileges, a design failure that directly broadens the attack surface and weakens Zero Trust implementation. Identity design also shapes how quickly compromise can be contained: if service accounts, API keys, and agent identities are not built for isolation, rotation, and offboarding, downstream controls inherit the mess instead of fixing it. The NHI risk patterns documented in the Top 10 NHI Issues show that design flaws often become operational weaknesses across secrets management, privilege assignment, and lifecycle enforcement. Organisations typically encounter the consequences only after a breach review, at which point identity design becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Identity design governs how NHI roles and lifecycle rules are structured. |
| NIST CSF 2.0 | PR.AC-1 | Access provisioning and governance depend on identity structure and rules. |
| NIST SP 800-63 | IAL/AAL | Identity assurance concepts influence how identities are established and bound. |
| NIST Zero Trust (SP 800-207) | None | Zero Trust relies on identity-centered policy enforcement and continuous evaluation. |
| OWASP Agentic AI Top 10 | A-04 | Agent identity design shapes tool access, scope, and control boundaries. |
Model identities for least privilege and continuous verification, not implicit network trust.
Related resources from NHI Mgmt Group
- When should organisations treat an API design issue as an identity risk?
- How should security teams design API authorisation for decentralized identity?
- Why does decentralized identity increase the importance of token design?
- Should organisations prioritise secrets rotation or agent identity design first?
