They often review titles instead of actual entitlements, so hidden conflicts remain inside roles, inherited permissions, and exception paths. SoD review only works when it is tied to live access data, not org charts. The practical test is whether any identity can complete a sensitive transaction without independent oversight.
Why This Matters for Security Teams
segregation of duties reviews fail when they become a paperwork exercise. Teams often validate job titles, manager approvals, or RBAC group names while missing the actual paths that let one identity request, approve, and execute a sensitive action. That is especially dangerous for NHI estates, where inherited access, service account sprawl, and exception paths can hide a full conflict even when the role model looks clean. NHI Mgmt Group research shows only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which explains why SoD gaps persist in practice.
The security impact is not abstract. A weak SoD review can allow one workload to retrieve a secret, call an API, and complete a privileged transaction without any independent control. That breaks the basic assumption behind NIST Cybersecurity Framework 2.0: access governance must be tied to real protective outcomes, not organizational diagrams. In practice, many security teams encounter SoD failures only after a privileged workflow has already been abused, rather than through intentional review.
How It Works in Practice
Effective SoD review starts with live entitlement data, not the org chart. Security teams need to trace what an identity can actually do across PAM, RBAC, secrets stores, ticketing systems, and deployment pipelines. For NHI, that means mapping the full chain from workload identity to credentials, then checking whether the same identity can create, approve, and release a change, payment, or production action. The Ultimate Guide to NHIs is clear that visibility and rotation gaps are common, so reviews that ignore service accounts and API keys miss the highest-risk paths.
A practical review usually includes three checks:
- Entitlement discovery: identify direct grants, inherited roles, and exception-based access for each identity.
- Workflow tracing: verify whether the same identity can both initiate and complete a sensitive transaction.
- Control separation: require a distinct human approver, different workload identity, or a technical gate such as JIT approval.
This is where current guidance suggests combining policy review with runtime evidence. Frameworks such as NIST Cybersecurity Framework 2.0 support access control and monitoring, while the operational reality is that SoD for NHI is strongest when paired with short-lived secrets, revocation, and logging. Organisations that treat secrets as static assets tend to miss chain-of-custody problems, especially when CI/CD tools or automation runners inherit broad access. These controls tend to break down in highly delegated cloud environments because exception handling, inherited permissions, and machine-to-machine trust chains obscure the true decision path.
Common Variations and Edge Cases
Tighter SoD controls often increase review overhead, requiring organisations to balance operational speed against assurance. That tradeoff is real in environments with frequent releases, shared platform tooling, or incident-response automation. In those cases, a rigid approval model can slow delivery without meaningfully reducing risk if the underlying entitlements still overlap.
Best practice is evolving for autonomous systems and agent-driven workflows. An AI agent or other autonomous workload may need temporary access to multiple tools to finish a task, which makes static SoD matrices less reliable. For those environments, teams are moving toward intent-based authorisation, JIT credential provisioning, and workload identity with runtime policy evaluation. The important question is not whether a role is separate on paper, but whether the same identity can still cross the control boundary at execution time. That is consistent with NIST Cybersecurity Framework 2.0 expectations around continuous control enforcement, and with NHI governance guidance in the Ultimate Guide to NHIs.
There is no universal standard for this yet, but a sound operating rule is simple: if a single identity can still both request and approve a sensitive action, the SoD review has not actually separated duties. That becomes hardest to prove in multi-cloud estates, temporary break-glass access, and agentic workflows where permissions change faster than periodic reviews can keep up.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers excessive privileges and hidden access paths in NHI estates. |
| NIST CSF 2.0 | PR.AC-4 | Addresses access enforcement and least privilege for identity governance. |
| NIST AI RMF | Useful where autonomous agents change access patterns and break static SoD models. |
Inventory NHI entitlements and remove any path where one identity can complete both sides of a sensitive action.
Related resources from NHI Mgmt Group
- What do organisations get wrong about segregation of duties in federated environments?
- What do organisations get wrong about cryptographic bill of materials data?
- How should organisations implement segregation of duties in hybrid environments?
- What do organisations get wrong about automated data classification?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 4, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
