Segregation of duties risks in 2026 expose IAM control gaps

At a glance

What this is: This is a governance analysis of segregation of duties risks, showing how role overlap, collusion, and lifecycle gaps weaken access controls.

Why it matters: It matters because SoD failures affect human IAM and NHI governance alike, especially where access approvals, recertification, and offboarding are still manual.

👉 Read Zluri's analysis of segregation of duties risks in 2026

Context

Segregation of duties is an identity governance control that prevents one actor from both initiating and approving high-risk actions. In practice, it depends on clean role boundaries, timely review, and reliable offboarding, which is why it often fails when organisations grow faster than their access model.

For IAM teams, the SoD problem is broader than finance or compliance. The same control logic applies when humans, service accounts, or automated workflows can accumulate conflicting privileges over time, especially in environments with frequent role changes and weak certification discipline.

Key questions

Q: How should organisations enforce segregation of duties in modern IAM programmes?

A: Start by mapping the real business process, not the org chart. Then separate initiation, approval, execution, and reconciliation across people and systems, and tie those checks to joiner, mover, and leaver events so access is revalidated when roles change. The control only works when identity reviews are continuous, not annual.

Q: Why do segregation of duties controls fail after mergers or reorganisations?

A: They fail because inherited access and approval chains often remain intact after the operating model changes. Two merged environments may have conflicting role definitions, duplicate privileges, and old admin paths that no longer match the new reporting structure. Without a full access rationalisation, SoD becomes a patchwork of exceptions rather than a control.

Q: What do security teams get wrong about collusion risk in SoD?

A: They often assume that separated roles mean independent behaviour. In reality, employees can share credentials, coordinate approvals, or work around process boundaries, which defeats the control even if the matrix looks correct. Teams need behavioural monitoring and exception review, not just role design, to detect when independence has collapsed.

Q: Should SoD controls also cover service accounts and automation?

A: Yes, because non-human identities can also accumulate conflicting privileges across request, execution, and approval paths. If a service account or automation account can both trigger and complete a sensitive action, the same separation logic should apply. Treat those identities as part of the governance model, not as exceptions to it.

Technical breakdown

How SoD failures emerge during mergers and access model consolidation

Mergers and acquisitions often merge two different role models before the target access graph is fully understood. That creates temporary overlap between authorisation, custody, record-keeping, and reconciliation functions. When access policies are not rationalised quickly, a user can inherit conflicting duties across systems, which is a structural SoD failure rather than a one-off exception. The risk is highest when inherited accounts, delegated approvals, and legacy admin rights remain in place after the organisational structure changes. In identity terms, the control failure is not simply excess privilege. It is the inability to re-establish clean separation after the operating model changes.

Practical implication: map conflicting access paths immediately after consolidation and remove overlapping approvals before business-as-usual resumes.

Why collusion defeats SoD even when role design looks correct

SoD assumes that separated roles behave independently. Collusion breaks that assumption by allowing two or more actors to coordinate outside the control design, whether by sharing credentials, manipulating workflows, or informally approving each other's actions. That means the issue is not only permission structure, but also the trust model behind the process. Even well-designed SoD matrices can fail if the organisation treats role separation as sufficient without monitoring behavioural relationships, audit trails, and exception patterns. In other words, SoD is a control over task division, not a guarantee of human independence.

Practical implication: pair SoD with monitoring for shared access, repeated exception approvals, and unusual cross-role coordination.

How lifecycle drift turns SoD into a standing privilege problem

SoD becomes fragile when joiner-mover-leaver processes lag behind real role changes. A user may move into a new function while keeping old access, creating privilege overlap that no longer matches the intended separation of duties. This is the same governance pattern that shows up in NHI programmes when service accounts keep old permissions after application or team changes. The core problem is lifecycle drift: access remains valid after the business reason for it has changed. Without certification and deprovisioning discipline, SoD turns into a paper control with little operational value.

Practical implication: tie SoD enforcement to mover and leaver events so conflicting access is removed when job scope changes.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

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

