Separation of duties matrices are still the core IAM control

At a glance

What this is: This is a guide to separation of duties matrices and how they structure role, access, approval, and monitoring controls for access governance.

Why it matters: It matters because SoD is still one of the clearest ways to limit privilege concentration across human, NHI, and AI-governed workflows.

👉 Read Zluri's guide to separation of duties matrix design for IGA teams

Context

Separation of duties, or SoD, is the practice of splitting critical tasks so one identity cannot initiate, approve, and complete a sensitive action on its own. In IAM terms, it is a governance control that reduces privilege concentration, limits fraud paths, and supports auditability across employee access and machine-adjacent workflows.

The problem is not the idea of SoD. The problem is that many programmes still express it as a static matrix while the underlying access model keeps changing through SaaS sprawl, delegated approvals, and incomplete review cycles. When access moves faster than governance, SoD becomes a policy statement instead of an operational control.

Key questions

Q: How should security teams implement separation of duties in SaaS environments?

A: Start by defining incompatible duties at the entitlement level, then map those duties to roles and approvers in your SaaS stack. Require that request, approval, and execution sit in different hands, and verify the result with recurring access certification and audit logs. If the same identity can still complete the full workflow, SoD is not enforced.

Q: Why do separation of duties controls fail in practice?

A: They fail when access stays broader than the current job need, when approvals are detached from live permissions, and when exceptions are not tracked. A matrix on paper does not prevent fraud or error if standing privilege lets one identity span conflicting tasks. Operational SoD depends on current-state enforcement, not just policy design.

Q: How do you know if a separation of duties matrix is actually working?

A: Check whether active permissions match current responsibilities, whether approvals are logged end to end, and whether conflicting actions can still be completed by one identity. If auditors cannot reconstruct the decision chain or if users retain overlapping access between reviews, the matrix is creating documentation, not control.

Q: What is the difference between SoD and least privilege?

A: Least privilege limits how much access an identity has, while SoD limits which conflicting duties that identity can combine. You need both. An account can be narrowly scoped and still violate SoD if it can request, approve, and execute the same sensitive action. Segregation is about incompatible power, not just small permissions.

Technical breakdown

Roles and responsibilities in SoD matrices

SoD matrices work by mapping identities to distinct duties so incompatible actions do not sit in the same hands. The control depends on precise role definition, clear responsibility scope, and cross-verification between actors. In practice, the matrix must reflect who can request, approve, process, and audit access or transactions, otherwise the separation is only documented, not enforced. Where organisations blur role boundaries, they create hidden control collisions that are hard to see in audits and easy to exploit in daily operations.

Practical implication: define incompatible duties at the entitlement level, not just in policy language.

Access levels, permissions, and least privilege

Access levels in SoD are the mechanism that turns separation into enforcement. Granular permissions let teams restrict who can reach specific systems, datasets, or functions, while least privilege keeps each identity close to its actual job need. If access rights are broad, inherited, or stale, the matrix loses value because one identity can still span multiple conflicting duties. In many environments, the real failure is not missing approval logic but excessive standing access that undermines the boundary SoD is supposed to hold.

Practical implication: recertify entitlements against actual duty boundaries and remove overlapping permissions quickly.

Audit trails and monitoring for SoD enforcement

Audit trails give SoD evidentiary strength by showing who did what, when, and in what sequence. Monitoring adds the operational layer by detecting anomalies, correlating actions, and surfacing exceptions before they become compliance failures. Without logging and review, organisations cannot prove that segregation existed at the time of the action, only that a matrix existed on paper. That distinction matters in investigations, regulatory review, and remediation planning.

Practical implication: log each approval, exception, and privilege change so segregation can be proven after the fact.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.

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 a lifecycle control, not a spreadsheet control. The article treats separation of duties as a role matrix, but its real value depends on joiner-mover-leaver discipline, access certification, and exception handling. Once entitlements drift or approvals become detached from current role scope, the matrix no longer separates duties in practice. Practitioners should treat SoD as a governed lifecycle process across human and non-human identities.

Standing privilege is the hidden SoD failure mode. A matrix can look sound while identities retain broad access between reviews. That is the control gap most teams underestimate: segregation breaks when permissions persist long after the task that justified them. The implication is that SoD cannot be evaluated only by policy design; it has to be measured against live access state.

