Adding identity as a fourth pillar is a useful step, but it does not fully solve the architectural problem if actor governance and data protection remain separated. Organisations should use it to force a redesign of access governance, lifecycle management and runtime authorisation, not just rename the framework.
Why adding identity helps, but does not finish the redesign
Identity becomes more useful when it is treated as a control plane, not a label change. If organisations simply add identity as a fourth pillar, they improve visibility over who or what is acting, but they still risk leaving governance fragmented across infrastructure, applications and data. The real shift is to make identity the link between policy, access and runtime behaviour.
A stronger model also forces teams to confront identity security programme design instead of inheriting siloed ownership. That matters because actor governance spans workforce, privileged, customer, service and agent identities, and those populations fail in different ways even when the underlying platform is shared.
For readers comparing operating models, the question is not whether identity is important, but whether it is strong enough to organise decision-making across the whole stack. A useful redesign will clarify ownership for authentication, authorization, lifecycle and escalation paths, rather than treating identity as another box in the security org chart.
What changes when identity is made part of the model
Identity changes the security model when it becomes the mechanism that connects request, privilege and accountability. In practice, that means access decisions are no longer based only on network location or application boundary, but on the actor, its current state, and the scope of authority it has been granted. This is the point at which lifecycle management and runtime authorization stop being downstream admin tasks and become architectural concerns.
That redesign also exposes where the old model breaks down. If secrets, tokens, sessions and standing privileges are not governed with the same discipline as user access, the organisation can have strong perimeter controls and still fail at the point of action. The relevant question is whether the control plane can distinguish between legitimate delegation and excessive persistence. NHIMG’s NHI Lifecycle Management Guide is useful here because lifecycle discipline is what turns identity from a naming convention into a governable system.
Where identity is well integrated, teams can reason about joiner-mover-leaver events, service credential rotation, access reviews and environment boundaries as part of the same model. That reduces the chance that a redesign creates one modern layer on top of legacy privilege practices. It also makes it easier to map who approved access, who can revoke it and which controls should trigger when identity state changes.
Why a full redesign usually outperforms a simple pillar addition
A fourth pillar can improve language, but it can also preserve the wrong boundaries. If actor governance remains separate from data protection, organisations still end up with mismatched policy decisions, duplicated enforcement points and weak accountability for who can do what with sensitive data. A redesign is preferable when identity is expected to shape authorisation, monitoring and exception handling across the whole environment, not just in one platform team.
That is why the better operating model is usually converged, not additive. It should combine identity governance, access policy, privileged control and runtime checks so that the same actor state drives both access grant and access review. NHIMG’s Identity Convergence Guide captures this logic well, because convergence is the practical answer when separate identity silos cannot keep pace with shared services, machine access and agentic workflows.
The redesign should also account for the fact that some organisations need stronger alignment with standards and control frameworks to make the model operational. NHIMG’s Ultimate Guide to NHIs, Standards is a useful reference point when teams need to anchor that redesign in recognised control expectations rather than in abstract architecture language.
Risk and Threat Considerations
When identity is bolted on as an extra pillar without changing governance, the main risk is false confidence. Organisations may believe they have modernised the model while standing privileges, weak lifecycle controls and poorly scoped delegation still allow abuse of legitimate access paths.
Failure mechanism: Siloed identity ownership leaves access, data and runtime policy inconsistent, so a compromised or overprivileged actor can still perform high-impact actions within an apparently controlled environment.
Impact: The result is broader blast radius, slower revocation, weaker attribution and a higher chance that misuse, compromise or policy drift remains undetected until after material damage.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Identity pillar redesign depends on lifecycle governance for accounts and actors. |
| AC-6 — Least Privilege | The question centers on redesigning authority, not just naming identity. | |
| IA-5 — Authenticator Management | Identity as a pillar requires control of secrets, tokens and authenticators. | |
| Recommendation — Align account lifecycle ownership so creation, review and removal are governed centrally. Constrain access to the minimum authority each actor needs at runtime. Manage authenticators through issuance, rotation, revocation and secure storage. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The answer depends on moving from static trust to policy-driven access decisions. |
| Recommendation — Use continuous verification and policy-based access to replace implicit trust. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Non-human actors are part of the identity scope when redesigning governance. |
| Recommendation — Reduce standing privilege for non-human actors and enforce least privilege. | ||
Practitioner Guidance
What to prioritise: Start by mapping which decisions identity must control directly, especially access grant, revocation, delegation and step-up checks. If those decisions still sit outside the identity model, the organisation has only renamed a boundary, not redesigned it.
What to verify: Check whether one actor state can drive both access policy and access review across workforce, privileged, service and agent populations. If it cannot, the architecture is still fragmented even if the terminology has changed.
Practitioner takeaway: Treat identity as a design constraint on the security model, not an optional pillar, because the value comes from unifying governance and runtime authority, not from adding another label.
Related resources from NHI Mgmt Group
- What breaks when organisations do not have a clear identity security maturity model?
- Why do organisations need an identity-centric security model when a single compromised identity can create broad exposure?
- Why do organisations need a more flexible identity security model as systems and regulatory demands expand?
- Why do identity governance and privileged access controls matter when organisations add AI-driven security workflows?