Segregation of duties still breaks first at identity control points

At a glance

What this is: This is an explanatory governance post arguing that segregation of duties remains essential because modern identity, cloud, and workflow systems still fail when one actor can both act and certify the same process.

Why it matters: It matters because IAM, PAM, and NHI programmes all rely on separating authority from execution, and SoD gaps become access, audit, and fraud risks across human, workload, and automated identities.

👉 Read SecurEnds' guide to segregation of duties in finance, IT, and HR

Context

Segregation of duties is a control design pattern, not a compliance slogan. The core idea is simple: the same identity should not be able to initiate, approve, and record a sensitive action without independent oversight. In identity programmes, that becomes a question of who can change access, who can use it, and who can certify that it was appropriate.

The article’s real relevance is that SoD now sits inside IAM, PAM, and NHI governance rather than beside them. As cloud infrastructure, payroll systems, and DevOps workflows converge, the separation problem shifts from job titles to entitlements, approvals, and logging paths. That is why the Ultimate Guide to NHIs is useful background for the access and lifecycle side of the issue.

Key questions

Q: How should security teams implement segregation of duties in cloud and IAM environments?

A: Start by identifying the actions that should never sit with one identity, such as approving access, using elevated access, and certifying the outcome. Then enforce separation through roles, approval workflows, and independent review. In cloud and IAM environments, the most common failure is letting one person or service account own both privilege administration and evidence creation.

Q: Why do service accounts and automation identities make segregation of duties harder?

A: Because service accounts can operate at machine speed and often bypass the informal controls used around human work. If the same automation identity can trigger, change, and verify a workflow, SoD becomes impossible to demonstrate after the fact. The answer is to separate creation, execution, and review rights as tightly for NHI as for human users.

Q: What breaks when one role can approve and execute the same transaction?

A: The control loses independence, which means mistakes and fraud are harder to detect and easier to hide. Auditors cannot trust the record when the same role can both perform the action and sign off on it. That is why SoD requires distinct authorisation, execution, and reconciliation paths.

Q: How do organisations know if segregation of duties is actually working?

A: They look for evidence that conflicting access is rare, reviewed, and remediated quickly. A working SoD programme produces clean access reviews, separate approval chains, and logs that show independent validation. If the same identity keeps appearing across multiple control steps, the programme is failing even if policy says otherwise.

Technical breakdown

Authorization, custody, recordkeeping, and reconciliation in identity workflows

SoD is usually described through four control functions. Authorization means approving the action, custody means controlling the asset or entitlement, recordkeeping means creating the audit trail, and reconciliation means independently verifying that the record matches the action. In modern IAM, those functions can sit in different systems, but the risk appears when one identity can influence more than one stage. That is especially true when access administration, log visibility, and remediation rights converge in the same operational team. Practical implication: map each sensitive workflow to these four functions and remove any identity overlap that collapses them into one control surface.

Practical implication: map each sensitive workflow to these four functions and remove any identity overlap that collapses them into one control surface.

SoD violations in cloud and DevOps environments

In cloud and DevOps environments, SoD breaks when the same person or service path can change code, approve deployment, and manage credentials or audit logs. The article reflects a common enterprise failure mode: access expands with role growth, but review and deprovisioning lag behind. That creates a control gap where production changes are no longer independently observable. For NHI governance, the parallel risk is service accounts or automation identities that can both execute and validate a workflow. Practical implication: separate production change authority from deployment and audit authority, and treat credential administration as its own privileged function.

Practical implication: separate production change authority from deployment and audit authority, and treat credential administration as its own privileged function.

Automation as SoD enforcement, not SoD replacement

Automation does not remove the need for SoD, but it can enforce it more consistently than manual review. The key distinction is that automated SoD monitoring detects conflicting access patterns, while the control itself still depends on role design, approval boundaries, and deprovisioning discipline. In identity terms, automation is a detection and workflow layer, not the governance rule. This matters most where access changes quickly, such as cloud, HR, and finance operations. Practical implication: use automated conflict detection to surface violations early, then fix the role model and approval path that created them.

Practical implication: use automated conflict detection to surface violations early, then fix the role model and approval path that created them.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SoD failures are identity failures, not just process failures. The article treats segregation of duties as a business control, but in practice the break happens when identity entitlements allow one actor to both create and certify a sensitive action. That is an IAM design problem as much as a policy problem. When access governance, approvals, and evidence collection are not separated, the audit trail loses independence. Practitioners should treat SoD as an entitlement architecture requirement, not a documentation exercise.

