Security teams should evaluate exclusion rules at request time, not just during periodic review. If a proposed entitlement creates a conflict, the workflow should block it, escalate it, or send it to a higher-trust approver. That keeps the control preventive and gives reviewers the context they need before access becomes active.
Why This Matters for Security Teams
Separation of duties is only effective when conflict detection happens before an entitlement becomes active. For non-human identities, that matters even more because service accounts, API keys, and automation tokens can be created or reused at machine speed. The control should stop toxic combinations at request time, not rely on a later audit to notice them after the fact. That is why NHI governance needs preventive checks aligned to the OWASP Non-Human Identity Top 10 and the broader lifecycle risks highlighted in the Ultimate Guide to NHIs.
Security teams often get this wrong by treating SoD as a review-cycle issue instead of an admission-control issue. By the time periodic recertification finds the conflict, the account may already have executed deployments, changed infrastructure, or accessed sensitive data. NHIMG research shows only 1.5 out of 10 organisations are highly confident in securing NHIs, which is a useful indicator of how much hidden entitlement risk still exists in practice. In practice, many security teams encounter SoD failures only after a privileged workflow has already combined incompatible access paths, rather than through intentional prevention.
How It Works in Practice
The practical pattern is straightforward: define exclusion rules, evaluate them automatically at request time, and block or escalate any request that creates a conflict. For example, the same NHI should not be allowed to both approve a production change and execute the deployment that implements it. If a machine workflow needs both steps, the system should route one step to a different identity or a higher-trust approver.
Current best practice is to make this evaluation context-aware. That means the policy engine considers the requested resource, environment, role combination, ticket metadata, and the identity’s existing entitlements before issuing access. This is consistent with OWASP Non-Human Identity Top 10 guidance on least privilege and with the control objectives in the Ultimate Guide to NHIs — Key Challenges and Risks.
- Use policy-as-code so SoD rules are versioned, reviewed, and testable.
- Evaluate conflicts at the point of access grant, not only during quarterly access reviews.
- Separate request, approve, and execute functions across different identities where possible.
- Record the reason for any escalation so reviewers can see why the exception exists.
- Revoke or time-limit the entitlement if the workflow cannot be completed safely.
Teams that already use PAM, RBAC, or JIT still need a dedicated SoD layer because role membership alone does not prevent two conflicting entitlements from being active at the same time. These controls tend to break down in highly automated CI/CD environments because identities are created dynamically, permissions are chained across tools, and the conflict only becomes visible after the workflow has already started.
Common Variations and Edge Cases
Tighter SoD enforcement often increases workflow friction, so organisations have to balance strong prevention against operational speed. That tradeoff is especially visible in engineering and DevOps pipelines, where a single automation path may legitimately need multiple permissions but still must not concentrate incompatible authority in one identity.
There is no universal standard for every SoD pattern yet, but current guidance suggests using different approaches for different risk levels. Low-risk requests may be auto-blocked when conflicts are detected. Higher-risk requests may be routed to a separate approver, a break-glass path, or a time-bound exception with explicit expiry. For service accounts that support critical production jobs, the safer pattern is usually split identities rather than exceptions. That aligns well with Ultimate Guide to NHIs recommendations on lifecycle control and with policy-led governance models described in the OWASP Non-Human Identity Top 10.
Edge cases also matter in shared platforms. If a vendor-managed automation identity, a human operator, and a deployment bot all touch the same system, the control must consider the effective combination of privileges, not just the nominal role label. In practice, many teams only discover the conflict after a production incident or a failed audit, which is a sign the SoD rule was never enforced at the point where it actually mattered.
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 least privilege and excessive NHI access, core to pre-grant SoD checks. |
| NIST CSF 2.0 | PR.AC-4 | Access authorization must enforce approved, least-privilege entitlements. |
| NIST AI RMF | Govern and manage AI-enabled access decisions with accountability and oversight. |
Use AI RMF governance to ensure automated access decisions are reviewable and accountable.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
