Segregation of duties tools in 2026: what changes for IAM

At a glance

What this is: This is Delinea’s 2026 roundup of SoD tools, arguing that segregation of duties now has to span multiple business applications and support ongoing governance, not just audit preparation.

Why it matters: IAM, IGA, and PAM teams need to treat SoD as an operating control across ERP and business apps because disconnected application silos leave risky access combinations in place.

Context

Segregation of duties is the control that prevents one identity from both creating and approving high-risk actions in the same system or workflow. In modern IAM programmes, that control breaks down when access is spread across ERP, finance, and business applications that do not share a common governance layer.

Delinea’s 2026 roundup frames the problem as one of control consistency, not just audit evidence. The practical issue for identity teams is that SoD has to follow access across applications, not stop at the boundaries of a single ERP estate.

Key questions

Q: What breaks when segregation of duties is the only control in place?

A: SoD blocks some toxic combinations, but it does not clean up stale, unused, or orphaned access. Users can change roles, projects can end, and temporary access can become permanent without any SoD alert. A programme built only on prevention still accumulates governance debt over time.

Q: When should organisations prioritise cross-application SoD over single-system controls?

A: They should prioritise it when core business workflows span multiple business applications and the same identity can request, approve, and execute steps in different systems. In those environments, the real risk is not one badly designed role, but an access pattern that only becomes visible when the applications are analysed together.

Q: What signs show that SoD governance is failing in practice?

A: Common signs include users who can both create and approve transactions, admins who review their own privileged activity, recurring access creep, and unresolved toxic entitlement combinations. If those patterns appear across ERP, cloud, or IAM systems, the control is probably being managed as a periodic review exercise rather than an enforced governance rule.

Q: How do security teams know if SoD controls are actually working?

A: SoD controls are working only if live access state matches the approved separation model across systems. Teams should verify that no identity can both initiate and validate the same sensitive transaction, and that exceptions are time-bound and independently reviewed. If certification reports look clean but operational workflows still allow self-approval, the control is failing.

Technical breakdown

Why single-system SoD breaks across ERP and business apps

Traditional segregation of duties controls are often designed around one core platform, where roles, transactions, and approvals can be analysed inside a single permission model. That approach becomes brittle when the same business process spans ERP, CRM, and finance applications, because the conflict exists across systems rather than inside one. Cross-application SoD requires a unified view of entitlements, workflows, and business activities so that risky combinations can be evaluated in context. Without that layer, organisations may satisfy local checks in one application while still allowing a toxic access pattern across the wider stack.

Practical implication: map SoD rules across the systems where a business process actually occurs, not only inside the core ERP.

How continuous access reviews and remediation support SoD

SoD only works if conflicts are found and resolved before they become normalised access. Continuous access reviews help surface policy violations, but review alone is not enough if the organisation cannot route findings into remediation workflows that remove or constrain the offending access. The article points to workflow-driven remediation as a key capability because governance depends on closing the loop between detection, approval, and enforcement. In practice, SoD is not a static policy library; it is an operational process that has to keep pace with role changes, business exceptions, and inherited access.

Practical implication: connect SoD detection to remediation workflows so conflicts do not survive multiple review cycles.

What defensible audit trails add to identity governance

Auditability matters because SoD disputes are rarely about whether an access path exists, but whether the organisation can prove how it was approved, monitored, and corrected. Defensible audit trails give compliance teams evidence that a control was actively enforced rather than assumed. That is especially important when external frameworks such as SOX, ISO 27001, or PCI DSS require repeatable control operation rather than one-time configuration. For identity governance teams, the real value is not the report itself but the ability to show that access decisions, risk exceptions, and remediation actions were tied together in a traceable chain.

Practical implication: retain evidence that links SoD findings, approvals, and fixes across the full access lifecycle.

NHI Mgmt Group analysis

Cross-application SoD is now the real control boundary: the old model assumed segregation could be enforced inside a single ERP. That assumption fails when finance, CRM, HR, and business workflows are split across separate applications with different permission models. The implication is that identity teams have to govern access combinations across the business process, not just within one platform.

SoD has become an operational discipline, not an audit artifact: the article is right to frame ongoing governance, because a rule set that only appears during audit prep is too late to reduce risk. Conflicts that survive day-to-day provisioning quickly become normal access, and manual review cycles cannot keep pace. Practitioners should treat SoD as a live control embedded in request, grant, and review workflows.

Defensible evidence is part of control effectiveness: audit trails are not just for inspectors, they are how organisations prove that conflicts were identified, adjudicated, and remediated. Without traceable evidence, SoD degrades into policy theatre, especially in hybrid application estates. This is where IAM, IGA, and PAM teams need a shared control story rather than disconnected reporting.

Application-specific SoD libraries still matter, but only as inputs: prebuilt rulesets reduce design effort, yet they do not replace governance over how those rules are applied across mixed ERP environments. The field is moving toward control orchestration, where the value is in consistent enforcement and exception handling. Practitioners should judge tools by their ability to sustain governance across systems, not by catalog size alone.

What this signals

Cross-application segregation of duties will matter more as organisations keep distributing business processes across ERP, finance, and SaaS platforms. The governance question is no longer whether a role is clean inside one system, but whether the full access chain creates a conflict anywhere the process is executed.

Control orchestration: SoD programmes now need to coordinate entitlement analysis, exception handling, and remediation across multiple applications. That is the point where identity governance stops being a reporting function and starts behaving like an operating control.

For IAM and IGA teams, the practical shift is toward process-level control design. If the business process is distributed, the SoD model has to be distributed too, or else the organisation is only auditing fragments of the risk.

For practitioners

• Define SoD at the business-process level Map conflicts around end-to-end business activities such as create, approve, post, and pay, then trace where those steps live across ERP and adjacent applications.
• Centralise access and risk visibility Build a single view of entitlements and SoD conflicts across the applications that support finance, procurement, HR, and customer operations.
• Tie findings to workflow remediation Route SoD violations into approval and remediation workflows so conflicts are removed, constrained, or explicitly risk-accepted with evidence.
• Preserve evidence for audit and review Keep traceable records of the rule, the conflict, the decision, and the fix so the control can be defended during SOX, ISO 27001, or PCI reviews.

Key takeaways

• Segregation of duties is increasingly a cross-application governance problem, not a single-system configuration task.
• The strongest SoD programmes tie detection to remediation and retain evidence that can stand up in audit and review.
• IAM teams should judge SoD tools by how well they govern access combinations across real business processes, not by how many rules they ship.

Key terms

• Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
• 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.
• Explainable Audit Trail: An explainable audit trail is a record that ties identity, action, context, and approval state into one reviewable sequence. It gives responders and auditors enough evidence to reconstruct what happened and why access was allowed. For agentic systems, the trail must survive machine-speed execution and chained decisions.
• Workflow-Driven Remediation: Workflow-driven remediation is an operating model that uses structured routing, ownership, and feedback loops to move vulnerabilities from discovery to closure. It replaces manual ticket chasing with repeatable processes across tools and teams. The approach improves accountability, SLA performance, and visibility into backlog and remediation outcomes.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.