Segregation of duties exposes the IAM gap in access governance

At a glance

What this is: This is a guide to segregation of duties and its role in access governance, with the key finding that SoD breaks down when identity lifecycle and review processes are too weak to stop privilege concentration.

Why it matters: It matters because IAM teams cannot treat SoD as a policy exercise alone; they need lifecycle, certification, and remediation controls that keep conflicting access from accumulating across human and non-human identities.

Context

Segregation of duties, or SoD, is an internal control that splits critical steps in a process across different people so no single account can complete and conceal a high-risk action end to end. In IAM terms, that only works when access rights, approvals, and review cycles are tightly governed.

Zluri frames SoD as a compliance and fraud-control issue, but the underlying IAM problem is broader: role sprawl and delayed offboarding create conflicting access that outlives its business justification. When access governance is weak, SoD becomes a matrix exercise instead of a control that actually limits privilege concentration.

The article also shows why SoD is now being operationalised through IGA tooling rather than manual review alone. That is a typical challenge in mature enterprises, where the control objective is clear but enforcement is hard to sustain at scale.

Key questions

Q: What breaks when separation of duties is not enforced in IAM governance workflows?

A: When separation of duties is weak, the same person can request, approve, and retain conflicting access, which undermines control integrity. That creates hidden fraud risk, audit gaps, and exceptions that are difficult to explain later. In practice, organisations lose confidence that access approvals reflect genuine business need rather than convenience or process drift.

Q: Why do weak SoD controls create compliance and audit risk?

A: Weak SoD controls allow conflicting permissions, self-approval paths, and excessive privilege to persist across systems. Auditors treat that as evidence that internal controls are not operating effectively, which can lead to findings under frameworks that expect demonstrable governance over sensitive transactions and access.

Q: How do teams know whether an SoD programme is actually working?

A: An SoD programme is working when conflicting access is prevented at provisioning, surfaced during certification, and removed quickly when role changes occur. If violations keep appearing in review cycles or after offboarding, the control is reporting risk rather than reducing it.

Q: What is the difference between a potential SoD violation and an actual SoD violation?

A: A potential SoD violation exists when a user has the permissions to perform both sides of a sensitive transaction, but has not yet done so. An actual SoD violation exists when the user has executed both sides. The first is a control warning. The second is evidence of active policy breach and should trigger immediate remediation and review.

Technical breakdown

How SoD conflicts emerge in role-based access control

SoD conflicts appear when one identity accumulates roles that should remain separate across a business process, such as requesting, approving, and reconciling the same transaction. In RBAC terms, the problem is not the role model itself but the way conflicting entitlements are allowed to coexist. When teams map process steps directly to roles without checking combinations, they create hidden control overlap that looks compliant on paper but concentrates decision power in practice.

Practical implication: Model conflicting role combinations explicitly and review them at the entitlement level, not just at the user level.

Why SoD violations are harder to control than SoD conflicts

A conflict is a potential separation problem, while a violation is the point at which a user actually exercises an unauthorized combination of duties. That distinction matters because many organisations stop at identifying conflicts and never operationalise the evidence path needed to detect violations in live systems. The article’s emphasis on access review and audit reporting reflects the real control question: whether teams can prove that conflicting access was removed before it was used.

Practical implication: Instrument access reviews so they detect actual use of incompatible privileges, not only policy-defined risk.

Why the SoD matrix becomes an IAM governance control, not just a spreadsheet

An SoD matrix is a catalogue of incompatible role combinations, but in a modern identity programme it becomes a governance layer only when it is tied to provisioning, certification, and remediation. Without that linkage, the matrix documents risk without reducing it. The article’s IGA emphasis shows the practical shift from static policy definition to continuous enforcement across onboarding, access changes, and offboarding.

Practical implication: Tie the SoD matrix to provisioning and review workflows so violations trigger removal rather than manual escalation.

NHI Mgmt Group analysis

