Segregation of duties checks fail when a user, role, or service account accumulates conflicting permissions across roles, groups, or application entitlements. Common causes include role creep, poorly designed inheritance, emergency access left in place, and incomplete identity data. Review effective access, map toxic combinations, and reconcile joiner-mover-leaver changes so conflicting privileges are removed promptly.
What makes SoD checks break down in practice?
segregation of duties checks are only as accurate as the entitlement model behind them. They fail when access is spread across roles, groups, inherited permissions, and direct grants that the rule engine does not fully reconcile. That means the control may look healthy on paper while the effective permissions still allow a single user or service account to complete conflicting steps.
SoD failures also emerge when organisations treat role design as a one-time project instead of a living governance problem. If joiner-mover-leaver events are not reflected quickly, or if emergency access is not removed after use, the check is working against stale identity data rather than current reality.
Why role creep and inheritance are such common failure modes
Role creep is one of the most common reasons SoD checks lose value. As users change jobs, get temporary exceptions, or inherit access through nested groups, the organisation accumulates combinations that were never intended in the original role model. The check then has to detect conflict across a messy access graph, not a clean entitlement set.
Inheritance creates a similar problem because the conflict may not sit in any one obvious assignment. A user can appear compliant at the top level while the underlying group, application entitlement, or delegated permission introduces the toxic combination. Effective SoD analysis therefore has to flatten the access path, not just inspect named roles.
What good SoD analysis has to verify before it can be trusted
Reliable SoD checking starts with current effective access, not declared access. The control should evaluate direct grants, inherited rights, exception paths, break-glass access, and any service or shared account that can act on behalf of a person or process. If any of those paths are missing, the result is a partial answer rather than a control decision.
It also has to map the conflicting action pair, not just the label on the role. In practice, the relevant question is whether one principal can originate, approve, reconcile, or release a transaction that should be independently checked. Where the model cannot express that conflict clearly, the control becomes too blunt to support audit or remediation.
Risk and Threat Considerations
SoD failures matter because they create hidden paths for fraud, self-approval, and unauthorized change. When conflicting privileges are spread across roles or identities, a weak control can let one actor create, approve, and conceal a transaction without triggering the intended oversight.
Failure mechanism: The entitlement source of truth is incomplete, stale, or unable to flatten inherited and direct permissions into the same effective-access view, so the conflict is never detected or is detected too late.
Impact: Organisations may miss toxic combinations until after a financial, operational, or compliance event, and remediation becomes harder because the access path is distributed across multiple control layers.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | SoD failures often reflect excessive or conflicting privilege accumulation. |
| AC-5 — Separation of Duties | The subject is directly about SoD control design and conflict prevention. | |
| AC-2 — Account Management | Joiner-mover-leaver drift and stale accounts commonly cause SoD failures. | |
| Recommendation — Limit conflicting permissions to the minimum needed for each role and exception. Define and enforce duties that prevent one actor from completing conflicting actions. Review and update account access promptly when roles or responsibilities change. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | SoD depends on managing entitlements, exceptions, and privileged access consistently. |
| Recommendation — Maintain authoritative access reviews and remove conflicting access promptly. | ||
| ISO/IEC 27001:2022 | A.5.3 — Segregation of Duties | This control directly addresses SoD governance and conflict separation. |
| Recommendation — Assign duties so one person cannot authorise and execute conflicting actions alone. | ||
Practitioner Guidance
What to verify: Validate the control against effective access data, not role names alone. If your tooling cannot show how a user, service account, or delegated session acquires each permission, treat the result as incomplete rather than compliant.
Decision rule: If a conflict depends on temporary elevation, emergency access, or inherited permissions, require explicit expiry and recertification before closing the SoD exception. If the access path cannot be time-bounded, it should be treated as standing privilege.
What practitioners underestimate: The hardest failures are usually data-quality failures, not logic failures. A well-written SoD rule will still miss conflicts when identity records are incomplete, role ownership is unclear, or the joiner-mover-leaver process lags behind real access changes.
Practitioner takeaway: SoD is strongest when it is checked against live, flattened, and owned access data, because the control fails most often at the seams between roles, inheritance, exceptions, and lifecycle governance.
Related resources from NHI Mgmt Group
- Guide: Segregation of Duties (SoD) Guide
- Why do segregation of duties controls fail in cloud and SaaS environments?
- Why do segregation of duties controls fail after mergers or reorganisations?
- How do access reviews and segregation of duties fail when teams treat SSO as the access record?
- What breaks when segregation of duties checks are handled outside the provisioning workflow?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org