NHI Mgmt Group analysis

SoD is failing less because the principle is wrong and more because lifecycle controls do not keep pace with organisational change. The article’s core risk pattern is not just excess access, but access that survives role changes, mergers, and reorganisations long after the original segregation logic has expired. That is a governance failure, not a policy failure. Practitioners should treat SoD drift as evidence that access models are not being revalidated against the operating structure.

Collusion is the named failure mode that most SoD programmes underweight. Segregation assumes independent actors, but real environments depend on people, approvals, and exceptions that can be socially coordinated. Once credentials are shared or workflows are manipulated, the control is no longer about separation of duties but about separation in theory only. Practitioners should assume independence must be evidenced, not presumed.

SoD and least privilege are converging into the same identity governance problem across human and non-human actors. The article keeps returning to limiting access to only what is necessary, which is the same baseline that governs service accounts, API credentials, and privileged users. When the same actor can both request and approve, or persist across move and leave events, the identity model has already failed. Practitioners should unify SoD, access reviews, and privilege scope into one governance control plane.

Lifecycle gaps are the hidden multiplier in SoD failures. Manual certifications, delayed deprovisioning, and inconsistent approvals allow conflict to accumulate quietly until audit or incident response exposes it. The named concept here is access overlap drift, where legitimate changes leave behind incompatible permissions. Practitioners should reframe SoD as continuous identity hygiene rather than annual compliance housekeeping.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• For lifecycle governance context, see NHI Lifecycle Management Guide and Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

What this signals

Access overlap drift: SoD breaks when lifecycle events leave conflicting privileges behind, and that pattern is already visible across NHI programmes as well as human IAM. If an organisation cannot continuously reconcile mover and leaver events, it will keep discovering conflicts after the fact rather than preventing them.

The governance direction is clear: SoD, access review, and least privilege are converging into one continuous control discipline. Teams should align their review cycles with business change, then connect the process to role models, approval paths, and deprovisioning workflows so the control is measurable rather than implied.

For practitioners

• Rebuild the SoD matrix around actual business workflows Document which roles initiate, approve, record, and reconcile each sensitive process, then compare that map against live entitlements and delegated permissions.
• Trigger access revalidation on every mover event When a person changes role, automatically review conflicting access, inherited approvals, and dormant privileges before the new assignment is fully active.
• Instrument collusion indicators in approval workflows Watch for repeated cross-approvals, shared admin paths, exception stacking, and unusual combinations of requestor and approver behaviour.
• Extend SoD checks to non-human identities Apply the same conflict analysis to service accounts, API keys, and automation accounts that can both request and execute sensitive actions.

Key takeaways

• Segregation of duties is a lifecycle control as much as a compliance control, and it fails when access outlives the business reason for it.
• The biggest operational risks are role overlap, collusion, and unreviewed exceptions, not the abstract idea of SoD itself.
• Practitioners should unify SoD with access reviews, deprovisioning, and privilege scope management across human and non-human identities.

Key terms

• Segregation of Duties: A control that divides sensitive tasks so one identity cannot both initiate and approve the same high-risk action. In identity governance, SoD is a preventive design pattern that reduces fraud, error, and abuse by forcing independence between roles, approvals, and record-keeping.
• Access Overlap Drift: A governance failure where legitimate role changes leave behind permissions that no longer fit the actor's current function. The result is conflicting access that accumulates over time, making SoD and least privilege look intact on paper while breaking down operationally.
• Collusion Risk: The possibility that two or more actors coordinate to bypass a control that assumes independent behaviour. In SoD programmes, collusion can take the form of shared credentials, reciprocal approvals, or informal process workarounds that defeat the separation the control is meant to enforce.

Deepen your knowledge

SoD risk management, access review design, and lifecycle enforcement are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance programme that must hold across human and non-human identities, it is worth exploring.

This post draws on content published by Zluri: Security & Compliance Segregation of Duties (SoD) Risks to Address in 2026. Read the original.