They often assume that separated roles mean independent behaviour. In reality, employees can share credentials, coordinate approvals, or work around process boundaries, which defeats the control even if the matrix looks correct. Teams need behavioural monitoring and exception review, not just role design, to detect when independence has collapsed.
Why This Matters for Security Teams
Separation of duties only reduces risk when the separated actions remain genuinely independent. Security teams often design SoD as a static approval matrix, then assume the control holds even when employees coordinate outside the workflow, reuse access, or trade favours in practice. That gap turns a governance model into a paperwork exercise. NHI Management Group’s research on broader identity risk shows how often controls fail when visibility is weak and behavior is not monitored, which is why NHI and human identity issues can look different on charts but fail in similar ways.
The problem is not just fraud. Collusion can bypass approval logic, hide privilege escalation, and make exception paths look routine. That creates a false sense of assurance in audits and in day-to-day operations, especially where business pressure rewards speed over independence. Current guidance in NIST Cybersecurity Framework 2.0 supports ongoing oversight, not one-time policy design, and the same principle applies here. In practice, many security teams discover collusion only after an exception becomes a pattern and the control has already lost its independence.
How It Works in Practice
Effective SoD design starts by mapping which actions must never be controlled by the same person or the same informal network of people. That means reviewing not just role titles, but actual workflow paths, shared mailbox access, delegated approvals, break-glass processes, and the informal handoffs that happen outside ticketing systems. The goal is to detect when two separated duties become functionally merged through collusion or convenience.
Practitioners should treat SoD as a monitored control, not a static entitlement model. That usually means:
- Logging approvals, overrides, and exception grants with enough context to identify repeated pairing of the same actors.
- Reviewing whether the same user benefits from multiple sides of the control, even if the actions are technically separated.
- Checking for shared credentials, delegated inboxes, proxy approvals, or unreviewed admin access that collapses independence.
- Using periodic exception review to distinguish legitimate business continuity from habitual control bypass.
This is where identity research becomes useful. The Top 10 NHI Issues and the Ultimate Guide to NHIs both underscore a broader lesson: access controls fail fastest when teams trust the diagram more than the actual operating behavior. For human SoD, the same logic applies. Monitoring should focus on behavior drift, repeated exception patterns, and evidence that the two halves of the control are no longer independent. These controls tend to break down in high-volume finance, procurement, and release-management environments because pressure to keep work moving normalizes workarounds faster than reviewers can spot them.
Common Variations and Edge Cases
Tighter SoD often increases operational friction, requiring organisations to balance fraud resistance against cycle time, staffing constraints, and business continuity. That tradeoff becomes sharper in small teams, where the same people wear multiple hats and strict role separation can be impractical without compensating controls.
There is no universal standard for this yet, but current guidance suggests treating some exceptions as temporary and high-risk rather than permanently approved. For example, emergency access, weekend support, and merger integrations often create valid reasons for overlapping duties. The key is to time-box those exceptions, review them after the fact, and revoke access when the exception ends. If the same exception keeps recurring, it is no longer an exception and should be redesigned.
The strongest programs combine policy, monitoring, and accountability. The NIST framework emphasizes continuous improvement, and the same approach fits SoD collusion risk: review who approves exceptions, who benefits from them, and whether the control still works outside the org chart. As The State of Non-Human Identity Security notes, weak monitoring and over-privilege are common failure drivers across identity programs, which is exactly why collusion detection should not be limited to annual audit checks.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | SoD collusion is an access enforcement and oversight problem. |
| OWASP Non-Human Identity Top 10 | NHI-05 | Collusive access patterns mirror privilege misuse and weak oversight. |
| NIST AI RMF | GOVERN | SoD collusion needs accountable oversight, not just policy design. |
Detect repeated exception paths and privilege concentration before control separation collapses.
