What breaks when SoD is applied only to human users?

Why This Matters for Security Teams

Separation of duties only works when it covers every identity that can initiate or approve change. If the policy is limited to employees, service accounts, API keys, build bots, and workflow automations can still create deployments, modify infrastructure, or move data without a comparable control boundary. That leaves a false sense of compliance while the operational path to privilege remains open. NHI Mgmt Group has repeatedly shown that NHIs are a core control plane issue, not an edge case, and the broader problem is visible in the Ultimate Guide to NHIs.

Current guidance from NIST Cybersecurity Framework 2.0 still points security teams toward governing access, accountability, and change management as linked disciplines. That matters because SoD is not just about who signs off on a request, but who can actually execute the action. When machine identities are excluded, a human reviewer may approve a safe-looking workflow even though the implementation layer is fully capable of self-escalation. In practice, many security teams encounter this only after a CI/CD account, scheduler, or integration token has already been used to bypass the intended approval path.

How It Works in Practice

Human-only SoD usually breaks in three places. First, the business process may be separated on paper, but the underlying automation still shares credentials across build, test, deploy, and support functions. Second, RBAC often maps cleanly to people but poorly to autonomous workloads, because a bot or service account can act across multiple roles in a way no single employee should. Third, approval workflows may require a human to click “approve” while the actual deployer is a long-lived secret embedded in code or a pipeline variable. The result is an approval boundary without an execution boundary.

Practitioners should treat SoD as an identity design problem, not only a workflow policy. That means binding every machine identity to an owner, scoping its permissions to one purpose, and using JIT credentials or other short-lived secrets where possible. For state-changing actions, intent-based authorisation is increasingly discussed as a stronger pattern than static role checks, because the decision can evaluate what the workload is trying to do at runtime. NHI Mgmt Group’s Ultimate Guide to NHIs highlights why lifecycle control, rotation, and offboarding are part of the same control plane. On the standards side, the NIST Cybersecurity Framework 2.0 is useful for mapping who is accountable for access review, but it does not replace workload-level enforcement.

• Assign a named human owner to each service account, API key, and bot identity.
• Separate approval from execution, then verify the executor cannot also self-authorise.
• Use short-lived credentials with automated revocation after the task completes.
• Log both the approving human and the machine identity that performed the action.

These controls tend to break down when CI/CD, IaC, and ticketing systems share a single privileged token because one credential can traverse the entire change chain.

Common Variations and Edge Cases

Tighter SoD often increases operational overhead, requiring organisations to balance stronger control against deployment speed and support burden. That tradeoff is real in environments with release trains, infrastructure automation, or 24/7 incident response, where rigid human handoffs can slow recovery. Best practice is evolving toward risk-based separation: not every low-risk read action needs the same control as a database migration or secret rotation.

There is no universal standard for this yet, but guidance increasingly favours distinguishing between humans who approve, machines that execute, and systems that broker credentials. That is especially important for agentic systems, where an Agent can chain tools and act goal-driven rather than follow a fixed script. In those cases, static SoD becomes fragile unless paired with workload identity, real-time policy evaluation, and tightly bounded JIT access. The current NHI governance view in the Ultimate Guide to NHIs is that secrets, rotation, and offboarding must be enforced consistently across all identities, while NIST Cybersecurity Framework 2.0 remains useful for assigning oversight and review responsibilities.

The edge case is the “shared automation umbrella,” where multiple teams rely on one orchestration platform. That model can appear efficient, but it concentrates privilege and makes it hard to prove that SoD is actually preserved. In those environments, security teams should treat every reusable automation path as a potential shared-admin domain and require compensating controls, because once the orchestration layer can approve and execute its own changes, SoD is no longer meaningful.

Related resources from NHI Mgmt Group

• What breaks when DLP and DSPM are built only for users and files?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• Why do non-human identities create more audit risk than human accounts?