Separation of duties in 2026: what IAM teams should watch

At a glance

What this is: This is a 2026 SoD guide showing that separation of duties has become an identity governance problem as much as a finance control, because access workflows can re-concentrate power even when policy language looks sound.

Why it matters: For IAM, IGA, PAM, and NHI programmes, the issue is whether provisioning, approval, review, and recovery are actually separated in workflow, or whether a single operator can still control the full access lifecycle.

Context

Separation of duties is a control design problem, not just a policy statement. In identity programmes, the question is whether one person or one workflow can initiate access, approve it, and later validate or reconcile the same access path.

Zluri’s guide frames SoD across access provisioning, access reviews, backup recovery, vendor management, and SaaS administration. That makes it relevant to IAM and IGA teams because the control boundary now sits inside identity workflows, not only inside finance or audit.

The practical governance issue is whether the organisation has separate actors and separate evidence for each critical step. If the same operational path can carry request, approval, execution, and review, SoD becomes nominal rather than enforced.

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 backup and recovery tasks need separate ownership?

A: Backup and recovery need separate ownership because the same operator should not be able to create, verify, and restore the same data set without oversight. That concentration creates a privileged path for concealment or misuse, and it weakens confidence in recovery evidence. Independent verification matters as much as restore capability.

Q: How do security teams know if SoD controls are actually working?

A: SoD controls are working only if live access state matches the approved separation model across systems. Teams should verify that no identity can both initiate and validate the same sensitive transaction, and that exceptions are time-bound and independently reviewed. If certification reports look clean but operational workflows still allow self-approval, the control is failing.

Q: What is the difference between role separation and workflow separation in SoD?

A: Role separation assigns different people to different duties, while workflow separation ensures the system itself cannot route all critical steps through one control path. Both matter, but workflow separation is what stops automation from recreating the same concentration of authority. In practice, organisations need both to prevent SoD from becoming ceremonial.

Technical breakdown

How separation of duties fails in access provisioning workflows

Separation of duties breaks when access request, approval, provisioning, and review are handled by the same system owner or by tightly coupled workflow roles. In practice, the control is not only about who has permission to act, but about whether the approval trail is independent from the execution trail. That matters in SaaS environments because access changes are often fast, delegated, and repeatable, which makes “temporary” concentration of authority easy to overlook. When the same actor can raise, approve, and fulfil a request, SoD exists on paper but not in operation.

Practical implication: split request, approval, and fulfilment into separate identity roles with distinct audit evidence.

Why backup and recovery are also SoD problems

Backup and recovery become an SoD issue when one administrator can both preserve data and restore it without independent oversight. The control concern is not merely availability. It is also abuse prevention, because someone who can create backups, test restores, and execute recovery can conceal or overwrite activity without a second check. Zluri’s example shows that recovery authority is a privileged control path, especially when a single operator controls both the backup chain and the recovery action. SoD here is about separating custody from verification.

Practical implication: require independent verification and separate recovery authority for backup operations.

How vendor and SaaS administration create SoD drift

Vendor management and SaaS governance often combine procurement, contract approval, entitlement assignment, and ongoing performance review in one team. That concentration creates SoD drift because the same function can select the vendor, approve the commercial relationship, and then manage the access or payment consequences of that choice. In identity terms, the control gap is lifecycle concentration: offboarding, contract change, and access revocation do not stay independent. Once vendor access and payment authority overlap, accountability becomes difficult to prove and harder to challenge.

Practical implication: separate vendor selection, contract approval, entitlement management, and performance review into different owners.

Threat narrative

Attacker objective: The objective is to concentrate authority over a business process long enough to hide errors, misstate records, or gain unauthorized control without detection.

1. Entry occurs through a combined access or process workflow where one operator can initiate a change and steer it through approval without independent challenge.
2. Escalation follows when that same operator can provision access, reconcile records, or recover data, giving them control over both the action and the evidence.
3. Impact is policy failure rather than a single exploit: fraud, error concealment, or unauthorized access can persist because no independent control interrupts the chain.

