They often treat a certified access review as proof that the risk is controlled. In reality, SoD is only effective when the organisation can show that incompatible access is not being used together in live transactions. Compliance evidence matters, but operational evidence is what prevents fraud.
Why Organisations Misread Segregation of Duties as a Paper Exercise
SoD is often reduced to an access review checkbox, but that misses the real control objective: preventing one identity from completing incompatible steps in a live process. The risk is highest when credentials, service accounts, and API keys can be reused across systems without transaction-level visibility. That gap matters because compliance frameworks expect controls to be both designed and operating, not merely documented. NHI Management Group’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives frames this distinction clearly, and it aligns with the control logic in NIST Cybersecurity Framework 2.0, where governance and detection must prove outcomes, not just policy intent.
What teams get wrong is assuming a clean certification means incompatible access is harmless. In practice, an account can pass review and still be used to approve, create, and reconcile the same transaction if logging, workflow controls, and runtime enforcement are weak. That is why compliance evidence alone does not stop fraud or abuse. In practice, many security teams discover SoD failures only after a financial exception, audit finding, or insider abuse path has already been exploited, rather than through proactive transaction monitoring.
How SoD Actually Works in Live Systems
Effective SoD depends on three layers working together: identity entitlement design, runtime enforcement, and auditable transaction evidence. A role model can help define who should not combine certain functions, but static RBAC alone is not enough if the same NHI can invoke multiple tools or services in sequence. Current guidance suggests organisations should pair entitlement rules with workflow controls and event correlation so the system can detect when incompatible actions are attempted together. That is especially important for API-driven platforms, where service accounts often bypass the human approval paths that auditors expect to see.
Operationally, teams should treat each sensitive process as a chain of actions, then map which NHI can initiate, approve, execute, or reconcile each step. The Top 10 NHI Issues highlights how overprivileged non-human identities and weak lifecycle controls turn SoD into a false comfort if secrets are reused broadly. The practical control pattern is to use least privilege, short-lived credentials, and logging that links each action to a unique workload identity. Frameworks such as NIST SP 800-53 Rev 5 Security and Privacy Controls support this by requiring access control, auditability, and monitoring that can demonstrate whether the control is operating as intended.
- Define incompatible functions at the transaction level, not only in role matrices.
- Use workflow approval paths that cannot be completed by the same NHI end to end.
- Correlate logs across applications, databases, and automation tools to detect combined use.
- Rotate and scope credentials so an NHI cannot persist across unrelated control points.
These controls tend to break down in highly automated environments with shared service accounts, weak application logging, or batch jobs that reuse the same secret across multiple business functions.
Where Compliance Evidence and Control Reality Diverge
Tighter SoD monitoring often increases operational overhead, requiring organisations to balance stronger fraud prevention against audit effort and process friction. That tradeoff is real, especially where legacy systems cannot expose transaction-level events or separate duties cleanly. Best practice is evolving, and there is no universal standard for proving live SoD across every platform, so organisations need to document the method used, the scope covered, and the exceptions accepted.
The most common edge case is a certified access review over a system that has no meaningful runtime enforcement. Another is third-party or shared automation, where multiple teams rely on one NHI and assume process ownership will preserve separation. The better approach is to treat compliance evidence as supporting material, not the control itself, and to tie it back to lifecycle and revocation discipline described in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs. For organisations formalising governance, ISO/IEC 27001:2022 Information Security Management is useful for framing risk treatment, while ISO/IEC 27002:2022 Information Security Controls helps translate that into practice.
One useful benchmark is that NHI Management Group notes 97% of NHIs carry excessive privileges, which is why SoD programmes that stop at attestation frequently miss the real exposure. In regulated environments, the gap becomes visible when auditors ask not just who had access, but whether incompatible access was ever used together in production.
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, NIST SP 800-53 Rev 5 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 | Excessive NHI privilege undermines SoD even when reviews are clean. |
| NIST CSF 2.0 | PR.AC-4 | SoD depends on access enforcement matching approved roles and duties. |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege is the baseline control behind effective segregation. |
| NIST AI RMF | Compliance must reflect live control operation, not documentation alone. | |
| CSA MAESTRO | Agentic and automated workflows can chain actions that defeat static SoD. |
Map every NHI to least privilege and remove cross-functional access paths that enable incompatible actions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
