Separation of duties in 2026: what IAM teams should watch

At a glance

What this is: This guide argues that separation of duties is a practical identity and operational control, not just a finance policy.

Why it matters: It matters because IAM, IGA, and PAM teams increasingly need SoD enforced across human access, service accounts, and delegated workflows, not only in audit controls.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.

👉 Read Zluri's guide to separation of duties policy examples for 2026

Context

Separation of duties is the idea that no single person or process should control an entire sensitive workflow from start to finish. In identity terms, that means access creation, approval, review, and revocation should not collapse into one administrative path, especially when the same workflow touches human users, service accounts, and delegated SaaS administration.

Zluri’s guide frames SoD as a compliance and risk control that applies across access management, backup and recovery, vendor management, network administration, and employee lifecycle events. That broader scope matters because modern identity programmes are no longer only about logins and roles. They are about preventing concentrated control wherever access can be granted, reused, or silently retained.

Key questions

Q: How should security teams implement separation of duties in access workflows?

A: Start by splitting request, approval, provisioning, and review into different roles or systems. Then remove self-approval paths, shared admin bypasses, and exception handling that lets one person complete the workflow alone. The control only works when the separation is enforced in process and technology, not just described in policy.

Q: Why do access reviews fail when separation of duties is weak?

A: Access reviews fail when the same team or person can both grant access and certify that access later. In that model, the review becomes a confirmation exercise rather than an independent challenge. SoD gives the review function its credibility by keeping approval and verification separate.

Q: What breaks when employee role changes are not tied to separation of duties?

A: Old access often remains in place while new permissions are added, which creates overlapping privileges and hidden conflicts. That overlap defeats the purpose of SoD because the user now carries both the old and new duties at once. Movers are one of the clearest places to look for SoD drift.

Q: Who should be accountable when a SoD violation is found?

A: Accountability should sit with both the control owner and the approver chain that allowed the conflict to persist. In practice, the business owner of the workflow, IAM governance, and the system owner all need a defined remediation path. SoD failures are usually process failures, not single-person mistakes.

Technical breakdown

How separation of duties works inside access workflows

SoD works by splitting a sensitive identity workflow into distinct functions such as request, approval, provisioning, review, and revocation. In access governance, that means the person who requests access should not be the same person who approves it, and the person who grants access should not be the only one who later certifies it. This creates independent checks that reduce fraud, error, and privilege accumulation. The control is stronger when the workflow is enforced in the system rather than relying on policy documents alone.

Practical implication: map each access workflow to separate approver, fulfiller, and reviewer roles and remove self-approval paths.

Why SoD fails when lifecycle events stay in one admin path

SoD breaks down when joiner-mover-leaver actions, role changes, or offboarding are handled by a single team without independent review. If one operator can provision access, retain exceptions, and skip revocation, the control becomes cosmetic. The same pattern appears in backup, vendor, and asset management when the same operator can initiate, approve, and verify the outcome. Lifecycle discipline only works when identity changes are auditable and separable from execution authority.

Practical implication: separate provisioning from recertification and offboarding, then require independent evidence that removals actually occurred.

SoD, RBAC, and access review are related but not interchangeable

RBAC assigns permissions through roles, but it does not by itself enforce separation between conflicting duties. SoD is the higher-order control that says a role model must not allow one identity to hold incompatible powers in the same process. Access review then tests whether those conflicts have crept back in through exceptions, inherited permissions, or role drift. In practice, the strongest programmes treat RBAC as a distribution mechanism, SoD as a constraint, and review as the verification layer.

Practical implication: test role design against SoD conflicts before recertification campaigns expose the problem late.

Threat narrative

Attacker objective: The attacker or insider aims to complete a sensitive business process end to end without independent challenge, creating fraud opportunity or unauthorized access.