Cloud and DevOps have turned classic SoD into a privileged workflow problem. The article’s examples show how developers, operators, and approvers can collapse into one operational path if access is not deliberately segmented. In NHI terms, the same risk appears when automation identities can deploy, modify, and attest within the same pipeline. That is where separation becomes difficult to prove after the fact. Practitioners need to model SoD around execution paths, not just job descriptions.

Automation strengthens SoD only when the control model is already clear. Continuous monitoring can surface conflicts faster, but it cannot compensate for a role design that lets one identity own too much of the process. This is the same pattern seen in overloaded service accounts and broad cloud permissions. The real governance question is whether the enterprise can still demonstrate independent review. Practitioners should align automation to control boundaries, not use it to justify collapsing them.

Separation of duties debt: As organisations move from manual approval chains to cloud-native workflows, they accumulate a governance debt where identity roles outgrow the controls that were meant to separate them. The result is not only more risk, but less provable accountability when auditors or regulators ask who was able to act, approve, and record the same event. Practitioners should measure SoD by independence, not policy language.

SoD is one of the few controls that connects human IAM, PAM, and NHI governance in a single model. Finance approval, developer deployment, and service-account privilege problems all fail for the same reason: one identity or role can cross too many control boundaries. That makes SoD a useful bridge concept for identity teams that still operate in silos. Practitioners should use SoD reviews to expose where human roles and machine identities are governed by different standards.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means SoD reviews often start from incomplete entitlement data rather than a reliable baseline.
• For the control model behind this issue, see Ultimate Guide to NHIs , Standards for the frameworks that anchor least-privilege and lifecycle governance.

What this signals

Separation of duties becomes harder to prove as identities multiply across cloud and automation layers. With NHIs outnumbering human identities by 25x to 50x in modern enterprises, the control problem is no longer limited to people and approvals. It now includes service accounts, tokens, and deployment paths that can collapse the same workflow into one identity domain.

Separation of duties debt: the longer organisations tolerate overlapping privilege, the more they normalise control paths that cannot be independently reviewed. That makes SoD a lifecycle and entitlement issue, not just an audit finding. Teams that still rely on manual separation will find the gap widens fastest in hybrid environments.

The practical signal is simple: if a role can both change a process and explain that change afterward, SoD is only partially in place. Mature IAM programmes should treat that as a design defect and trace it back to roles, approvals, and credential ownership.

For practitioners

• Map sensitive workflows to control functions Break each high-risk process into authorization, custody, recordkeeping, and reconciliation, then assign each function to different roles or systems. The goal is to prevent one identity from approving, executing, and certifying the same action.
• Separate privileged administration from operational execution Keep account administration, production deployment, and audit-log management in distinct hands. In cloud and NHI environments, that includes service account ownership, token issuance, and change approval.
• Automate conflict detection and recertification Use access reviews and rule-based monitoring to flag role combinations that create SoD conflicts, then route them into remediation before the next audit cycle. Do not rely on spreadsheets or ad hoc manager checks.
• Treat contractor and leaver access as a SoD risk Remove inherited access promptly when roles change or engagements end, especially where third parties can still approve, record, or reconcile sensitive actions. SoD breaks quickly when offboarding lags.

Key takeaways

• Segregation of duties remains a control architecture problem, and identity entitlements are where it most often fails.
• The scale of the issue is now driven by cloud roles, service accounts, and automation paths, not just human workflow design.
• Practitioners should review approval, execution, and reconciliation as separate identity functions, then remove overlaps before audit or abuse exposes them.

Key terms

• Segregation of Duties: Segregation of duties is the practice of separating sensitive tasks so one identity cannot create, approve, and verify the same action. In identity governance, it is a control architecture issue that applies to humans, service accounts, and automation alike, because independence of review is what makes accountability real.
• Reconciliation: Reconciliation is the independent review step that checks whether an action, record, or entitlement matches what should have happened. In IAM and NHI governance, it helps prove that access changes, transactions, and privileged operations were not only performed, but correctly validated by a separate control path.
• Privilege Overlap: Privilege overlap occurs when one identity or role holds enough access to perform multiple stages of a high-risk process. It is a common SoD failure mode because the same account can approve, execute, and obscure the action, making both misuse and error harder to detect.

Deepen your knowledge

Segregation of duties, privilege separation, and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are rebuilding control boundaries across cloud and automation, it is worth exploring.

This post draws on content published by SecurEnds: Segregation of Duties explained for modern enterprises. Read the original.