They treat segregation of duties as a policy checkbox rather than an active control. SoD only works when the system detects conflicting access before it is granted or retained. If exceptions are hidden in spreadsheets or unmanaged approvals, the control loses its value.
Why This Matters for Security Teams
segregation of duties is supposed to prevent one identity from accumulating incompatible powers, yet workforce iam programs often reduce it to a one-time approval step. That misses the real risk: access can become toxic after onboarding, after a role change, or through inherited group membership. NIST’s NIST Cybersecurity Framework 2.0 treats access governance as an ongoing control outcome, not a paperwork exercise.
The same pattern appears in NHI programs. NHIMG research shows only 5.7% of organisations have full visibility into their service accounts, which is a warning sign for any identity estate where access drift is common. If teams cannot continuously see who can approve, deploy, pay, and override, SoD becomes easy to bypass through exceptions, stale entitlements, or informal “temporary” access that never expires. In practice, many security teams discover SoD failures only after audit findings or fraud indicators have already surfaced, rather than through preventive entitlement design.
How It Works in Practice
Effective SoD in workforce IAM requires the access engine to understand incompatible duties before access is granted and to re-evaluate that decision whenever roles, groups, or entitlements change. The control is strongest when it is embedded in joiner-mover-leaver workflows, access requests, and periodic recertification, rather than left to managers or spreadsheet-based exception tracking. Current guidance suggests that SoD should be enforced through policy and workflow integration, not manual memory.
Practically, teams should define toxic combinations such as requestor plus approver, developer plus production approver, or vendor onboarding plus payment authorization, then encode those conflicts into role design and request-time checks. That usually means:
- mapping duties to business processes, not just job titles;
- blocking conflicting access at provisioning time;
- requiring time-bound exceptions with explicit expiry and compensating controls;
- rechecking SoD when an employee changes teams, projects, or managers;
- tracking inherited entitlements from nested groups and shared administrative roles.
This is where automation matters. Identity governance platforms, PAM, and policy-as-code checks help, but only if they are connected to authoritative HR and ticketing data. If an exception lives outside the system of record, the control cannot be trusted. The NHI angle is relevant because the same governance gaps show up in secrets and service accounts: the 2024 Non-Human Identity Security Report found that 59.8% of organisations want dynamic ephemeral credentials, which reflects the broader shift away from standing privilege and toward time-bounded access.
These controls tend to break down in large enterprises with cross-functional matrix reporting because approval paths become ambiguous and local managers override global policy.
Common Variations and Edge Cases
Tighter SoD enforcement often increases workflow friction, requiring organisations to balance risk reduction against business continuity. That tradeoff is real, especially in finance, operations, and incident response where a single person may legitimately need broad access during a narrow window.
Best practice is evolving, and there is no universal standard for every exception pattern. Some environments use compensating controls such as dual approval, session recording, or JIT elevation through PAM; others use risk-based approval rules that weigh transaction value, data sensitivity, and recent behavior. The key is that exceptions should be deliberate, short-lived, and reviewable. If an emergency access path is permanent, it is not an exception anymore. If a control cannot explain why one person was allowed to both request and approve an action, it is too weak to satisfy audit or operational scrutiny.
This problem is more pronounced when organisations have multiple HR systems, outsourced process owners, or inherited access from mergers. In those cases, policy logic often misses real-world conflicts because the authoritative source of duty assignment is fragmented. Teams that understand this tend to pair SoD with least privilege, periodic access review, and strong offboarding discipline. Where they do not, hidden exceptions accumulate until the first investigation forces a full entitlement rebuild.
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 is an access control outcome tied to how permissions are granted and maintained. |
| OWASP Non-Human Identity Top 10 | NHI-03 | SoD failures mirror unmanaged standing access and weak lifecycle control for identities. |
| NIST AI RMF | AI RMF supports governance and accountability patterns for policy-driven access decisions. |
Eliminate standing access, time-bound exceptions, and stale entitlements across identity lifecycle events.
