What breaks when segregation of duties is the only control in place?

SoD blocks some toxic combinations, but it does not clean up stale, unused, or orphaned access. Users can change roles, projects can end, and temporary access can become permanent without any SoD alert. A programme built only on prevention still accumulates governance debt over time.

Why This Matters for Security Teams

segregation of duties is useful, but it is only a preventive control. It blocks certain toxic combinations of access, yet it does nothing to continuously detect who still has access after a role change, project end, or temporary exception. That is why a SoD-only programme can look strong in policy and still accumulate hidden risk in service accounts, API keys, and other NHIs. The governance problem is not just “who should not do two things at once”, but “who still has standing access at all”.

Current guidance in NIST Cybersecurity Framework 2.0 and NHIMG’s lifecycle guidance both point toward continuous identity governance, not one-time prevention. NHI Mgmt Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer rotate them consistently. That gap matters because stale access is often invisible until it is exploited. The practical failure is that SoD can reduce insider misuse, but it cannot remove orphaned credentials or expired entitlements from circulation. In practice, many security teams discover this only after an audit, a breach, or a failed offboarding event has already exposed the gap.

How It Works in Practice

Operationally, SoD should be treated as one layer in a broader identity control stack. For NHIs, that stack needs lifecycle review, ownership, expiration, and revocation. A service account or agent should have a named owner, a clear purpose, and a defined expiry. When the purpose ends, access should be removed automatically. That is the control gap SoD does not close.

For this reason, practitioners typically pair SoD with PAM, RBAC, and periodic entitlement recertification. The goal is to stop incompatible access at request time and then keep standing access as small as possible. NHI Mgmt Group’s research shows that Ultimate Guide to NHIs — Standards is especially relevant here because it ties governance to visibility, rotation, offboarding, and Zero Trust. That matters in environments where secrets are embedded in code, CI/CD, or vaults with weak controls. In those settings, Ultimate Guide to NHIs — Standards aligns with the operational reality that excessive privileges and stale credentials travel together.

• Inventory every NHI, then assign an owner and business purpose.
• Set expiration dates for temporary access and revoke on task completion.
• Review SoD conflicts, but also recertify standing access on a schedule.
• Use NIST Cybersecurity Framework 2.0 to anchor access governance, detection, and recovery.
• Rotate secrets and remove orphaned entitlements as part of offboarding, not as an afterthought.

This guidance tends to break down in fast-moving cloud and CI/CD environments because ephemeral workloads, shared pipelines, and unmanaged secrets create access paths that SoD reviews never see in time.

Common Variations and Edge Cases

Tighter SoD often increases administrative overhead, so organisations have to balance control strength against operational speed. That tradeoff becomes sharper for short-lived cloud workloads, contractors, and automation accounts, where manual approvals can slow delivery if they are not paired with automation. Best practice is evolving, but current guidance suggests using SoD to prevent risky combinations and using time-bound identity controls to remove access when the task is over.

There is no universal standard for this yet, but the direction is consistent across NIST Cybersecurity Framework 2.0 and NHIMG lifecycle guidance: minimise standing privilege, automate revocation, and make ownership explicit. For highly autonomous systems, this becomes more urgent because access can be exercised faster than a human review cycle can respond. In those cases, the issue is not only privilege separation, but whether the identity should exist with persistent authority at all. That is why Ultimate Guide to NHIs — Standards emphasises rotation and offboarding rather than relying on policy alone. A SoD-only model can be acceptable for narrow compliance use cases, but it is weak wherever credentials are shared, long-lived, or attached to automation that outlives the original approval.

Related resources from NHI Mgmt Group

• What breaks when segregation of duties is missing from privileged access?
• What breaks when access reviews are used as the main risk control?
• What breaks when identity is treated as an administrative task instead of a control plane?
• What breaks when stale Snowflake service accounts are left in place?