Why do segregation of duties conflicts still happen in mature IAM programmes?

Why This Matters for Security Teams

SoD conflicts keep showing up because mature IAM programmes often optimise for administration, not for workflow risk. A role can look clean in a review and still allow one person or one service account to request, approve, and execute the same change path. That gap matters most where human approvals, emergency access, and delegated automation overlap. NIST’s NIST Cybersecurity Framework 2.0 frames access governance as an ongoing risk function, not a one-time role design exercise.

In NHI-heavy environments, the issue becomes harder because service accounts, API keys, and pipeline identities often inherit broad permissions that were originally intended for operational continuity. NHIMG’s research shows only 5.7% of organisations have full visibility into their service accounts, which makes SoD conflicts easy to miss until audit or incident response forces the question. When access is spread across code, CI/CD, and cloud control planes, separation failures are usually hidden inside normal delivery patterns rather than obvious policy violations. In practice, many security teams encounter SoD breakdowns only after an exception has already been used to complete a risky workflow, rather than through intentional control testing.

How It Works in Practice

Effective SoD in a mature IAM programme starts with mapping business tasks, not just entitlements. The question is not whether a user has two roles, but whether a single identity can complete a harmful sequence without an independent control point. That means analysing request, approve, deploy, administer, and revoke paths across both human and non-human identities. In cloud and DevOps settings, this often includes service accounts, workload identities, and automation tokens that can bypass manual review if they are granted standing privilege.

A practical model usually combines role design, policy checks, and short-lived access:

• Separate request and approval functions at the workflow layer, not only in the IAM directory.
• Use just-in-time access for elevated tasks so privileges expire when the task ends.
• Prefer workload identity and short-lived credentials over shared or long-lived secrets.
• Evaluate policy at request time so context, environment, and task purpose are visible.
• Log approval, execution, and revocation events in a way that preserves an auditable chain.

This is where standards and research converge. NIST CSF 2.0 supports governance, identity, and access control as continuous capabilities, while the NIST AI RMF is useful when autonomous systems can initiate privileged actions without a predictable human pattern. For NHI-specific controls, NHIMG’s Ultimate Guide to Non-Human Identities is a useful reference point because SoD failures often arise when non-human identities inherit broad operational access. The related Azure Key Vault privilege escalation exposure research shows how apparently narrow permissions can still be chained into broader control if inheritance is not reviewed carefully. These controls tend to break down when emergency access is exempted from review for long periods because temporary operational shortcuts become permanent privilege paths.

Common Variations and Edge Cases

Tighter SoD usually increases delivery friction, so organisations have to balance control strength against operational speed. That tradeoff is real in incident response, regulated change windows, and high-volume automation, where rigid approval chains can slow remediation. Current guidance suggests distinguishing between standing authority and time-bound exception handling rather than eliminating exceptions entirely.

One common edge case is shared operational responsibility between platform teams and security teams. If the same identity can both define and approve policy changes, the SoD boundary collapses even when the work is “team-owned.” Another is machine-to-machine workflows, where a pipeline identity can trigger a deployment, update a secrets store, and then validate success without an independent check. Best practice is evolving toward context-aware authorisation for these cases, but there is no universal standard for this yet. The safest approach is to treat every identity path that can both create and exploit privilege as a SoD candidate, even if it is automated and not user-facing.

For mature programmes, the biggest blind spot is often exception drift. Emergency roles, break-glass accounts, and temporary vendor access are created for legitimate reasons but not consistently retired. Over time, those exceptions become the real privilege model, and the formal SoD design becomes documentation rather than control.

Related resources from NHI Mgmt Group

• Why do passwordless deployments still create risk in human IAM programmes?
• What does the 144:1 NHI-to-human ratio mean for IAM governance programmes?
• Why do MFA fatigue attacks still work in mature IAM programmes?
• Why does authentication complexity create security risk for IAM programmes?