What breaks when access review workflows do not account for separation of duties violations?

Why This Matters for Security Teams

access review workflows are supposed to catch toxic combinations before they become operational risk. When they do not account for separation of duties, the review can still look complete while approving identities that can request, approve, and execute the same sensitive process. That breaks the control intent behind least privilege, weakens evidence for auditors, and creates a false sense of coverage.

This matters just as much for NHIs as for people. Service accounts, API keys, and agentic workloads often accumulate broad permissions over time, and the problem is amplified when reviewers focus on whether an identity exists rather than whether its entitlements conflict. NHI Mgmt Group notes that Ultimate Guide to NHIs shows 97% of NHIs carry excessive privileges, which makes SoD blind spots far more dangerous in practice. Current guidance from OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls both point toward entitlement review as a control, but they are only effective when conflicting duties are checked explicitly. In practice, many security teams encounter SoD failures only after an exception has already been approved and used in production.

How It Works in Practice

A useful access review process should evaluate more than ownership, activity, and last use. It should compare each identity against a separation of duties rule set that defines incompatible capabilities, such as create versus approve, submit versus reconcile, deploy versus attest, or administer versus audit. For NHIs, this often means mapping machine identities to business process roles and to the systems they can chain together.

In mature programs, reviewers do not manually infer conflicts from raw entitlements alone. They use policy logic to flag toxic combinations at review time, then require one of three outcomes: remove access, split duties across identities, or document a time-bound exception with compensating controls. That approach aligns with the direction of the Ultimate Guide to NHIs — Key Challenges and Risks, which highlights visibility and governance gaps as core drivers of NHI exposure.

• Define SoD rules in terms of real workflows, not generic role names.
• Evaluate both human and non-human identities against the same conflict matrix.
• Flag identities that can both initiate and approve privileged changes.
• Require compensating controls for approved exceptions, with expiry dates.
• Recheck conflicts after role changes, token issuance, and automation updates.

For implementation depth, many teams pair access review tooling with policy-as-code patterns and entitlement analytics, then validate the resulting conflicts against actual privilege paths. The operational goal is to prevent a review from becoming a box-ticking exercise. These controls tend to break down in environments with sprawling service account sprawl, informal exception handling, and no reliable inventory of which NHI can execute which business action.

Common Variations and Edge Cases

Tighter SoD enforcement often increases review time and exception handling overhead, requiring organisations to balance control strength against operational speed. That tradeoff becomes sharper in engineering and DevOps environments, where automation pipelines need narrow but legitimate cross-functional access.

There is no universal standard for SoD implementation in NHI-heavy workflows yet, so current guidance suggests focusing on the highest-risk conflicts first: payment approval, production deployment, key management, privileged admin, and audit logging. In some cases, a single NHI may legitimately need broad technical reach during an incident, but that access should be time-bound, monitored, and revoked immediately after use. NHI Mgmt Group’s NHI Lifecycle Management Guide is especially relevant here because lifecycle controls determine whether conflict checks stay current after onboarding, rotation, or offboarding. For control design, teams can use 52 NHI Breaches Analysis to see how privilege accumulation and weak governance often intersect. The practical exception is emergency access: it can bypass normal SoD only if it is separately approved, tightly logged, and reviewed after the event, not folded into routine access review.

Related resources from NHI Mgmt Group

• What breaks when signing workflows depend on certificate-based admin access alone?
• What breaks when account correlation is not verified before provisioning access?
• What breaks when separation of duties is checked only at periodic intervals instead of continuously?
• What breaks when emergency access is granted without strong review and revocation controls?