Ownership should sit with the identity governance function, but enforcement needs input from application owners, risk teams, and audit stakeholders. The goal is to stop one identity from holding conflicting rights across a process, not just inside one system. SoD must be enforced across workflows, not only within a single application boundary.
Why This Matters for Security Teams
segregation of duties becomes a governance problem, not just an access review problem, when one identity can influence multiple steps in the same business process. A user may be clean inside each application and still be able to approve, provision, and reconcile the same workflow end to end. That is why ownership belongs with identity governance, while enforcement depends on app owners, risk, and audit to define what combinations are unacceptable. The challenge is especially sharp for non-human identities, where standing access and embedded secrets can traverse systems unnoticed.
NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which makes workflow-level conflict detection far more urgent than single-app review. Security teams also need to account for how these rights compose across automation, because the risk is usually created by the path between tools, not the permissions inside one tool. OWASP’s OWASP Non-Human Identity Top 10 reinforces that NHI exposure is often systemic rather than isolated. In practice, many security teams discover SoD failures only after a fraud review or incident response finding exposes a workflow that no single owner had mapped.
How It Works in Practice
Effective SoD ownership starts with identity governance defining the control objective, then translating business process conflicts into enforceable policy. Application owners provide the permission model for their systems, risk teams define the conflict matrix, and audit validates whether the control is being applied consistently. The operating question is not “who can do what in App A,” but “which identities can combine actions across App A, App B, and the workflow engine without creating an unacceptable conflict.”
Practically, that means cataloguing workflow roles, not just app roles, and tying them to identities, entitlements, and service accounts. For NHIs, the identity governance team should require:
- workflow-level entitlement mapping for humans and NHIs
- conflict rules for approve, create, modify, and reconcile actions
- exception handling with time limits and documented compensating controls
- periodic recertification of cross-app access paths
- logging that shows the full chain of actions, not only the final transaction
Current guidance suggests that policy should be evaluated at the process level wherever an identity can trigger multiple tool actions, especially in automation-heavy environments. The NHI risk picture in the Ultimate Guide to NHIs — Key Challenges and Risks is consistent with this approach, because overprivileged identities amplify any SoD gap. For implementation discipline, CISAs and standards bodies generally favour centralized governance with local ownership for enforcement, rather than leaving each app team to invent its own conflict rules. These controls tend to break down when the workflow spans legacy systems and custom integrations because the end-to-end entitlement path cannot be reconstructed reliably.
Common Variations and Edge Cases
Tighter SoD enforcement often increases operational overhead, requiring organisations to balance fraud prevention against process friction and exception management. That tradeoff is real, especially when a single team owns both configuration and operations in a small environment. Current guidance suggests using risk-tiered SoD: strict separation for payment, release, or production-change workflows, and lighter controls for low-impact approvals where business continuity matters more than hard separation.
There is no universal standard for this yet, but the strongest pattern is to keep ownership of policy in identity governance and delegate control design to the domain that understands the workflow. This becomes more complex when NHIs act on behalf of humans, because an agent or service account may inherit multiple app privileges that were never intended to be combined. In those cases, the conflict matrix should include both direct privileges and delegated actions, especially when automation can approve, route, and execute without human intervention.
Organisations should also watch for edge cases where one workflow is split across SaaS, on-premises systems, and APIs. Those environments often need manual control evidence until access telemetry is unified. Best practice is evolving, but the core principle remains stable: ownership sits with identity governance, while the business, risk, and audit functions define and verify the conflicts that matter most.
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-03 | Workflow-spanning NHI privileges create SoD conflict risk. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be managed consistently across systems. |
| NIST AI RMF | GOVERN | Cross-workflow automation needs accountable governance and oversight. |
Assign clear owners for SoD policy, exceptions, and monitoring across automated workflows.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
