They often scope SoD to human users and leave non-human identities outside the model. That creates blind spots, because service accounts, integrations, and AI-driven workflows can move data or trigger approvals across systems with the same business impact as a person.
Why This Matters for Security Teams
Segregation of Duties only works when it covers every identity that can initiate, transform, or approve a business process. If service accounts, API keys, CI/CD automation, and integrations sit outside the SoD model, teams can preserve the appearance of control while still allowing one workflow to create, move, and approve data across systems. That is a governance failure, not just an IAM gap.
This matters because non-human identities are not edge cases. NHIs now outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs — What are Non-Human Identities. When that blind spot exists, SoD becomes a paper control that misses the actual execution path. NIST control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that separation must be enforced across roles and system actors, not just named people. In practice, many security teams discover SoD drift only after an automation path has already moved sensitive data or triggered an approval outside the intended review chain.
How It Works in Practice
Effective SoD for automation starts by treating the service account as an actor with business consequence, not as a technical dependency. That means mapping each non-human identity to the process steps it can execute, then checking whether a single workflow can create, approve, reconcile, and export the same record. The control question is not “who owns the account?” but “can one identity complete incompatible actions without an independent check?”
Security teams usually need three layers of enforcement:
- Inventory the non-human identities used by ERP jobs, ETL pipelines, ticketing automations, and app-to-app integrations.
- Assign process-level SoD rules that reflect the real transaction flow, including handoffs between systems.
- Use short-lived credentials, scoped tokens, and approval-bound access so the automation only has authority for the specific task.
This is where the research on service accounts becomes practical. The 52 NHI Breaches Analysis shows how frequently compromised machine identities become the path to broad operational access. NIST guidance on access control and auditability in NIST SP 800-53 Rev 5 Security and Privacy Controls supports logging, approval traceability, and least privilege as baseline expectations. That becomes especially important when automation chains span SaaS platforms, because a service account in one system can silently perform the “first half” of a prohibited SoD combination and pass the result to another system. These controls tend to break down when workflow ownership is fragmented across teams because no single control owner sees the full cross-system transaction path.
Common Variations and Edge Cases
Tighter SoD often increases operational overhead, requiring organisations to balance fraud prevention against automation speed and maintenance cost. That tradeoff is real, especially where job scheduling, exception handling, and emergency access already create pressure to simplify controls.
One common edge case is shared automation across multiple business units. Current guidance suggests that SoD should follow the transaction, not the organisational chart, but there is no universal standard for this yet. A platform team may own the account while finance, procurement, and operations each rely on it differently, which makes a single role-based policy too coarse.
Another edge case is agentic or AI-assisted workflows. When an agent can decide which tool to call next, static role definitions become weaker than runtime policy checks. The safer pattern is context-aware authorisation, JIT credential issuance, and full event logging so that each step is evaluated in context rather than assumed safe because the service account was “approved” once. For broader NHI governance, Ultimate Guide to NHIs — What are Non-Human Identities is a useful baseline for lifecycle and visibility discipline. In regulated environments, the most difficult failures occur where a single integration account bridges multiple control domains and nobody has mapped the effective SoD boundary.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Service accounts must be inventoried before SoD can include them. |
| OWASP Agentic AI Top 10 | A1 | Autonomous workflows can bypass static SoD if runtime actions are not constrained. |
| CSA MAESTRO | TR-1 | Agentic and automated workflows need transaction-level governance and traceability. |
| NIST AI RMF | AI governance must account for automated decisions that affect separation of duties. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is required for both human and non-human actors. |
Map automated transactions end to end and enforce approval checkpoints at each trust boundary.
Related resources from NHI Mgmt Group
- What do security teams get wrong about protecting service accounts from interception?
- What do IAM teams get wrong about SoD for service accounts and shared accounts?
- What do security teams get wrong about ownership for service accounts and tokens?
- What do security teams get wrong about service accounts in PCI environments?
