By NHI Mgmt Group Editorial TeamPublished 2026-01-09Domain: Governance & RiskSource: Delinea

TL;DR: As organizations add more applications and hybrid access paths, segregation of duties becomes harder to enforce consistently across ERP and business systems, according to Delinea’s 2026 roundup. The control now has to work as an operating discipline, not just an audit requirement, because weak application-level separation leaves risky combinations of access intact.


At a glance

What this is: This is Delinea’s 2026 roundup of segregation of duties tools, highlighting that SoD must be enforced across multiple applications and workflows, not only inside a single ERP.

Why it matters: It matters because IAM, IGA, PAM, and audit teams need SoD controls that reflect how privileges actually span applications, so conflicts are found before they become compliance failures or internal risk.

👉 Read Delinea's 2026 comparison of segregation of duties solutions


Context

Segregation of duties is the control that prevents one identity from holding incompatible access paths at the same time. In practice, that means the programme has to understand business roles, privileged actions, and application-specific conflicts across ERP and adjacent systems, not just inside one core platform. As environments grow, the control problem becomes one of visibility and governance across systems rather than policy on paper.

Delinea’s article is really about a familiar IAM problem in a more distributed form: access combinations are easy to miss once finance, HR, CRM, and cloud business apps all carry separate entitlement models. That makes SoD a cross-application governance issue, especially for teams responsible for audit evidence, access certification, and remediation workflows.


Key questions

Q: How should security teams implement segregation of duties across multiple business applications?

A: Start by mapping the business actions that must never sit in the same identity across ERP, finance, HR, CRM, and workflow systems. Then translate those actions into conflict rules that are checked whenever access changes, not only during audit season. The goal is to catch toxic combinations before they become operationally usable.

Q: Why do segregation of duties controls break down in hybrid and multi-application environments?

A: They break down because access governance is often built around one system at a time, while real users and service identities operate across several platforms. A role that looks harmless in one application can complete an incompatible workflow when combined with another entitlement elsewhere. SoD fails when the control model stops at the platform boundary.

Q: What do teams get wrong when they treat SoD as only an audit requirement?

A: They focus on proving compliance after the fact instead of preventing risky access combinations in the first place. That usually leads to manual reviews, weak evidence chains, and delayed remediation. Effective SoD governance is operational, continuous, and tied to lifecycle events that change access.

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

A: They should ask whether a non-human identity can assemble incompatible business actions across systems, even if each permission appears isolated. If an automation account can create, approve, and post transactions or move data between sensitive systems, it deserves the same conflict analysis as a human user. SoD is about action combinations, not whether the actor is human.


Technical breakdown

Cross-application SoD risk analysis

Cross-application Segregation of Duties analysis checks whether one identity can assemble a risky workflow across multiple systems, even if each system looks acceptable in isolation. The control depends on correlation between entitlements, business functions, and sensitive actions. In ERP-heavy environments, the hard part is mapping equivalent privileges across different applications and detecting conflicts that emerge only when access is combined. That is why SoD tooling matters beyond a single system: the risk often lives in the intersection of systems, not within one permission set.

Practical implication: build SoD rules around cross-system entitlement combinations, not just native application roles.

Defensible audit trails for SoD

SoD controls have to be provable, not just enforced. Defensible audit trails show which access was reviewed, which conflicts were detected, what was remediated, and when the decision was made. For auditors, the question is whether the organisation can reconstruct control operation consistently across time and across applications. That requires workflow evidence, not screenshots or manual assertions. When SoD lives inside identity governance and access management workflows, the evidence chain becomes part of the control itself.

Practical implication: preserve review, approval, and remediation records as control evidence for each sensitive access conflict.

Continuous access review versus point-in-time certification

Traditional access certification tells you whether a role was acceptable at a moment in time. Continuous access review looks for conflicts as access changes, business roles shift, and entitlements accumulate. That distinction matters in large environments because SoD violations can appear after a user moves roles or gains a new application permission. A point-in-time review can miss that drift. Continuous controls reduce that blind spot by tying SoD checks to ongoing change rather than annual or quarterly reviews alone.

Practical implication: connect SoD checks to lifecycle events so conflicts are detected when access changes, not after the next review cycle.


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 is no longer a single-application control problem. The article reflects a broader reality that segregation of duties fails when organisations still reason about access inside siloed platforms while users operate across ERP, CRM, HR, and finance systems. The control surface is now cross-application, so a clean role in one system can still create a toxic combination in another. Practitioners need to treat SoD as an identity governance problem across the application estate, not as a point solution inside one business suite.

