They often treat it as a single permission rule instead of a control design problem. The common mistake is assuming different job titles guarantee independence, when the same person, role, or delegated access path can still control the process end to end.
Why This Matters for Security Teams
Segregation of Duties is supposed to stop one identity path from creating, approving, and executing a sensitive action end to end. Teams often miss that identity programmes can satisfy a title-based rule while still leaving the same operator, service account, delegated admin, or automation chain with effective control. That gap matters because identity governance is not just about who appears in a directory, but who can actually assemble privilege across systems.
In practice, NHI risk makes this worse: secrets spread across code, CI/CD, and shared vaults, and control paths blur between humans and machines. NHIMG’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which helps explain why SoD failures rarely look like a single bad role assignment. The relevant lesson from NIST Cybersecurity Framework 2.0 is that governance must be tied to enforced outcomes, not just catalogue entries.
In practice, many security teams encounter SoD failure only after a privileged workflow has already been abused, rather than through intentional design review.
How It Works in Practice
Effective SoD starts by mapping the full decision path, not just the named owner. That means tracing who can request access, who can approve it, who can provision it, who can bypass controls, and which NHIs can execute the final action. In mature programmes, SoD is enforced at the workflow layer with policy checks, approval boundaries, and short-lived entitlements, rather than as a static rule in an identity catalogue.
For NHIs, this usually means separating identity issuance, secret delivery, privilege activation, and workload execution. A service account might exist, but it should not also hold standing approval rights, long-lived admin tokens, or unconstrained delegation paths. Current guidance suggests using Top 10 NHI Issues to identify where standing privilege and unmanaged secrets undermine control design. The practical pattern is to combine least privilege with runtime checks, JIT credentialing, and logging that proves who approved what, when, and under which context.
Standards bodies frame this as part of governance and continuous monitoring. NIST CSF 2.0 emphasises access control, auditability, and resilience, while implementation teams should also treat SoD as a control objective in CI/CD, cloud admin, and API automation. That often requires policy-as-code, separation between build and deploy identities, and explicit break-glass handling for emergency access.
- Define SoD around actions, not job titles.
- Separate approval, provisioning, execution, and audit paths.
- Use short-lived secrets and revoke them after task completion.
- Review whether delegated access collapses the separation you thought existed.
- Test the full workflow, including automation, not just directory roles.
These controls tend to break down in heavily automated environments where CI/CD robots, shared pipelines, and delegated cloud admins can chain privileges faster than manual reviews can detect.
Common Variations and Edge Cases
Tighter SoD often increases operational overhead, requiring organisations to balance stronger independence against delivery speed and exception handling. That tradeoff becomes especially visible in smaller teams, where one person may legitimately wear multiple hats, and in incident response, where emergency access must sometimes override normal boundaries.
There is no universal standard for this yet, but current guidance suggests treating exceptions as time-bound, logged, and separately reviewed rather than permanently widening the model. The hardest edge cases involve third-party operators, managed service accounts, and autonomous workflows where an agent can request, receive, and consume access without a human in the loop. In those cases, traditional SoD language can become misleading unless it explicitly covers machine identities and delegated automation paths.
For teams assessing real-world exposure, NHIMG’s 52 NHI Breaches Analysis is useful for understanding how privilege concentration and weak lifecycle controls turn design gaps into incidents. The best practice is evolving toward continuous SoD validation: review actual execution paths, not policy diagrams, and confirm that no single identity can create, approve, and enact the same sensitive outcome.
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 CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | SoD fails when NHI secrets and privileges stay overextended. |
| NIST CSF 2.0 | PR.AC-4 | Access control must prevent one identity path from owning the whole action. |
| CSA MAESTRO | GOV-2 | Agentic and automated paths can collapse SoD without governance. |
Govern automation and delegated access so no single agent can complete a sensitive task alone.
