How should organisations evaluate SoD for service accounts and automation identities?

Why This Matters for Security Teams

Segregation of Duties for service account and automation identities is a control question, not a personnel question. The risk is that a single non-human identity can chain otherwise acceptable permissions into a prohibited business outcome, such as creating, approving, and executing the same transaction. That is why the analysis has to follow the action path across systems, not stop at one entitlement at a time. NIST’s Cybersecurity Framework 2.0 reinforces the need to govern access in a way that supports risk-based operational controls.

NHIMG research shows that NHI exposure is not abstract: Ultimate Guide to NHIs — What are Non-Human Identities notes that 97% of NHIs carry excessive privileges, which makes SoD failures more likely when automation accounts are left with broad, overlapping rights. In practice, many security teams discover SoD gaps only after a service account has already moved data, posted changes, or approved exceptions that no single reviewer expected it to combine.

How It Works in Practice

Effective SoD review for automation identities starts with mapping business actions, not just technical permissions. A service account may look harmless if one team sees only database write access and another sees only workflow approval access, but SoD should ask whether those permissions together allow an end-to-end conflicting outcome. That means classifying the identity by the business process it supports, the systems it touches, and the strongest action it can complete without human intervention.

Security and IAM teams should evaluate service accounts across four layers:

• Business action: can the identity create, approve, release, reconcile, or reverse the same process?
• System path: can it move data between systems that normally require separate reviewers?
• Privilege scope: does it have broad read, write, or admin access that enables privilege chaining?
• Operational guardrails: are approvals, JIT elevation, or time-bound tokens limiting the blast radius?

Current guidance suggests treating automation identities as workload identities with explicit ownership, purpose, and runtime controls. That aligns well with Zero Trust thinking and with the NHI lifecycle guidance in NHIMG’s 52 NHI Breaches Analysis, where abuse often follows excessive access and poor visibility rather than a single broken control. The practical test is simple: if the identity can complete a prohibited sequence without an independent checkpoint, the SoD design has failed even if each permission appears individually justified. For policy design, NIST’s Cybersecurity Framework 2.0 is useful for aligning identity governance, access review, and monitoring around measurable risk outcomes.

These controls tend to break down in event-driven architectures and CI/CD pipelines because permissions are distributed across code, orchestration, and cloud services, making the full action chain hard to see in one control plane.

Common Variations and Edge Cases

Tighter SoD for automation often increases operational overhead, requiring organisations to balance control strength against deployment speed and reliability. That tradeoff is real, especially where service accounts are embedded in legacy ERP, batch jobs, or integration middleware that was never designed for fine-grained approval separation. Current guidance suggests documenting exceptions rather than pretending they do not exist.

There is no universal standard for every edge case yet, but a few patterns are consistent. Break-glass automation accounts may be acceptable if they are heavily monitored, time-bound, and independently approved. Shared service accounts are harder to defend because ownership and attribution are blurred, so best practice is to move toward named workload identities wherever possible. In high-volume environments, SoD may be enforced through compensating controls such as step-up approvals, ticket binding, or downstream transaction monitoring instead of strict pre-execution blocking.

One useful way to decide is to ask whether the automation identity can both initiate and finalize an irreversible business event. If it can, the organisation should either split the workflow, add a separate approval path, or constrain the account with just-in-time access and short-lived credentials. For identity governance context, the Ultimate Guide to NHIs — What are Non-Human Identities is a practical reference point for understanding why visibility and rotation matter as much as the access model itself.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• How should security teams govern non-human identities alongside human accounts?
• How can organisations reduce the blast radius of compromised agent identities?
• What problem does ownership attribution solve for service accounts and API keys?