SoD fails when conflicting access is granted in one workflow and removed in another, because the control depends on consistent lifecycle enforcement. If provisioning, role changes, exceptions, and offboarding are not tied together, identity entitlements can outlive the policy that should have constrained them.
Why SoD breaks when lifecycle controls do not stay in lockstep
segregation of duties depends on the whole access lifecycle behaving as one control plane. If a user can receive one half of a conflicting privilege in onboarding, keep it through a role change, or retain it after offboarding, the SoD rule is no longer enforcing the intended separation. The problem is not the rule itself, but the inconsistency between entitlement creation, modification, review, and removal.
That is why SoD failures often show up as process gaps rather than a single bad access grant. A role model may look sound on paper, but if exceptions are not time-bounded, movers inherit old access, or deprovisioning is delayed, the effective permission state drifts away from policy. The control only works when lifecycle events are synchronised and every entitlement path is governed by the same decision logic.
In practice, lifecycle inconsistency lets conflicting access accumulate in ways that are easy to miss during point-in-time reviews. A compensating approval in one workflow can be undermined by a separate automated feed that reissues access later, or by manual remediation that fixes one system but leaves another unchanged. That creates the classic SoD failure mode: policy says the duties are separated, while the operating state says otherwise.
Where inconsistent provisioning, movers, and offboarding create conflict
SoD failure is usually rooted in broken entitlement continuity across joiner, mover, and leaver events. If provisioning is not tied to role design, movers do not lose old access, and offboarding is incomplete, then toxic combinations persist longer than the control assumes. The result is privilege creep, orphaned entitlements, and exceptions that outlive the business justification that created them.
One useful way to think about the failure is that SoD is cumulative, not transactional. Each workflow should both add the right access and remove the wrong access. When one path grants access but no matched removal path exists, the control becomes additive only, which is exactly how conflicting duties survive in real environments. For a deeper lifecycle model, see the Joiner-Mover-Leaver (JML) Guide and the IAM and IGA Basics.
SoD also fails when exception handling is disconnected from entitlement governance. If a temporary override is granted for a business reason but no expiry, recertification, or removal control follows, that exception silently becomes permanent. The same issue appears when service accounts, bots, or other non-human actors are exempted from ordinary reviews, even though their access can still participate in conflicting workflows. The Segregation of Duties (SoD) Guide addresses those conflict patterns directly.
What practitioners should watch for when SoD starts drifting
When SoD is unstable, the most revealing signals are not the policy statements, they are the mismatches between authoritative sources and live entitlements. A role change that does not remove prior access, delayed offboarding, stale emergency access, and manual exceptions that bypass the standard lifecycle are all signs that the control is being applied inconsistently. That inconsistency matters because it changes the effective blast radius of a single identity.
The risk becomes especially acute when lifecycle failures involve credentials or tokens that remain valid after the business role has changed. In that case, the identity may still be able to exercise access that the SoD design intended to prevent. For examples of how lingering credentials and late revocation extend exposure, review the Joiner-Mover-Leaver (JML) Guide and the NHI Lifecycle Management Guide.
Another common drift pattern is control fragmentation. If one system enforces SoD at request time, another at approval time, and a third only during periodic review, the organisation may believe it has separation while the actual access state says otherwise. That is why lifecycle governance needs one consistent source of truth for grant, change, review, and removal decisions. Where lifecycle gaps leave credentials behind, the Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs shows how governance breaks when removal does not follow issuance.
Risk and Threat Considerations
Inconsistent lifecycle governance turns SoD from a preventive control into a delayed-detection control. The main exposure is that toxic access combinations can persist unnoticed long enough to enable fraud, unauthorised changes, or privilege escalation, especially when offboarding and exception expiry are not enforced with the same discipline as provisioning.
Failure mechanism: conflicting access is granted in one workflow, then retained or reintroduced through a different workflow that does not share the same removal logic, review cadence, or ownership.
Impact: the organisation can lose the practical separation between request, approval, execution, and review, so a single identity can accumulate enough authority to bypass the intended control.
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 NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-5 — Separation of Duties | SoD failures are directly about separation of duties control design. |
| AC-2 — Account Management | Lifecycle drift arises when provisioning, change, and offboarding are not governed consistently. | |
| IA-5 — Authenticator Management | Lingering credentials can preserve conflicted access after role change or offboarding. | |
| Recommendation — Enforce AC-5 so conflicting duties cannot coexist across workflows or exceptions. Use AC-2 to align account creation, modification, and removal with SoD rules. Apply IA-5 to rotate or revoke authenticators when lifecycle events change access risk. | ||
| NIST CSF 2.0 | PR.AA-05 — Managed Access Control | SoD depends on consistent access enforcement across the identity lifecycle. |
| GV.RM-04 — Risk Response Strategy | SoD exceptions need governed handling, expiry, and escalation when conflicts persist. | |
| Recommendation — Implement PR.AA-05 so access decisions stay aligned with lifecycle changes and exceptions. Set risk response rules for SoD exceptions, expiry, and escalation thresholds. | ||
Practitioner Guidance
What to prioritise: Treat lifecycle consistency as the control, not the individual access request. If you can grant, move, and remove access in different systems, you must verify that the same SoD rules and revocation logic are enforced across all three.
What to verify: Check whether exceptions expire, movers lose prior entitlements, and leavers are fully deprovisioned across every authoritative system. If any workflow can re-add access without rechecking conflicts, SoD is only partially enforced.
What good looks like: the current entitlement state matches policy after every lifecycle event, and any temporary override is visible, time-bounded, and independently reviewable rather than buried in a one-off approval trail.
Practitioner takeaway: SoD fails when governance is event-based instead of lifecycle-based, so the real test is whether every entitlement change is followed by the corresponding removal, review, or expiry action.