Segregation of duties risks in 2026 expose IAM control gaps

At a glance

What this is: This is a 2026 analysis of segregation of duties risk in IAM, showing that the main failure mode is not the rule itself but overlapping access, weak approvals, and access reviews that trail organisational change.

Why it matters: It matters because IAM, IGA, PAM, and audit teams need SoD controls that actually prevent conflicting access paths, especially during mergers, role changes, and high-volume access administration.

Context

Segregation of duties is an identity governance control that separates approval, custody, record-keeping, and reconciliation so the same person cannot create and approve a risky action. In practice, the control only works when role design, access review, and approval routing stay aligned with how work actually gets done.

The article’s core problem is that SoD breaks down when organisations treat it as a static policy rather than a living access model. That failure shows up in merger integration, overlapping admin permissions, concentrated approvers, and delayed certification cycles that let privilege drift outrun governance.

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: How often should organisations run a segregation of duties analysis in a dynamic environment?

A: The right cadence depends on how much change the organisation introduces. Weekly analysis fits medium sized organisations with moderate changes, while large complex environments with daily provisioning, patches, or configuration changes should run it daily. Quarterly review may be enough only for very stable environments. Waiting a full year is too slow in modern systems because risks and audit findings can accumulate between cycles.

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 should security teams do when role overlap creates SoD conflicts?

A: Security teams should remove the overlapping privileges first, then redesign the approval and certification path so the conflict cannot reappear. That means separating execution from approval, tightening exception handling, and aligning access reviews to the actual job change that created the conflict.

Technical breakdown

Why SoD fails when access and approval paths overlap

Segregation of duties depends on separating the ability to initiate an action from the ability to approve or record it. When a user can both grant access and approve changes, or when role mergers collapse distinct responsibilities into one account path, SoD becomes a paper control. The technical failure is not just excessive privilege, but conflicting privilege combinations that cross business systems, especially when identity data is not reconciled after organisational changes. In IAM terms, the risk is a broken authorisation model, not simply a missing policy document.

Practical implication: Map conflicting entitlement combinations across systems and remove any path that lets one identity both execute and authorise the same workflow.

How mergers and acquisitions create SoD drift

Mergers and acquisitions frequently merge duplicate functions, inherited roles, and multiple access models into one operating environment. That creates entitlement sprawl because permissions from both organisations persist while governance teams are still normalising roles, approvals, and system ownership. SoD is vulnerable here because the post-merger state often contains overlapping admin rights, inconsistent approval chains, and unresolved exceptions. The control gap is temporal as much as structural: access that was acceptable in one entity becomes conflicting once the operating model changes.

Practical implication: Revalidate all inherited roles and approval routes after merger integration and treat inherited access as temporary until conflicts are removed.

Why access reviews and certification matter more than static policy

SoD only holds if access certifications keep pace with movement across roles, systems, and responsibilities. The article points to a familiar governance gap: access reviews that happen too late to catch privilege creep, especially when administrative workloads delay certification cycles. In effect, the identity programme is judging yesterday’s access while today’s permissions have already shifted. That is why SoD is best treated as a lifecycle control, not a one-time design choice. Without periodic review, exceptions become normalised and audit findings follow.

Practical implication: Tie SoD reviews to mover, joiner, and leaver events so conflicting access is removed when role changes occur, not at the next annual review.

Threat narrative

Attacker objective: The objective is to gain conflicting access that enables unauthorised approvals, manipulation, or fraudulent execution without effective checks and balances.

1. Entry occurs when users inherit overlapping entitlements during organisational change or role assignment, creating conflicting access paths across business systems.
2. Escalation follows when the same identity can approve, modify, and execute actions that should be separated by SoD policy.
3. Impact appears as fraud exposure, audit findings, operational errors, and weakened accountability because the control no longer distinguishes who can do what.

NHI Mgmt Group analysis

SoD is failing less because organisations lack policy and more because identity governance is lagging organisational change. The article describes a familiar control trap: roles change faster than access models, so conflicting entitlements survive long after the business process has moved on. The practitioner lesson is that SoD has to be governed as a live entitlement state, not a compliance document.

Merger-driven entitlement sprawl is the most dangerous SoD failure mode in this article. When two organisations combine, inherited approvals, duplicate admin rights, and unresolved exceptions create a governance fog in which no one can easily prove which access combinations are still valid. That makes post-merger access reconciliation a first-order identity control problem.

Access review lag turns SoD into a retrospective control that arrives after the risk has already materialised. The article shows that certification only works when it is timed to role movement, system changes, and administrative handoffs. For practitioners, the implication is straightforward: if reviews trail privilege drift, the SoD programme becomes evidence of governance activity rather than a mechanism for preventing conflict.

SoD remains a cross-domain control that links IAM, IGA, PAM, and audit in one operating model. This is why the article matters beyond finance teams. The same separation logic must govern entitlement assignment, elevated access, reviewer independence, and exception handling if the control is to survive real-world operational pressure.

Identity governance needs a specific concept for this problem: entitlement conflict drift. That is the slow accumulation of overlapping roles, inherited access, and delayed reviews that gradually dissolves SoD boundaries. The practical conclusion is that teams should look for drift as a structural indicator of failing governance, not as an isolated permission issue.

What this signals

Entitlement conflict drift: this is the slow accumulation of overlapping roles, inherited permissions, and delayed reviews that erodes SoD even when the policy still exists on paper. IAM and IGA teams should treat it as a lifecycle signal, not a one-off access exception.

SoD governance gets harder when merger activity, role changes, and approval centralisation all happen at once. The practical programme response is to make identity review events follow business change, so access is corrected while the organisation is still remodelling itself.

For practitioners

• Map conflicting access paths Identify where one identity can both create and approve sensitive transactions, then remove those entitlement combinations from business-critical workflows.
• Reconcile inherited access after mergers Treat post-merger roles, approvals, and admin rights as provisional until every conflicting privilege has been reviewed and either remediated or formally justified.
• Tie SoD to lifecycle events Trigger certification and exception review when employees move roles, join new teams, or leave functions that formerly granted authority over the same process.
• Separate approvers from executors Ensure no approver can also execute or modify the same control path in financial, access, or change-management workflows.

Key takeaways

• Segregation of duties fails most visibly when a single identity can both approve and execute the same sensitive workflow.
• The article shows that merger integration, access overlap, and review lag are the main conditions that let SoD drift become operational risk.
• Practitioners need lifecycle-tied access review, approval separation, and entitlement reconciliation to keep SoD effective in real environments.

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.
• Entitlement Conflict: A condition where one identity holds permissions that should be kept separate because they create conflicting authority over the same business process. In practice, this often appears as overlapping admin, request, and approval rights after role changes or merger integration.
• Access Review Lag: The delay between a role or permission change and the review that should confirm whether that access is still appropriate. When the lag grows, SoD becomes retrospective and conflicting access can remain active long enough to create audit or fraud risk.
• Privilege Drift: Privilege drift is the gradual gap between the permissions an identity was meant to have and the permissions it actually retains. In AI agent environments, drift grows quickly because roles are reused, tasks change, and lifecycle reviews often lag behind deployment velocity.

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.