SOD risk analysis evaluates whether a role, account, or workflow contains conflicting permissions that could enable fraud or control bypass. It is used to identify toxic combinations before access is granted or after roles change, so governance teams can reduce exposure proactively.
Expanded Definition
SOD risk analysis, or segregation of duties risk analysis, is the practice of testing whether a role, account, or workflow contains permission combinations that could let one actor initiate, approve, and conceal a sensitive action. In NHI governance, that actor may be a service account, API client, CI/CD robot, or autonomous agent.
Unlike simple privilege review, SOD analysis focuses on toxic combinations across entitlements and process steps, not just on whether a permission is individually justified. The control objective is to prevent a single identity from accumulating end-to-end authority over actions that should be separated, such as code deployment and production approval, payment creation and payment release, or secret retrieval and secret rotation. Guidance varies across vendors on how much process context should be included, so definitions are still evolving for agentic systems and machine-to-machine workflows. For a standards-oriented baseline, NIST CSF 2.0 frames this work under access governance and risk management, while NIST SP 800-53 Rev. 5 provides control families that support authorization review and separation expectations.
The most common misapplication is treating SOD as a one-time audit checkbox, which occurs when organisations review static roles but ignore workflow changes, temporary privilege elevation, and NHI-to-NHI delegation.
Examples and Use Cases
Implementing SOD risk analysis rigorously often introduces slower access design and more review overhead, requiring organisations to weigh fraud prevention and control integrity against operational speed.
- A payroll service account can create vendor payments, but a separate approval identity must release them, preventing a single NHI from pushing fraudulent disbursements.
- A deployment bot may merge approved code, but production promotion is blocked unless a different workflow or human approver validates the release, aligning with patterns discussed in the Top 10 NHI Issues.
- An API key used to provision cloud resources is denied access to billing exports, so the same identity cannot both create and obscure cost or fraud signals.
- A secret-reading automation role is separated from the secret-rotation role, reducing the chance that one account can both extract credentials and control remediation.
- Agent workflows are tested against toxic permission paths before release, reflecting the same governance concerns described in the OWASP NHI Top 10.
In practice, teams often pair SOD rules with policy engines and access reviews so that exceptions are explicit, time-bound, and traceable rather than hidden inside broad service roles. NIST CSF 2.0 supports this approach by emphasizing governance, access control, and continuous risk oversight.
Why It Matters in NHI Security
SOD risk analysis matters because non-human identities frequently carry excessive privilege, and that makes a single misconfigured role enough to bypass multiple control layers. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges, which means toxic combinations are not edge cases but a structural governance risk. When the same identity can request, approve, and execute, attackers do not need many steps to turn a stolen secret into fraud, data exposure, or unauthorized production change.
This is especially important in environments where secrets are scattered, rotation is inconsistent, and ownership is unclear. The Ultimate Guide to NHIs highlights how common weak visibility and excessive privilege are, and the Why NHI Security Matters Now section explains why these weaknesses have become operationally urgent. In control terms, SOD analysis complements the access governance intent found in NIST SP 800-53 Rev. 5 and the programmatic risk management model in the NIST Cybersecurity Framework 2.0.
Organisations typically encounter SOD breakdowns only after a payment anomaly, unauthorized deployment, or audit failure, at which point the term 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 CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, 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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers overprivileged NHI paths that create toxic permission combinations. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions should be managed to prevent conflicting authority. |
| NIST SP 800-53 Rev 5 | AC-5 | Separation of duties is a direct control objective in access control governance. |
| NIST Zero Trust (SP 800-207) | PE-1 | Zero Trust requires fine-grained authorization that limits combined authority. |
| CSA MAESTRO | Agentic systems need workflow separation to prevent unsafe autonomous execution chains. |
Review NHI roles for conflicting permissions and remove paths that enable single-identity abuse.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
