Segregation of duties conflicts: where identity controls break down

At a glance

What this is: This is an analysis of segregation of duties conflicts and toxic combinations, showing that access often becomes risky only when individually valid permissions accumulate across workflows.

Why it matters: It matters because IAM, IGA, PAM, and business application teams all need to spot and stop overlapping access before users can complete sensitive transactions without oversight.

👉 Read SecurEnds' analysis of segregation of duties conflicts and toxic combinations

Context

Segregation of duties conflicts are a governance problem, not just an access management problem. The core issue is that a role can look acceptable on its own while becoming risky when combined with another permission in the same process. In identity programmes, that is where toxic combinations appear and where controls that operate one permission at a time lose sight of the full transaction path.

For IAM, IGA, PAM, and business application owners, the practical challenge is keeping conflict rules aligned to real workflows as they change. The article’s examples point to finance, HR, provisioning, and privileged access, which are exactly the places where access overlap can turn a routine change into an audit finding or a fraud path.

Key questions

Q: What breaks when SoD conflicts are not in place?

A: When segregation of duties is not enforced, one identity can complete a sensitive process from start to finish without independent review. That removes a core control boundary and increases the chance of fraud, error, and audit failure. The practical fix is to separate action, approval, and finalisation across different roles.

Q: Why do temporary access and role changes create SoD risk?

A: Temporary access and role changes are where overlap accumulates. A permission added for convenience or emergency use often survives long after the need ends, and the same user can end up holding conflicting rights across systems. That is why lifecycle discipline matters as much as the SoD rule itself.

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

A: SoD controls are working when conflict pairs are blocked during request and provisioning, and when certification reviews surface few surprises. If toxic combinations keep appearing in HR, finance, IAM, or privileged systems, the control is either stale, incomplete, or not enforced in the workflow.

Q: Who is accountable when a toxic combination leads to fraud or audit findings?

A: Accountability usually spans identity governance, application ownership, and the business process owner. The identity team defines and enforces the conflict rule, the application owner aligns access with the workflow, and the process owner decides whether a compensating control is acceptable until the overlap is removed.

Technical breakdown

How toxic combinations form in segmented workflows

A toxic combination is not a single privilege. It is the pairing of two or more permissions that removes a control boundary, such as create and approve, request and approve, or create and elevate. In practice, the risk appears when a workflow spans multiple steps but the identity model treats each step separately. The result is a user who can move an action from initiation to completion without a second set of eyes. This is why SoD is a governance pattern, not a role naming exercise.

Practical implication: Map permissions to full business processes, not isolated entitlements, and block combinations that collapse approval boundaries.

Why access creep turns SoD into a control failure

Most SoD issues emerge gradually. A role change adds access, a temporary approval stays in place, and an exception is never revoked. Over time, the identity accumulates permissions across functions that were never meant to coexist. The system still looks orderly because each access grant was valid when issued. The failure is the lack of lifecycle discipline across changes, exceptions, and removals. That is why access reviews and provisioning rules must work together instead of acting as separate after-the-fact checks.

Practical implication: Tie SoD checks to joiner-mover-leaver events so conflicting access cannot survive role changes and temporary exceptions.

How detection works when controls must see the whole path

SoD detection depends on evaluating combinations across systems, not just reviewing one application at a time. A useful conflict matrix defines which role pairs or action pairs are incompatible, then continuously compares current access against that baseline. High-risk platforms like ERP, HR, IAM, and privileged access systems deserve first attention because conflicts there create direct financial, administrative, or audit impact. Automated monitoring scales the review, but the rule set still has to reflect the actual business process, or the tool will only automate blind spots.

Practical implication: Build a living SoD conflict matrix and enforce it in provisioning and certification workflows for the highest-risk systems first.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Toxic combinations are a process design failure, not an entitlement naming problem. The article shows that a permission can be valid in isolation and still become unsafe when paired with another step in the same workflow. That is a governance failure because the control boundary sits in the process, not the individual access grant. Practitioners should treat SoD as transaction design, not just role hygiene.

Access growth outrunning control enforcement is the real SoD failure mode. Temporary access, role changes, and manual provisioning create the overlap window that toxic combinations exploit. The issue is not that policies are missing, but that they are not enforced fast enough as access changes. Under NIST Cybersecurity Framework 2.0, this sits squarely in protect and detect discipline, and it is where certification cadence must match operational change.

