No. SoD automation should be designed to include machine identities from the start because service accounts, APIs, bots, and automation workloads participate in the same entitlement ecosystem as humans. If they are left outside the policy scope, the organisation creates a blind spot where risky access can evade the very governance model meant to prevent it.
Why SoD Has to Cover Machine Identities Up Front
Segregation of duties is only effective when it sees the full entitlement picture. If machine identities are excluded, the policy may look complete on paper while leaving service accounts, bots, APIs, and workloads free to combine permissions in ways that would be blocked for people. That creates an avoidable control gap, not a cleaner rollout.
In practice, SoD is about who can initiate, approve, execute, and reconcile a sensitive action. A machine identity can hold the same permissions, trigger the same workflow, and reach the same systems as a human user, so the control logic must evaluate it the same way. The design question is not whether machines are different, but whether they change the entitlement graph.
That is why a phased approach that starts with humans and “adds machines later” often fails at the point of governance, not implementation. The moment machine identities can create, approve, deploy, transfer, or otherwise influence sensitive activity, they belong in the ruleset that defines conflicting access. This is especially true where automation is used to increase speed, because speed amplifies any hidden entitlement overlap.
Where SoD Breaks When Machines Are Left Out
Leaving machine identities outside SoD scope produces a blind spot in discovery, policy evaluation, and exception management. Teams may review user roles carefully while missing a bot account with broad access, a CI/CD credential that can promote code and approve changes, or an API principal that can both request and enact a sensitive transaction.
That gap matters because SoD problems are often not about one obvious toxic pair, but about combinations spread across human and non-human actors. A machine identity can become the hidden second half of a conflict that appears harmless in user access reviews. If the control model only checks people, the organisation can miss the actual path by which prohibited combinations are assembled.
For a practical governance view of this problem, the Segregation of Duties (SoD) Guide explicitly extends SoD rulesets to service accounts, bots and AI agents. The broader identity foundation is covered in IAM and IGA Basics, which is useful when teams need to align access governance with entitlement design rather than bolt governance on later.
When the question is specifically about machine identities, the operational detail matters. NHI Lifecycle Management Guide helps frame how provisioning, rotation, offboarding, and access review should be handled as part of governance, not as separate cleanup work after the fact.
How to Sequence SoD and Identity Governance in Practice
The sensible sequence is to define the SoD policy model once, then apply it across all identity types at the same time. That means mapping privileged actions, conflict pairs, and compensating controls in a way that can evaluate humans and machines against the same business rule, even if the enforcement mechanisms differ.
Practitioners should verify three things before calling the control mature: first, machine identities are inventoried with owners and business context; second, their entitlements are classified into the same conflict model used for humans; third, exception handling is explicit and time bound, not informal. If any of those are missing, the SoD design is incomplete.
For organisations building out machine identity governance, the best navigation path is usually to start with ownership, entitlement mapping, and rotation discipline together. The NHI Ownership and Accountability Guide is useful where unclear ownership would otherwise block recertification and exception review, while the Guide to NHI Rotation Challenges highlights why long-lived credentials often undermine the governance model you think you have.
If your environment uses service accounts for workflows, orchestration, or release automation, the review should happen before scale, not after. A small pilot that already includes machine identities is much easier to govern than a later retrofit, because you avoid reworking the policy model, the entitlement catalogue, and the exception process twice.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-5 — Separation of Duties | SoD conflicts must cover both human and machine identities. |
| IA-5 — Authenticator Management | Machine identities rely on managed credentials that affect governance scope. | |
| AC-6 — Least Privilege | Machine identities often become hidden overprivilege sources inside SoD conflicts. | |
| Recommendation — Apply AC-5 to detect and prevent conflicting access across all identity types. Manage machine credential lifecycle so SoD rules see current, valid access paths. Reduce non-human entitlements to the minimum needed for the approved task. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | SoD expansion to machine identities is an access-control design issue. |
| A.8.2 — Privileged access rights | Machine identities can hold privileged rights that create SoD conflicts. | |
| A.5.18 — Access rights | The question turns on who receives and retains access rights over time. | |
| Recommendation — Define access rules that cover service accounts, bots, and automation workloads. Review and restrict privileged machine access under the same governance model as users. Recertify machine access rights on the same schedule and evidence standard as human access. | ||
| CIS Controls v8 | CIS-5 — Account Management | SoD depends on complete account inventory, ownership, and lifecycle control. |
| CIS-6 — Access Control Management | SoD enforcement relies on restricting conflicting permissions. | |
| CIS-8 — Audit Log Management | SoD needs auditability for machine-initiated sensitive actions. | |
| Recommendation — Inventory and govern machine accounts alongside human accounts. Constrain conflicting entitlements before they reach production workflows. Log machine identity actions so conflict violations can be detected and reviewed. | ||
Practitioner Guidance
What to verify: Confirm that SoD rules are evaluated against all identity classes that can initiate or complete a sensitive action, including service accounts, automation users, and API principals. If a non-human account can create, approve, or deploy, it belongs in the same conflict analysis as a person.
Decision rule: If a machine identity can participate in a business-critical transaction path, include it in SoD design from day one. Treat “we will govern it later” as a temporary exception with an expiry date, not as a control strategy.
What good looks like: The entitlement catalogue, recertification workflow, and exception register should all show the same conflict logic regardless of whether the actor is human or machine. If they do not, the programme is still relying on partial visibility.
Practitioner takeaway: The right control boundary is the entitlement ecosystem, not the user population, so delaying machine identities usually delays the only version of SoD that can actually hold up under audit and abuse.
Related resources from NHI Mgmt Group
- Should organisations prioritise identity governance before expanding agentic AI?
- Should organisations prioritize securing machine identities before expanding agentic AI use?
- What do organisations get wrong about machine identities and identity governance?
- Should organisations prioritise simplification before expanding identity governance scope?