What is the difference between separation of duties and role based access control?

How SoD and RBAC differ in practice

Separation of duties is a control objective: it says critical tasks should be split so no single actor can initiate, approve, and complete the same sensitive process. RBAC is an access model: it assigns permissions by role. They often work together, but they are not the same thing. SoD defines the governance requirement, while RBAC is one way to express and enforce parts of that requirement.

The difference matters because a role model can be structurally correct and still fail SoD if one role bundles conflicting powers. For example, a user can have neat role assignments and still be able to create a vendor, approve a payment, and reconcile the transaction. SoD is about the workflow conflict; RBAC is about how permissions are grouped and distributed.

For a useful mental model, treat SoD as a policy question and RBAC as an implementation question. SoD asks what combinations of duties must never sit with one person or one identity. RBAC asks which permissions belong to each job role, and how those permissions are assigned, reviewed, and revoked. That is why IAM and IGA Basics is useful background when you want to see how governance principles and access models fit together.

Why RBAC helps, but does not solve SoD by itself

RBAC works well when duties map cleanly to job functions, especially for standard access patterns and repeatable business processes. It reduces ad hoc permissioning and makes access easier to review. But RBAC alone does not guarantee conflict-free design, because roles can be too broad, inherited from legacy practice, or layered in ways that recreate the same toxic combination.

SoD usually needs an additional design layer: conflicting role combinations, dual approval rules, compensating controls, or transaction-level checks. A role can grant a person the ability to prepare a change, but a separate control should stop that same person from approving or deploying it. Core Security Principles Guide is relevant here because SoD is one of the classic design principles that sits above any single access model.

In practice, this means RBAC should be reviewed through an SoD lens, not treated as a complete answer. If your access model can express roles but cannot detect when those roles create a conflict, you have implemented authorization structure without governance assurance. Segregation of Duties (SoD) Guide is the better reference when the question is how to define conflicts, mitigations, and exception handling across people, bots, and AI agents.

Where teams get the boundary wrong

The most common mistake is to assume that a clean role catalogue automatically produces SoD compliance. It does not. Role design can hide overlap, especially when access is inherited across applications, emergency access is not reviewed, or a single privileged role accumulates multiple responsibilities over time.

Another common error is to treat SoD as a one-time design exercise instead of a continuous review problem. Roles change, processes change, and exceptions tend to persist longer than intended. If you only look at initial provisioning, you miss the later drift that turns a well-designed model into an unsafe one. Authorisation Models Guide helps here because it shows why role logic is only one part of the wider authorization design space.

RBAC is strongest when the job structure is stable and the permission set is predictable. SoD becomes more important when the process is sensitive, the business impact of error or fraud is high, or approvals must remain independently challengeable. Where those conditions exist, the access model should be tested against the process, not the other way around.

Risk and Threat Considerations

SoD failures create concentration of power: one identity can make, approve, and conceal a risky action. That increases fraud risk, change abuse risk, and the chance that mistakes are not caught by a second set of eyes. RBAC can also amplify the problem if broad roles are used to simplify administration without checking for conflicting duties.

Failure mechanism: Conflicting permissions are bundled into one role, or multiple roles combine to recreate a toxic path, so the same person can execute a sensitive workflow end to end without independent review.

Impact: The organisation loses control over approval integrity, non-repudiation, and fraud resistance, and downstream reviews may only discover the conflict after damage has occurred.

Practitioner Guidance

What to verify: Check whether your role catalogue is reviewed for conflicts at the process level, not just for permission hygiene. A role can be least privilege in isolation and still violate SoD when paired with another role or an emergency entitlement.

Decision rule: If the control objective is “no single actor can complete the full sensitive process,” do not rely on RBAC alone. Add conflict rules, independent approvals, or compensating workflow checks where the business process demands them.

Common mistake: Teams often tune RBAC to reduce ticket volume and then assume SoD is covered. That usually shifts the problem into the exception process, where conflicts become harder to see and harder to evidence.

Practitioner takeaway: Use RBAC to distribute permissions, but use SoD to prove that no one can abuse the process boundary; if the two are not tested together, the control is incomplete.

Related resources from NHI Mgmt Group

• Role-Based Access Control
• Role-Based Access
• What happens when role-based access control is applied without separation of duties?
• How should security teams implement role-based access control in environments where job duties overlap across departments?