How should security teams apply SoD to service accounts and API keys?

Why This Matters for Security Teams

Segregation of duties is easy to describe and hard to enforce once a service account or api key is allowed to create, approve, and execute access in the same workflow. That is exactly why these identities need to be treated as governed workloads, not technical leftovers. When a single key can provision another key, modify policy, and trigger production actions, SoD becomes a paper control instead of an operational boundary. NIST’s NIST Cybersecurity Framework 2.0 reinforces the need for access governance, but the implementation details matter more for machine identities than for people.

Security teams should assume that secrets are already being created, copied, and reused outside the intended path. NHIMG research on Guide to the Secret Sprawl Challenge shows how quickly credentials spread across repos, chat, and ticketing systems, which makes SoD depend on control points rather than intention alone. The practical question is not whether an API key exists, but whether it can both initiate and finalise a sensitive action without independent oversight. In practice, many security teams discover SoD failure only after a key has already been reused across pipelines, rather than through deliberate design.

How It Works in Practice

Apply SoD to service accounts and API keys by mapping incompatible actions, then enforcing separation across provisioning, approval, execution, and review. The useful unit is not the credential itself, but the set of authorities attached to it. A key that can create users, mint new secrets, and deploy code should be split into narrower identities, each with a different purpose and control path. Current guidance suggests that the cleanest SoD boundary for machine identities is often between the system that requests access and the system that approves it.

In practice, security teams usually implement this with a matrix that defines combinations that must never sit on the same principal. For example, one service account may read data, another may write to a release channel, and a separate approval workflow may be required before a production change is activated. That pattern is easier to defend when paired with short-lived secrets and workload identity. The NHIMG article 52 NHI Breaches Analysis is a useful reminder that machine credentials are often involved in lateral movement once they are over-permissioned.

• Define incompatible combinations such as create and approve, deploy and attest, or export and delete.
• Issue separate identities for request, execution, and review where the platform allows it.
• Use policy-as-code to evaluate access at request time, not just during provisioning.
• Prefer ephemeral secrets with tight TTLs so approval and execution are not both available in the same long-lived credential.

For control design, OWASP guidance for agentic and model-driven systems and the CSA MAESTRO framework both point toward runtime governance rather than static trust. These controls tend to break down in legacy automation stacks where one shared service account owns both the orchestration tool and the target system, because there is no clean place to separate approval from execution.

Common Variations and Edge Cases

Tighter SoD often increases operational overhead, requiring organisations to balance blast-radius reduction against delivery speed and administrative complexity. That tradeoff is real, especially when a platform was built around one integration token or one “automation” account that now supports multiple teams. Best practice is evolving, and there is no universal standard for this yet, so teams should document where strict SoD is mandatory and where compensating controls are acceptable.

One common edge case is emergency access. A break-glass service account may legitimately combine actions that are normally separated, but it should be heavily constrained, monitored, and reviewed after use. Another is read-only analytics jobs that become write-capable during maintenance windows; those temporary changes need explicit expiry and independent approval. NHIMG’s Dropbox Sign breach and BeyondTrust API key breach illustrate how broadly exposed machine credentials can become when administrative paths are not sharply separated. The point is not to eliminate every shared function, but to make exceptions visible, time-bound, and reviewable.

Security teams also need to adjust for SaaS and CI/CD environments, where a single API key may be able to approve builds, publish artifacts, and rotate downstream secrets. That is where SoD should be enforced through workflow design, not just RBAC labels. In environments with high automation density and weak secret lifecycle controls, the model is especially fragile because one compromised key can impersonate multiple business steps at once.

Related resources from NHI Mgmt Group

• How should security teams assess vendor access that includes service accounts or API keys?
• How should security teams govern API keys used for generative AI access?
• What problem does ownership attribution solve for service accounts and API keys?
• How should security teams govern Active Directory service accounts?