Why do separation of duties controls fail even when policies exist?

Why This Matters for Security Teams

Separation of duties is meant to stop one actor from controlling an entire sensitive process, but that protection disappears when the workflow is built as a chain of tickets rather than independent decisions. In NHI environments, the same weakness appears with secrets, service accounts, and automated provisioning paths: a policy may exist, yet the operational path still lets one team or tool influence every step. That creates audit comfort without real control.

This matters because control failure is usually discovered during an incident, not during design review. The most common pattern is that request, approval, and execution sit in the same platform, or that privileged operators can both approve and deploy changes. The result is a single trust path where independence was assumed, not enforced. Current guidance in NIST Cybersecurity Framework 2.0 emphasizes accountable governance, but practitioners still need implementation evidence that the control is truly separated.

For NHI and agentic environments, that weakness becomes more visible because credentials can be issued, reused, and propagated at machine speed. A policy document does not prevent a build pipeline, bot, or admin from completing every action end to end. In practice, many security teams encounter separation of duties failures only after a privileged workflow has already been abused, rather than through intentional control testing.

How It Works in Practice

Real separation of duties requires independence at the point of action, not just on paper. That usually means one role requests access, another approves it, and a separate system provisions the entitlement, with each step producing immutable logs. For NHI controls, that same pattern should apply to secrets issuance, key rotation, and service account changes. A reviewer should be able to prove that the approver could not also execute the change, and that the executor could not self-approve.

Operationally, teams should look for where control can collapse into a single operator path. Common safeguards include RBAC with constrained admin scopes, JIT credential issuance for temporary elevation, and workflow engines that enforce independent approval gates. For machine identities, this is often stronger when paired with lifecycle controls described in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, because creation, use, rotation, and decommissioning need distinct owners and evidence.

• Separate request, approval, and provisioning into different systems or at least different control domains.
• Require independent reviewers for privileged changes, especially for secrets and service accounts.
• Use time-bound access and revoke it automatically after the task is complete.
• Preserve audit trails that show who approved, who executed, and what was provisioned.

For organisations dealing with secret sprawl, the problem is compounded by weak visibility: the State of Secrets in AppSec reports that organisations maintain an average of 6 distinct secrets manager instances, which fragments control and makes independence harder to prove. These controls tend to break down when provisioning is embedded in the same CI/CD pipeline that requests approval, because the approver can influence the execution path directly.

Common Variations and Edge Cases

Tighter separation of duties often increases operational friction, requiring organisations to balance fraud prevention and auditability against speed and automation. That tradeoff is especially visible in DevOps, where overly rigid approvals can push teams toward bypasses unless the control design matches real delivery workflows.

There is no universal standard for this yet in highly automated NHI and agentic environments, so best practice is evolving. For autonomous workloads, classic SoD can be too static if a single pipeline legitimately needs to create, use, and rotate ephemeral credentials during a short task window. In that case, the better question is whether the system can still demonstrate independent control over the decision to grant privilege, not whether every step is performed by a different human.

That distinction matters when agents or automation tools have tool access and execution authority. A workflow may satisfy policy wording while still allowing one orchestration layer to request, approve, and act. The Top 10 NHI Issues and the Ultimate Guide to NHIs — Regulatory and Audit Perspectives both reflect the same operational reality: auditors will look for evidence of independence, not just policy language.

In environments with shared admin consoles, delegated approvals, or exception-heavy emergency access, the control can also fail because no one can prove who had final authority at the moment the action occurred. That is why current guidance suggests pairing SoD with JIT access, immutable logging, and periodic control testing rather than assuming policy text is sufficient.

Related resources from NHI Mgmt Group

• Why do non-human identities create compliance risk even when policies exist?
• Why do segregation of duties controls fail in cloud and SaaS environments?
• Why do AI programmes fail to show value even when pilots look successful?
• What is the difference between human IAM controls and NHI governance?