How do SoD rules fit into identity governance programmes?

Why SoD Belongs Inside Identity Governance, Not Beside It

Segregation of Duties, or SoD, is not a standalone control island. It is the conflict-definition layer that tells identity governance programs which entitlement combinations create unacceptable risk, then ties those rules to provisioning, certification, and remediation workflows. That matters because SoD only works when it is enforced at the point of decision, not reviewed after the fact. NIST’s Cybersecurity Framework 2.0 frames this as governance and access control working together, rather than as disconnected checklists.

The practical challenge is that many organisations treat SoD as an audit artifact instead of an operational control. When that happens, conflicts pile up in ERP, cloud, and privileged access paths, while reviewers only see them during periodic certification. The result is a program that detects risk late and remediates inconsistently. NHIMG research on Regulatory and Audit Perspectives shows why governance must connect policy, evidence, and enforcement across the full lifecycle.

In practice, many security teams encounter SoD violations only after a toxic combination has already been used to approve, modify, or move sensitive access, rather than through intentional prevention at grant time.

How SoD Rules Operate Across the IGA Lifecycle

In a mature identity governance and administration program, SoD rules are evaluated at multiple points. During request and approval, the system should block or escalate access that would complete a conflict pair. During provisioning, the entitlement engine should prevent unsafe combinations from being granted together. During access reviews, certifiers should see active conflicts and decide whether exceptions are still justified. During remediation, the workflow should remove one side of the conflict or force compensating controls.

That lifecycle view is consistent with NHI lifecycle guidance and with NIST CSF 2.0’s emphasis on continuous governance, not one-time approval. It also aligns with the broader lesson in the 2024 ESG Report: Managing Non-Human Identities, where compromised identities were common enough to show that entitlement sprawl becomes an operational security issue, not just a compliance issue.

• Define SoD rules in business terms first, then translate them into entitlement pairs or role combinations.
• Map rules to systems of record, because the same conflict may look different in ERP, cloud, or PAM.
• Use preventive controls for high-risk conflicts and detective controls for legacy exceptions.
• Track exceptions with expiration dates, ownership, and compensating controls.

Best practice is evolving toward policy-as-code and real-time evaluation, but there is no universal standard for every platform yet. Organisations still need a governance layer that reconciles risk appetite with how the target applications actually enforce access. These controls tend to break down when entitlements are hidden inside nested roles, inherited groups, or manually assigned admin privileges because the true effective access is difficult to calculate reliably.

Where SoD Programs Usually Fail and What Mature Teams Adjust

Tighter SoD enforcement often increases operational overhead, requiring organisations to balance strong conflict prevention against request friction and exception handling. That tradeoff is real, especially where business processes need temporary dual control or where legacy systems cannot express conflicts cleanly.

Current guidance suggests three common failure modes. First, rule sets become too broad, so reviewers see noisy alerts and start rubber-stamping exceptions. Second, rules are too narrow, so real conflicts slip through because they were never modeled. Third, the program is built around human user roles only, while service accounts, machine identities, and automation tokens remain outside scope. That gap matters because modern environments use more than human access paths, and NHIMG’s 2026 Infrastructure Identity Survey found 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.

Mature teams usually respond by tightening rule ownership, reducing false positives, and separating policy design from enforcement mechanics. They also align SoD with Top 10 NHI Issues because the same governance mistakes that affect human entitlements also show up in non-human accounts, especially where automation can accumulate privileges faster than a quarterly review can catch them.

The approach works best when access models are stable and well-instrumented. It breaks down in highly dynamic cloud environments with ad hoc admin paths, inherited permissions, and weak ownership over service accounts.

Related resources from NHI Mgmt Group

• Why is it important to integrate identity and data governance?
• What does the 144:1 NHI-to-human ratio mean for IAM governance programmes?
• What makes agentic AI an NHI governance issue?
• What is the difference between attack surface management and NHI governance?