SoD is now an access governance discipline, not just an audit control. The article makes clear that separation of duties only holds when identity lifecycle and certification processes are connected to entitlement decisions. In modern IAM programmes, the issue is not whether the policy exists but whether access sprawl and weak offboarding keep contradicting it. Practitioners should treat SoD as an operational control that must be enforced continuously, not as a periodic compliance artifact.

Privilege concentration is the real failure mode behind SoD drift. The guide repeatedly points to one person holding too much control across a process as the risk condition. That is the same failure pattern identity teams see when role mining, role assignment, and access reviews are not aligned. The practical conclusion is that SoD breaks down first at entitlement design and then at review discipline, not at the policy statement itself.

SoD governance is strongest when it is embedded in IGA workflows. Zluri’s discussion of automated certification, onboarding, offboarding, and reporting shows where the control boundary now sits. Manual matrices cannot keep pace with role changes in large environments, especially where access changes faster than review cycles. The field is moving toward governed enforcement, and teams that still separate policy from provisioning will keep generating the same conflicts.

Identity governance assumptions fail when access can accumulate faster than it is reviewed. SoD was designed for stable role assignments and clear responsibility boundaries. That assumption breaks when users, contractors, or service identities gain overlapping entitlements through repeated changes, exceptions, and delayed revocation. The implication is that access governance must be built to prevent entitlement accumulation, not merely document it after the fact.

Named concept: privilege concentration drift. This is the point at which SoD becomes progressively weaker because access reviews, role changes, and exception handling no longer keep pace with real entitlement growth. It is not just a policy gap but a lifecycle problem that turns a clean matrix into a misleading control surface. Practitioners should recognise this as a governance drift condition that requires continuous enforcement.

From our research library:

• Nearly 60% of IT leaders cite restrictive cost and complexity as a weakness of legacy identity governance, according to the 2025 State of Identity Governance Report.
• Read next: IGA Buyer's Guide

What this signals

Privilege concentration drift: SoD weakens when entitlement growth, role changes, and exception handling outpace certification cycles. That is the control pattern IAM teams should watch, because a clean matrix means little if access keeps accumulating faster than it is reviewed.

The strongest SoD programmes treat access governance as a lifecycle problem, not a policy library. That means provisioning, offboarding, and review processes have to work together or conflicting access will keep reappearing in new forms.

For practitioners

• Map incompatible duties into the entitlement model List the process steps that must never sit in the same identity path, then encode those conflicts directly into roles and access policies so provisioning can block them before they land.
• Review SoD violations separately from SoD conflicts Treat potential conflicts as design issues and active violations as live control failures, then route violations into removal and investigation workflows rather than general access review queues.
• Tie offboarding to SoD exception closure When an employee or contractor changes role, remove conflicting entitlements first and close any temporary exception before the identity is allowed into a new duty path.
• Automate access certification for high-risk role combinations Build recurring certification around the combinations that create approval, custody, and record-keeping overlap, and require business owners to attest to each exception explicitly.

Key takeaways

• SoD remains a core IAM control because it prevents a single identity from controlling every critical step in a process.
• The practical failure mode is privilege concentration, where role sprawl and delayed reviews let conflicting access persist.
• The control works best when the SoD matrix is tied to provisioning, certification, and offboarding workflows.

Key terms

• Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
• SoD Conflict: An SoD conflict is a risky combination of entitlements that lets one identity perform actions that should be separated for control, fraud, or compliance reasons. The conflict may be invisible inside a single application and only appear when permissions are combined across systems or reused through delegated access.
• SoD Violation: A SoD violation occurs when an identity actually performs incompatible duties that policy says must remain separate. Unlike a theoretical conflict, it represents active control breakdown and is usually the point at which investigation, remediation, and audit evidence become necessary.
• Privilege Concentration: Privilege concentration occurs when one identity holds enough authority to move through multiple control points without meaningful interruption. It is a structural governance problem because it reduces oversight, increases fraud opportunity, and makes later review less effective at detecting misuse.

Deepen your knowledge

Identity lifecycle management, secrets management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.