What is the difference between segregation of duties and toxic combinations?

How segregation of duties and toxic combinations differ

segregation of duties is the policy design rule: split incompatible responsibilities so no single person or process can complete a sensitive action end to end. Toxic combinations are the resulting access states that break that rule, such as the same user being able to both create and approve a payment. The distinction matters because one is preventive design, the other is evidence of exposed control coverage.

The first concept belongs to control design and governance. It is a rule for how access should be structured, usually across roles, entitlements, workflows, and approvals. The second concept belongs to effective state. It describes what the access model actually permits right now, which is why toxic combinations are typically discovered in role mining, access reviews, entitlement analysis, or audit testing.

A useful way to think about it is that segregation of duties answers, “Which responsibilities must be separated?” while toxic combinations answer, “Where has separation failed in the real access graph?” In practice, the control principle is broader than any single workflow, while the toxic combination is specific and testable. A person can have a toxic combination even if the organisation has a written SoD policy, because policy does not equal enforcement.

What makes a toxic combination operationally different

Toxic combinations are usually defined relative to a business process, not just a role name. The conflict may involve creating and approving purchases, entering and releasing payments, developing and deploying code, or requesting and certifying access. That is why the same entitlement can be harmless in one context and toxic in another, depending on what downstream authority it unlocks.

This is where access governance has to go beyond static job titles. A role may look acceptable on paper but still create a conflict when combined with another entitlement, a privileged workflow path, or emergency access. NHI and machine-account patterns can also surface here, because automated accounts sometimes accumulate broad permissions that make a conflict invisible until the workflow is mapped end to end. See IAM and IGA Basics for the broader access-governance context.

Toxic combinations also differ from ordinary overprovisioning. Overprovisioning means a user has more access than they need. A toxic combination means the access set creates an incompatible duty separation failure, which can enable fraud, unauthorized approval, or concealment of errors. That is why the control question is not only “is access too broad?” but “does this access pair create an unbroken path from request to approval, creation to release, or change to validation?”

Why this distinction matters in reviews and remediation

SoD is the policy and architecture target; toxic combinations are the findings you remediate. If you treat them as the same thing, teams often stop at writing rules and never verify whether the rules are actually enforced in roles, applications, and exceptions. The better practice is to define the incompatible activities first, then test real entitlements, delegated access, and exception paths against those conflicts.

That distinction also changes remediation choices. A pure SoD issue may call for redesigning a role model, approval flow, or control ownership. A toxic combination may require removing an entitlement, adding compensating controls, splitting a role, or documenting a time-bound exception with monitoring. For a control perspective on separating duties in access design, Segregation of Duties (SoD) Guide is the most directly aligned internal reference.

It also helps to anchor the issue in access-control mechanics. Conflicts are often created by role aggregation, inherited entitlements, emergency access, or cross-environment permissions that were added for convenience and never removed. In larger environments, the same toxic combination can exist in several forms, so reviewers should test both direct entitlements and indirect paths created by groups, nested roles, or privileged workflows. For standards-based control mapping, NIST SP 800-53 Rev 5 Security and Privacy Controls covers the access-control and review disciplines that support this kind of analysis.

Practitioner Guidance

What to prioritise: Define the incompatible business actions first, then map them to actual entitlements, not just role names. The most reliable SoD programs start from process risk, then test whether a user or machine can traverse the whole sensitive workflow without a second approval.

What to verify: Confirm that your access review process tests effective access, inherited access, and exception access together. A clean role design is not enough if application-specific permissions, service accounts, or temporary elevation recreate the same conflict elsewhere.

Common mistake: Treating a toxic combination as a one-time audit issue. In practice, it is a control-state problem that can reappear whenever roles change, approvals are added, or access is inherited from parent groups or shared automation.

Practitioner takeaway: SoD is the rule you design, toxic combinations are the breach of that rule you must detect and remove; mature governance measures both the intended separation and the real access state.

Related resources from NHI Mgmt Group

• What is the difference between attack surface management and NHI governance?
• What is the difference between reviewing human access and reviewing NHIs?
• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between human IAM controls and NHI governance?