Segregation of duties in IAM is the control gap auditors flag

At a glance

What this is: This is an analysis of segregation of duties in IAM and how conflicting permissions quietly accumulate into control failures.

Why it matters: It matters because IAM, PAM, and governance teams need to prevent one identity from spanning initiation, approval, and execution across sensitive workflows.

👉 Read SecurEnds' guide on segregation of duties in IAM

Context

Segregation of duties in IAM is a control that prevents one identity from holding permissions that should not exist together. The problem is usually not a single bad decision, but slow access drift as roles change, temporary approvals stay in place, and reviews fail to remove old entitlements.

In practice, that drift undermines auditability across human identity, service accounts, and privileged workflows. Sectors with finance, HR, and administrator access are especially exposed, because one conflicting role can remove the only meaningful checkpoint in a sensitive process.

Key questions

Q: How should security teams enforce segregation of duties in IAM?

A: Security teams should enforce segregation of duties by defining incompatible permission combinations, checking them during access requests, and monitoring for later drift. The key is to stop conflicting access before it is granted, then validate it through periodic reviews. If the control only exists in spreadsheets or audit evidence, it is not operating as a live IAM safeguard.

Q: Why do users end up with conflicting access in IAM programmes?

A: Users usually accumulate conflicting access through role changes, temporary approvals, emergency exceptions, and manual grants that are never cleaned up. The problem is governance drift, not just bad design. Over time, isolated permissions combine into a control failure that removes the separation auditors expect.

Q: What breaks when segregation of duties is missing from privileged access?

A: When segregation of duties is missing from privileged access, the same administrator can create identities, assign elevated roles, and hide the evidence of what changed. That removes independent oversight and makes misuse much harder to detect. In practice, privileged access without SoD turns one control plane into a single point of failure.

Q: How do access reviews help with segregation of duties?

A: Access reviews help by revealing conflicts that already exist, but they do not prevent those conflicts from being created. They work best when paired with preventive SoD checks in the request workflow. Used alone, reviews become a cleanup mechanism after privilege drift has already occurred.

Technical breakdown

Role combinations and conflict matrices in IAM

Segregation of duties works by defining incompatible permission combinations and checking them before access is granted. In most IAM programmes, that logic sits in an SoD matrix, which maps risky pairings such as request plus approval or create plus approve. The control is only effective if the matrix reflects current business processes and role definitions. When it drifts, the system can still issue access that looks legitimate on paper but breaks separation in practice.

Practical implication: maintain SoD matrices as living control artefacts, not audit leftovers.

How provisioning workflows enforce segregation of duties

The technical value of SoD appears when the access request workflow evaluates a new entitlement against existing access in real time. If the request creates a conflict, the system can block it or route it for higher review with the risk visible. That matters because manual checks happen too late and miss exceptions. Continuous monitoring also matters, since conflicts can appear after provisioning through role edits, manual grants, or integrations.

Practical implication: embed conflict checks in provisioning and continuously scan for post-provisioning drift.

Why access reviews alone do not close SoD gaps

Access reviews are a detection and cleanup mechanism, not a preventive one. They can reveal that a user already holds conflicting rights, but they do not stop the conflict from being created in the first place. That is why teams that rely only on certification cycles often discover SoD issues after the environment has already drifted. In mature IAM, reviews validate the preventive control instead of substituting for it.

Practical implication: use access reviews to verify SoD enforcement, not to replace it.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Segregation of duties fails when access is treated as a static assignment instead of a control relationship. The article describes the classic drift pattern: initial permissions are valid, then role changes and temporary approvals accumulate until one identity can complete a process end to end. That is not just overprivilege, it is the collapse of separation itself. The implication is that IAM governance must track permission combinations over time, not only entitlement counts.

SoD is a governance control, not just an access policy. The article correctly shows that the risky condition is the combination of permissions, not any one permission in isolation. That is why conflict matrices, workflow checks, and exception handling belong in identity governance rather than as a manual audit afterthought. Teams that treat SoD as a static rule set will miss the business-process change that creates the conflict.

Privileged access makes segregation of duties non-negotiable because one role can obscure both creation and oversight. When an administrator can create identities and assign high-risk roles, the same control plane can become both the source of access and the place where evidence disappears. That is the failure mode auditors look for in PAM-linked IAM programmes. Practitioners should view privileged role design as a separation problem first and an efficiency problem second.

Access reviews cannot rescue a broken SoD model after the fact. The article shows why periodic certification catches drift but does not prevent it. If users can request, approve, and retain access across a workflow, the review cycle is always late. The broader lesson is that SoD must be enforced where access is granted, otherwise governance becomes a cleanup exercise instead of a control.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, and 77% of those incidents resulted in tangible damage, according to the Ultimate Guide to NHIs.
• For the lifecycle side of the problem, NHI Lifecycle Management Guide shows why provisioning, rotation, and offboarding must be governed as one continuous control.

What this signals

SoD drift is really lifecycle drift. When access accumulates across role changes and temporary approvals, the issue is not just who can do what, but whether governance still knows why the entitlement exists. Teams that connect SoD to lifecycle management will catch conflicts earlier and reduce the number of exceptions that reach audit.

With 88.5% of organisations acknowledging that their non-human IAM practices lag behind or are merely on par with human identity management, the broader lesson is that separation controls are not keeping pace with modern access sprawl. That creates a governance gap across human users, service accounts, and privileged workflows that static review cycles will not close.

This is where OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 become useful reference points for practitioners. They reinforce a simple direction of travel: control the combination of entitlements, not just the identity record.

For practitioners

• Map conflicting roles before you automate provisioning Start with finance, HR, admin, and payment workflows, then document which permissions cannot coexist in the same identity. Keep the conflict matrix tied to current process ownership and review it whenever a role or approval path changes.
• Embed SoD checks into access request flows Use the IAM request path to evaluate existing entitlements against new requests before approval. If the combination is risky, block it or force a higher-level approval with the conflict clearly explained to reviewers.
• Monitor for post-provisioning role drift Scan for manual grants, role edits, and integration-driven permissions that create conflicts after the initial request. Treat new overlaps as control failures, not just policy exceptions, and route them to remediation owners immediately.
• Separate privileged administration from oversight tasks Avoid letting the same identity create users, assign privileged roles, and validate compliance evidence. Where separation is impossible in small teams, document compensating controls and make the exception visible to audit and governance owners.

Key takeaways

• Segregation of duties fails when one identity can initiate, approve, and execute the same sensitive process.
• The scale of the risk is governance drift, where valid permissions accumulate into conflicting access over time.
• Preventive SoD checks in provisioning matter more than after-the-fact reviews if teams want real control.

Key terms

• Segregation Of Duties: Segregation of duties is an access governance control that prevents one identity from holding permissions that let it complete a sensitive process alone. It reduces fraud and error by separating initiation, approval, execution, and oversight into different roles or control paths.
• SoD Matrix: An SoD matrix is a conflict map that lists role or permission combinations that should not exist in the same account. It turns policy into an enforceable rule set and must be updated as business processes, applications, and exceptions change over time.
• Access Drift: Access drift is the gradual accumulation of permissions beyond what a role originally required. It often happens through role changes, temporary approvals, manual grants, and unrevoked exceptions, and it is a primary reason SoD controls fail in mature IAM environments.

Deepen your knowledge

Segregation of duties in IAM and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is dealing with role drift, privileged overlap, or access review fatigue, it is worth exploring.

This post draws on content published by SecurEnds: Segregation of Duties in IAM. Read the original.