1. Entry occurs when one identity or admin path is allowed to initiate a sensitive process without a second independent control.
2. Escalation follows when the same operator can approve, execute, and reconcile the workflow, turning a control into a single-point-of-failure.
3. Impact is fraud, error, or unauthorized access persistence because no separate reviewer exists to catch the conflict before completion.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

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 an identity control before it is a finance control. The guide correctly treats separation of duties as a mechanism for preventing one actor from holding initiation, approval, execution, and review power at the same time. That makes it relevant to IAM, IGA, and PAM teams as much as to auditors. In a modern programme, SoD should be read as a design constraint on privileged workflows, not a checklist item for compliance reporting.

Access review without SoD enforcement only documents concentration of power. If the same workflow can create access and later certify that access, review becomes retrospective paperwork rather than a control. This is where role design, approval routing, and offboarding discipline must be treated as one system. The practitioner conclusion is simple: independent verification must be structurally separate from access granting, or the review cycle will keep rediscovering the same exception.

Lifecycle governance is where SoD either becomes real or remains theoretical. The article’s access provisioning and mover scenarios show that role changes are where conflicting duties often appear first. If movers retain old permissions while new access is granted, the organisation quietly defeats its own control model. The field implication is that lifecycle management, not policy language, determines whether SoD reduces risk in practice.

Mixed control environments need SoD across people, applications, and delegated administration. The useful question is not whether a business function has SoD in principle, but whether the control survives when access is split across IT, app owners, managers, and automated workflows. That is where identity governance becomes operational discipline. Practitioners should test every high-risk workflow for hidden end-to-end ownership.

Identity conflict density: the real risk is not how many roles exist, but how many incompatible powers one identity can accumulate across them. This guide points to the common failure mode: roles are separated on paper, then recombined through exceptions, shared admin paths, or weak reviews. Once that happens, the SoD model is technically present but operationally absent. Practitioners should measure conflict density, not just policy existence.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how quickly governance breaks when review and ownership are incomplete.
• If you are mapping SoD into machine identity controls, start with the NHI Lifecycle Management Guide and the Ultimate Guide to NHIs.

What this signals

Identity governance teams should treat SoD as a control architecture issue, not a policy drafting exercise. The practical test is whether approval, fulfilment, and certification are separated in the systems that actually run the business. When they are not, the programme accumulates exceptions that eventually behave like standing privilege.

Conflict review will matter more as SaaS administration becomes more distributed. Shared admin panels, delegated app ownership, and workflow automation make it easy for one person to accumulate incompatible powers without noticing. Teams that want durable SoD need controls that detect overlaps early and route them into remediation rather than exception sprawl.

For practitioners

• Define conflicting duties per workflow List which identities can request, approve, provision, and review each sensitive access path, then remove combinations that let one actor complete the workflow alone.
• Separate provisioning from certification Ensure the team that grants access is not the only team that recertifies it, and require evidence that exceptions are independently validated before renewal.
• Break mover access inheritance When employees change roles, revoke obsolete access before adding new permissions so old entitlements do not silently bypass the SoD model.
• Test shared admin paths for control collapse Review SaaS, backup, vendor, and infrastructure admin routes for places where one operator can initiate, approve, and verify the same action without oversight.

Key takeaways

• Separation of duties is an identity governance control that prevents one actor from owning a sensitive workflow end to end.
• The biggest failure mode is not the policy text but the collapse of approval, execution, and review into one admin path.
• Practitioners should design SoD around lifecycle events, access reviews, and delegated administration, where role conflicts most often reappear.

Key terms

• Separation of Duties: A control design that prevents one identity from owning every step of a sensitive process. In identity governance, SoD separates request, approval, execution, and review so errors, fraud, and privilege misuse are harder to hide.
• Access Review: A periodic check to confirm that permissions still match the role and need of an identity. In practice, access review only works when the reviewer is independent from the person or team that granted the access being reviewed.
• Role Conflict: A situation where one identity is assigned duties that should remain separate, such as approving and executing the same transaction. Role conflicts are a core SoD failure because they create hidden paths for misuse, error, and audit gaps.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: Security & Compliance Top 7 Separation of Duties Policy Examples for 2026. Read the original.