Should SoD controls also cover service accounts and automation?

Why This Matters for Security Teams

Separation of duties is not only a human access problem. service account, CI/CD bots, schedulers, and agentic automation can accumulate conflicting privileges across request, execution, and approval paths, which turns a control designed to prevent abuse into a blind spot. That matters because NHI governance failures are already common: the Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. The issue is not simply over-permissioning, but the lack of explicit lifecycle controls around identities that never log in like humans do.

Current guidance from the NIST Cybersecurity Framework 2.0 pushes organisations toward identity governance, least privilege, and continuous risk treatment, but many teams still stop their SoD review at employees and contractors. That leaves automation able to both initiate and complete sensitive actions, especially where scripts, orchestration platforms, and service principals are reused across environments. In practice, many security teams encounter SoD failures only after a pipeline, bot, or service account has already approved and executed an action that should have required independent review.

How It Works in Practice

For service accounts and automation, SoD needs to be expressed as a control over workflow paths, not just job titles. The practical question is whether a single non-human identity can initiate, approve, deploy, modify, or exfiltrate the same protected object without an independent check. If yes, the control is incomplete. The better pattern is to separate identities by function, scope them to a single task class, and enforce approval steps through distinct human or system trust boundaries.

Practitioners usually implement this by combining identity design with runtime policy:

• Use distinct service accounts for request, execution, and approval steps.
• Bind each account to a narrow workload, environment, and resource set.
• Issue short-lived credentials where possible instead of reusing static secrets.
• Require policy evaluation at the point of action, not only during provisioning.
• Log which NHI initiated the action, which identity approved it, and which one executed it.

That model fits the evidence in 52 NHI Breaches Analysis, which shows how service accounts become high-impact pivot points when their permissions are broader than the task requires. It also aligns with the NIST CSF emphasis on governance and access management, especially where automation spans production, secrets stores, and deployment tooling. Where organisations use workflow engines, ticketing bots, or privileged automation, SoD should be tested end to end: who can trigger the job, who can change its parameters, who can approve exceptions, and who can complete the privileged outcome. These controls tend to break down in highly shared platform accounts because ownership, attribution, and policy enforcement are no longer tied to a single workload identity.

Common Variations and Edge Cases

Tighter SoD often increases operational overhead, so organisations need to balance stronger abuse prevention against deployment speed and platform complexity. That tradeoff is real, especially in DevOps and cloud operations where one automation chain may manage dozens of microservices.

There is no universal standard for this yet, but current guidance suggests three common exceptions deserve extra scrutiny. First, break-glass automation can be allowed, but only with time-bound credentials and explicit post-use review. Second, read-only service accounts may still violate SoD if they can influence decisions that later unlock privileged actions. Third, multi-agent or orchestrated AI systems should be treated as high-risk because one agent may request, another may enrich, and a third may execute, creating a hidden SoD collapse across the tool chain.

The most common mistake is assuming that “non-human” means “non-governed.” NHIs are part of the control environment, and the Ultimate Guide to NHIs — Standards reinforces that identity lifecycle, rotation, and access review must cover machine identities too. For teams formalising policy, SoD should be reviewed alongside privilege assignment, secrets handling, and exception management, not as a separate human-only rule set.

Related resources from NHI Mgmt Group

• Why do service accounts and automation increase PII exposure risk?
• Who should own governance for automation workflows and service accounts?
• How should security teams apply SoD to service accounts and API keys?
• What problem does ownership attribution solve for service accounts and API keys?