Breaches seen in the wild

• New York Times GitHub breach 2024: An exposed GitHub token gave an attacker The New York Times' repositories; the 270GB leak held 4,875 unique secrets.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SoD is becoming an identity governance control, not just a finance control. The Zluri guide shows that the real risk now sits in access workflows, backup operations, vendor governance, and SaaS administration. When identity teams let request, approval, fulfilment, and review collapse into one operating chain, the control loses its independence. The practitioner conclusion is simple: SoD must be enforced in the identity workflow, not assumed in the policy document.

Access provisioning is the most common place where SoD quietly fails. Modern SaaS workflows compress human review into fast approvals and delegated actions, which makes role separation look present while actually being procedural only. This is where IAM and IGA teams need to be strict about distinct actors, distinct approvals, and distinct evidence. The practical conclusion is that provisioning should never be allowed to validate itself.

Backup recovery is a privilege boundary, not an operational detail. If one operator can back up data, verify it, and restore it without independent oversight, the organisation has created a hidden privileged path. That hidden path matters as much for misuse as it does for failure recovery. The practitioner conclusion is that recovery authority deserves the same scrutiny as any other elevated access path.

Vendor management shows why SoD must extend beyond the employee lifecycle. Procurement, contract approval, access assignment, and performance review often drift together in practice, especially when SaaS owners also control entitlement decisions. That creates accountability ambiguity when access should end or contracts change. The practitioner conclusion is that third-party lifecycle governance needs its own separation model, not a borrowed HR process.

Separation of duties only works when the evidence trail is independently trustworthy. A named concept here is access-path concentration: the same person or workflow can create, approve, and reconcile the same entitlement path. That is the control failure this article exposes across multiple examples. The practitioner conclusion is to treat SoD as evidence architecture as well as role design.

What this signals

Access-path concentration: the recurring SoD failure in modern identity programmes is not a missing policy statement, but a workflow that lets the same actor keep control across request, approval, execution, and review. IAM and IGA teams should treat that concentration as a design defect, not an edge case.

SoD is most fragile where organisations rely on approvals as evidence of control rather than on independently separated execution. That is why access governance needs audit trails that prove who decided, who acted, and who verified the action.

For NHI and human identity programmes alike, the lesson is the same: if the control owner can also authorise the control exception, the separation has collapsed. Governance must preserve distinct decision paths, not just distinct job titles.

For practitioners

• Define access-path separation Map every critical entitlement flow and identify where request, approval, fulfilment, and review are still owned by the same person or workflow.
• Split recovery authority Assign backup creation, restore testing, and production recovery to different roles so recovery cannot self-authorize.
• Separate vendor lifecycle ownership Keep vendor selection, contract approval, entitlement assignment, and vendor performance review under different accountable owners.
• Audit recurring SoD violations Review recurring access exceptions, override paths, and emergency grants to find where the same actor repeatedly crosses control boundaries.
• Document independent review evidence Retain logs, approvals, and reconciliation records that prove a second party validated the control step rather than merely observing it.

Key takeaways

• Separation of duties is now an identity governance issue as much as a finance control issue, because access and recovery workflows can collapse authority into one chain.
• The article’s examples show that the main risk is control concentration, where one actor can request, approve, execute, and review the same action.
• The practical fix is to preserve independent ownership, independent evidence, and independent verification across provisioning, recovery, and vendor governance.

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.
• Access Review: A formal process for confirming whether access is still needed and justified. In IAM programs, the review becomes an evidence-bearing control when decisions are recorded, scoped correctly, and traceable to the right reviewer, application owner, or auditor.
• Privileged Workflow: A privileged workflow is any access or administrative process that can change sensitive systems, accounts, or controls. Because these workflows can create audit and abuse risk quickly, they need independent approval, logging, and review, especially when one person could otherwise control multiple steps.
• Control Independence: The condition in which approval, execution, and review are owned by different actors or mechanisms. It is essential to SoD because independence is what makes the control testable, auditable, and resistant to fraud or self-justifying exceptions.

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.