Should organisations include service accounts in segregation of duties checks?

Why service accounts belong in SoD checks

segregation of duties is about preventing a single actor, or a single access path, from completing a sensitive workflow end to end. Service accounts are part of that control model because they can initiate approvals, move data, create transactions, or change configuration without a human sitting in the loop. If they are exempted, SoD becomes incomplete rather than risk-based.

That matters most where a service account is embedded in automation, integration, or batch processing. The governance question is not whether the account is human, but whether it can combine conflicting actions that should not be concentrated in one trust path.

What changes when the account is non-human

The non-human nature of the account changes the review pattern, not the basic SoD logic. Practitioners need to check who owns the account, what system it serves, whether the permissions are narrowly scoped, and whether the account can bypass approval, creation, posting, or release boundaries. Segregation of Duties (SoD) Guide is useful here because it explicitly treats service accounts, bots, and AI agents as SoD subjects when they can exercise sensitive functions.

This is also why service accounts often need a different evidence set from user accounts. For a human, you can inspect role assignments and session behaviour. For a service account, you also need the calling system, the integration purpose, and the allowed transaction path, because the account may represent a business process rather than an individual.

How to apply SoD to service accounts without breaking automation

Start by mapping each service account to the business activity it performs, then ask whether that activity conflicts with any other privileged step in the same process. IAM and IGA Basics is a strong reference point for this mapping because SoD only works when access governance covers both people and machines, including entitlement reviews and conflict detection.

Where a service account is genuinely required, the usual answer is not to remove it from governance, but to narrow its scope and compensate with stronger controls. That may mean separate accounts for separate workflow stages, tighter authorization boundaries, and explicit review of any account that can both initiate and approve a sensitive action. Service Account Security Guide supports that posture by focusing on discovery, least privilege, and governance for service accounts across platforms.

In practice, SoD checks should flag service accounts that can write records and also release them, create entitlements and also approve them, or change a control and also certify it. When a single integration user can do both sides of a control pair, the control is usually compensating at best, and weak at worst.

Risk and Threat Considerations

Excluding service accounts from SoD creates a parallel access path that often has higher privilege and weaker visibility than the human path. That increases the chance of fraud, accidental misuse, and undetected privilege concentration, especially when a shared automation account is reused across systems or environments.

Failure mechanism: A service account is allowed to execute conflicting steps in the same workflow, so the organisation loses the independent check that SoD is meant to provide. An attacker or insider can then abuse that path to bypass approval, conceal transaction origin, or move laterally through connected systems.

Impact: Sensitive transactions can be completed without effective challenge, auditability drops, and remediation becomes harder because the action appears to come from an approved system rather than a specific accountable user or bounded process.

Practitioner Guidance

What to verify: For each service account, verify whether it can both create and approve, request and fulfil, post and reconcile, or configure and certify the same control domain. If yes, treat that as an SoD conflict unless a documented compensating control is truly independent.

Decision rule: If the account can influence a sensitive outcome, include it in the SoD ruleset even when it is not tied to a named person. If it cannot be cleanly modelled in your SoD tooling, that is usually a governance gap, not a reason to exclude it.

Practitioner takeaway: The right test is not “is this account human?”, it is “can this account complete a conflicting business path without an independent control?” If the answer is yes, SoD must cover it.

Related resources from NHI Mgmt Group

• What problem does ownership attribution solve for service accounts and API keys?
• When do service accounts become a higher risk than ordinary user accounts?
• How should security teams govern Active Directory service accounts?
• Why do service accounts create segregation of duties risks in cloud IAM?