Defensible evidence is becoming as important as detection. Audit teams do not only need to know that a conflict existed, they need to know how it was found, who reviewed it, and what happened next. That shifts SoD from a static compliance checkbox into a workflow discipline tied to access review, remediation, and retention of control evidence. Organisations that cannot show this chain will struggle to defend the effectiveness of their governance model during audit.

Cross-application SoD maps directly to NHI governance patterns. The same logic that exposes conflicting human entitlements also applies to service accounts, APIs, and workflow identities when they can initiate business actions across systems. NHI programmes that ignore SoD inherit the same blind spot human IAM has lived with for years: access that looks harmless in isolation but becomes risky in combination. The implication is that identity governance must evaluate relationships between entitlements, not just individual credentials.

Named concept: cross-application SoD drift. This is the gap that appears when entitlement changes accumulate across multiple business systems faster than governance can re-evaluate conflict rules. The result is not just more risk, but weaker assurance that the organisation still knows who can do what across the full process chain. Practitioners should treat this drift as a standing governance condition, not an occasional exception.

From our research:

  • Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
  • Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, which shows how quickly identity control failures recur once governance is weak.
  • If you are extending SoD into machine and automation governance, the NHI Lifecycle Management Guide is the next practical step for aligning review, rotation, and offboarding.

What this signals

Cross-application SoD drift: the real governance problem is not whether one platform has a rule, but whether the rule still holds after access changes across several systems. That is why SoD needs to sit inside identity governance and lifecycle review, not outside it as an audit overlay.

The control conversation is also broadening beyond human users. As service accounts and automation identities gain more influence over business workflows, SoD logic has to follow the action chain rather than the actor label. For teams modernising governance, the NIST Cybersecurity Framework 2.0 remains a useful way to anchor control ownership and evidence handling.

The practical signal for readers is simple: if your SoD programme cannot trace conflicts from entitlement change to remediation to retained evidence, it will struggle under audit and under operational pressure. The next step is to align access governance with lifecycle processes and treat conflict detection as a continuous control signal, not a periodic report.


For practitioners

  • Map SoD rules across business applications Define toxic combinations across ERP, CRM, HR, finance, and cloud business apps so conflicts are detected even when no single platform shows a violation. Use business process ownership to model which actions must never coexist in one identity.
  • Tie access reviews to remediation workflows Require every detected SoD conflict to produce a tracked remediation outcome, not just a review note. Preserve reviewer identity, decision timestamp, and closure status as audit evidence.
  • Expand SoD governance to non-human identities Review service accounts, integration users, and automation identities for combinations of permissions that can complete incompatible business steps. Apply the same conflict logic used for human users to machine identities that touch finance or operational data.

Key takeaways

  • Segregation of duties fails when organisations still think in single-system roles instead of cross-application action chains.
  • Audit defensibility now depends on workflow evidence, remediation tracking, and continuous conflict review, not just point-in-time certification.
  • SoD governance should extend to service accounts and automation identities whenever they can assemble incompatible business actions.

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 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AC-4SoD is an access permissions governance control across applications.
OWASP Non-Human Identity Top 10NHI-03Cross-application identities need lifecycle controls and conflict visibility.
NIST CSF 2.0GV.RM-1SoD risk should be governed as part of enterprise risk management.

Document SoD risk acceptance, remediation ownership, and evidence retention in governance records.


Key terms

  • Segregation of Duties: Segregation of Duties is the practice of preventing one identity from holding incompatible permissions that could let a single person or system complete a sensitive process alone. In identity governance, the control is only effective when it is evaluated across applications, workflows, and lifecycle changes, not within one system in isolation.
  • SoD Conflict: An SoD conflict is a risky combination of entitlements that lets one identity perform actions that should be separated for control, fraud, or compliance reasons. The conflict may be invisible inside a single application and only appear when permissions are combined across systems or reused through delegated access.
  • Audit Trail: An audit trail is the retained record of access decisions, reviews, remediation steps, and approvals that proves a control operated as intended. For SoD, the trail needs to show both the conflict and the response, because auditors judge control effectiveness by evidence, not by policy statements.
  • Cross-application SoD Drift: Cross-application SoD drift is the gradual erosion of separation-of-duties controls as access changes accumulate across multiple systems without a fresh conflict check. It is a governance failure mode, not a one-time exception, and it becomes more likely when identity management is fragmented across business applications.

Deepen your knowledge

Segregation of duties across ERP, business applications, and non-human identities is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance around cross-application access and audit evidence, it is worth exploring.

This post draws on content published by Delinea: Top Segregation of Duties (SoD) solutions to know about in 2026. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-01-09.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org