Auditability is the difference between SoD intent and SoD evidence. This article correctly elevates logging, approvals, and reporting, because segregation only matters if an auditor can reconstruct the decision chain. In practice, teams need evidence that access requests, approvals, and revocations align to the same entitlement model. Practitioner conclusion: without traceable approval history, SoD becomes advisory rather than enforceable.

SoD now spans human and non-human operational identities. The same conflict patterns appear when service accounts, integrations, and automation platforms can both request and execute privileged actions. That is why SoD programmes that stop at employee roles miss an expanding attack surface. Practitioners should extend segregation logic to every identity that can participate in approval or execution paths.

Identity blast radius is the named concept this article points toward. SoD is ultimately about limiting how far a single identity can reach across request, approval, and execution. The narrower the blast radius, the less one compromise or one bad approval can do. Practitioners should use that lens when deciding which duties must never co-reside in the same access path.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, and a quarter encountered multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
• For broader lifecycle context, see NHI Lifecycle Management Guide for how provisioning, rotation, and offboarding affect segregation outcomes.

What this signals

Identity blast radius is the useful lens here: SoD is only durable when the same access path cannot be used to request, approve, and execute a sensitive action. In environments where 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security, the matrix is already operating against incomplete inventory.

The next governance step is not more policy text, but tighter linkage between approvals, entitlement state, and review evidence. Teams that cannot trace who approved what, and whether that approval still matches current access, will struggle to defend segregation in audit or incident review.

For practitioners, SoD is now part of the wider NHI and delegated-access problem, not just an internal finance control. That means lifecycle management, access certification, and visibility into external connected identities have to be treated as one programme, not separate workstreams.

For practitioners

• Map incompatible duties to live entitlements Translate SoD from policy language into entitlement-level controls so one identity cannot request, approve, and execute the same sensitive action. Tie the matrix to role definitions that are reviewed whenever job scope changes.
• Certify access against current role scope Run recurring reviews that compare active permissions with actual job responsibilities, then remove overlapping access before the next review cycle. This is the only way to keep standing privilege from eroding segregation boundaries.
• Separate approval paths from execution paths Ensure the identity that approves access or a transaction is not the same identity that can process it, and add exception handling for temporary overrides. Keep the approval chain visible in the audit trail.
• Extend SoD to SaaS and integration identities Apply the same segregation logic to service accounts, API-connected workflows, and delegated admin paths, not only to human users. Where a non-human identity can both request and perform privileged actions, the matrix is incomplete.

Key takeaways

• Separation of duties only works when incompatible actions are separated in live entitlement state, not just in a matrix document.
• Audit trails, approval chains, and access certification are what make SoD defensible in practice, especially where standing privilege still exists.
• As SaaS and delegated identities grow, SoD programmes must extend beyond human roles to cover every identity that can participate in request, approval, and execution.

Key terms

• Separation Of Duties: A governance control that divides sensitive work so one identity cannot perform conflicting steps in the same process. It is used to reduce fraud, errors, and unauthorized access. In practice, the control only holds when roles, approvals, and execution are enforced in live systems, not merely documented in policy.
• Access Certification: A periodic review process where access rights are checked against current responsibilities and business need. It is a core IGA control because stale permissions often survive long after the original need has ended. Effective certification produces evidence, not just acknowledgements, and should lead to timely revocation when access no longer fits the role.
• Standing Privilege: Persistent access that remains available outside the specific task or time window that justified it. This creates control drift because one identity can retain more authority than the current role requires. Standing privilege is especially risky in SoD programmes, where the boundary between incompatible duties must stay narrow and current.
• Identity Blast Radius: The maximum extent of damage a single identity can cause if it is misused or compromised. The concept applies to human, non-human, and autonomous identities alike, but the reduction strategy differs by actor type. In SoD programmes, reducing blast radius means preventing one identity from spanning request, approval, and execution.

Deepen your knowledge

SoD matrices, access certification, and lifecycle enforcement are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are turning segregation policy into an operational control model, it is worth exploring.

This post draws on content published by Zluri: Security & Compliance Segregation Of Duties Matrix Template. Read the original.