SoD matrices are only useful when they reflect current workflows. A stale conflict list gives teams false confidence because it codifies yesterday’s process. The practical lesson is that governance artefacts must be maintained at the same pace as systems, org charts, and approvals. Otherwise, the matrix becomes documentation, not control.

Least privilege reduces SoD exposure only when it is paired with lifecycle controls. The article correctly points to over-permissioned roles, but the deeper lesson is that privilege boundaries degrade when movers keep old access or exceptions are left open. The relevant NHI lesson is that access scope must be continuously recalculated, not assumed stable after provisioning. That is the line between a controlled role and a toxic combination waiting to happen.

Compensating controls are a temporary exception, not a substitute for separation. Extra approvals, monitoring, and logs can reduce exposure when a clean split is not immediately possible, but they do not restore the lost governance boundary. Teams should treat them as short-term containment while the underlying role design is corrected. The control goal remains separation of duty, not just better observation of the violation.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, which shows how slowly governance gaps can persist once they exist.
• That pattern makes Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs the next useful read for teams fixing access overlap and lifecycle drift.

What this signals

SoD governance will only improve when identity teams treat conflict detection as a live control, not a periodic audit task. The article’s patterns map cleanly to broader identity lifecycle failures, where access changes outrun review cycles and toxic combinations survive long enough to matter. With 96% of organisations storing secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, the same operational drift that affects secrets also affects entitlement governance.

Identity programmes should expect SoD risk to concentrate where business processes are fastest and least manual. Finance, HR, and privileged access are not just high-value systems, they are the places where approval shortcuts accumulate first. The implication for practitioners is to combine workflow enforcement, certification discipline, and role cleanup instead of relying on one control to absorb all the risk.

For practitioners

• Build a living SoD conflict matrix Define incompatible action pairs for finance, HR, IAM, and privileged workflows, then update the matrix whenever processes or approvals change. Anchor the rules to real business transactions so the matrix catches create-and-approve, request-and-approve, and create-and-elevate combinations as they happen.
• Wire SoD checks into provisioning and certification Apply conflict checks during request approval, role assignment, and access recertification so toxic combinations are blocked before they are active. This works best when the same rules are enforced in both the workflow and the review cycle.
• Prioritise high-risk systems first Start with ERP, HR, IAM, and privileged access platforms because they carry the highest impact when separation fails. Use these systems to prove the control model before expanding into lower-risk applications.
• Remove stale access after role changes Treat movers and temporary exceptions as SoD risk events until conflicting permissions are removed or revalidated. If a user changes jobs or gains emergency access, review whether any old permissions now create a toxic combination.
• Use compensating controls only as a bridge When separation cannot be implemented immediately, add extra approvals, activity monitoring, and audit logging, then set a deadline to eliminate the overlap. Compensating controls should reduce exposure, not become the permanent operating model.

Key takeaways

• Segregation of duties breaks down when individually valid permissions combine into a single uncontrolled workflow.
• The scale of the problem comes from access changes, exceptions, and manual provisioning outpacing governance enforcement.
• Teams need living conflict rules, workflow enforcement, and cleanup discipline to keep toxic combinations from returning.

Key terms

• Segregation Of Duties: Segregation of duties is the practice of splitting sensitive steps so one identity cannot complete a critical process alone. It reduces the chance of fraud, error, and hidden control bypass by requiring independent action, approval, or validation across a workflow.
• Toxic Combination: A toxic combination is a pair or group of permissions that becomes risky when held together, even if each permission is acceptable on its own. In identity governance, the danger appears when overlap removes a checkpoint between initiation and approval.
• Conflict Matrix: A conflict matrix is a working list of permissions or roles that must not coexist within the same identity. It is used by IAM and IGA teams to detect and block risky combinations during provisioning, recertification, and access change events.
• Compensating Control: A compensating control is a temporary safeguard used when a clean separation of duties is not immediately possible. It may include extra approvals, monitoring, or audit logging, but it does not remove the underlying conflict and should not become permanent.

Deepen your knowledge

Segregation of duties conflicts and toxic combination control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is already dealing with role overlap, temporary access, or certification drift, it is worth exploring.

This post draws on content published by SecurEnds: segregation of duties conflicts and toxic combinations. Read the original.