Segregation of duties is becoming a continuous identity control

At a glance

What this is: This is an analysis of why SOX segregation of duties now has to function as a continuous identity control across ERP and business applications.

Why it matters: It matters because IAM, IGA, PAM, and NHI programmes all need to prove that conflicting access cannot accumulate into a high-risk transaction path.

By the numbers:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read SafePaaS's guidance on continuous segregation of duties controls for SOX

Context

Segregation of duties, or SoD, is the identity control that prevents one user or workload from combining incompatible actions across a business process. In a SOX context, the issue is not only whether a role looks right on paper, but whether the access model and transaction path together can still protect financial reporting controls. The article argues that SoD has outgrown periodic review and now has to operate as a continuous control across provisioning, transactions, and evidence.

That shift matters because modern ERP and application estates distribute responsibility across more systems than traditional role design assumed. Once access, workflow, and transaction execution are separated across platforms, a conflict can exist even when no single role looks obviously unsafe. The practical identity problem is no longer just least privilege. It is proving that no identity, human or non-human, can assemble an end-to-end control failure inside the financial process.

Key questions

Q: How should security teams enforce segregation of duties before access is provisioned?

A: Teams should simulate requested access against cross-application SoD rules before provisioning completes, then block or reroute any request that creates an incompatible transaction path. The key is to evaluate the identity in the context of the financial process, not just the target application. That approach turns SoD from a review exercise into a preventive control.

Q: Why do static role models fail to control SoD risk in complex ERP environments?

A: Static role models fail because they assume conflicts are visible inside one role or one system, while modern access risk is often assembled across multiple applications and delegated workflows. A user can hold individually acceptable entitlements that still combine into a high-risk transaction path. SoD has to be evaluated as an identity and process problem, not a role-list problem.

Q: How do organisations know whether SoD controls are actually working?

A: Working SoD controls show up as blocked conflicts at provisioning time, monitored violations across applications, and clean audit evidence that connects access changes to financial processes. If conflicts are only discovered in periodic reviews, the control is reactive rather than preventive. Strong programmes measure both prevention and mitigation, not just policy existence.

Q: Who is accountable when SoD conflicts affect SOX controls?

A: Accountability should sit with the control owner for the business process, the identity governance team managing entitlement risk, and the application owner implementing the rule set. If a conflict cannot be prevented, the mitigating control must have named ownership, defined frequency, and an evidence trail. SOX auditors expect a clear line from conflict detection to accountable remediation.

Technical breakdown

How SoD rules map to financial statement assertions

SoD works by preventing one identity from holding access that could allow both initiation and approval, or other incompatible steps, within a financially relevant process. In SOX environments, rule design has to align with financial statement assertions such as completeness, accuracy, and authorization. A simple role conflict list is not enough, because auditors care about whether the conflict creates real control reliance risk. That means SoD rules must be risk-ranked against actual process paths like procure-to-pay, order-to-cash, and record-to-report.

Practical implication: build the rule library from financial process risk, not from generic role naming.

Why pre-provisioning simulation beats post-access review

Preventive SoD means checking for conflicts before access is granted, not after the identity has already accumulated risk. Simulation lets teams model the effect of a request across applications, transaction rights, and inherited access before provisioning completes. This is especially important in ERP estates where a role in one system may combine with access in another to create a hidden conflict. Point-in-time reviews miss those compound pathways, while continuous enforcement can stop them from ever becoming operational.

Practical implication: simulate SoD at provisioning time and block access changes that create cross-system conflict.

Cross-system SoD visibility in ERP and business apps

SoD fails when identity governance is fragmented across applications that each see only part of the access picture. Cross-system visibility is the ability to evaluate entitlements, business roles, and transaction permissions together so conflicts can be detected across ERP, finance, and connected SaaS tools. This becomes harder as organisations add automation, delegated admin, and non-human identities that can act faster than manual review cycles. Continuous monitoring and integrated evidence capture are the technical bridge between access control and audit proof.

Practical implication: connect entitlement, transaction, and audit evidence data into one SoD monitoring layer.

NHI Mgmt Group analysis

SoD has become an enterprise identity risk problem, not just an ERP control. The article is correct to move the discussion beyond isolated role conflicts. In complex environments, the real issue is accumulated access across systems that can assemble a control failure even when no single entitlement looks dangerous on its own. The implication is that SoD governance now belongs in the broader identity operating model, alongside lifecycle, privilege, and access certification.

Static role design was built for slower, more bounded access patterns. That assumption fails when access changes continuously across applications, business workflows, and non-human identities that can carry privilege between systems. The control problem is no longer whether a static role matrix exists, but whether the operating model can continuously prove that no identity can execute a high-risk transaction end to end. Practitioners must treat this as an assumption failure in the control design, not a minor tuning issue.

Continuous evidence is now part of the control itself. Auditors do not just need to see that a SoD rule exists. They need to see that prevention, monitoring, and mitigation are linked to actual financial processes and that violations create an auditable trail. This is where identity governance, transaction monitoring, and mitigating controls converge into one compliance story. The practitioner takeaway is that evidence collection can no longer be an afterthought.

Identity blast radius: the relevant design question is how far a single identity can move before a conflict is detected. That concept captures why cross-system access accumulation is more dangerous than a single bad entitlement. In SOX environments, the blast radius is defined by process reach, not just technical privilege count. The practical conclusion is that SoD programmes need to measure how much financial process a single identity can traverse before control intervention occurs.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• That is why lifecycle discipline belongs alongside SoD, as described in NHI Lifecycle Management Guide.

What this signals

Identity blast radius: SoD programmes will increasingly be judged by how far an identity can move across finance systems before a conflict is detected. When access, workflow, and transaction rights are split across applications, the control objective shifts from role hygiene to process containment. Teams that can correlate entitlement changes with transaction activity will be better placed to satisfy auditors and reduce hidden exposure.

The operational signal to watch is whether preventive checks happen before provisioning or only after access is already live. Continuous SoD enforcement is becoming the minimum viable control for ERP estates that depend on shared business roles and delegated administration. Organisations that still rely on periodic certification will keep discovering conflicts after the fact.

For identity teams, this is a reminder that SOX controls are now tightly coupled to broader identity governance. The same access sprawl that weakens recertification also makes cross-system SoD harder to prove. That means lifecycle, privilege, and evidence capture need to be managed as one control fabric rather than separate compliance tasks.

For practitioners

• Build SoD rules from financial process paths Map conflicts directly to procure-to-pay, order-to-cash, and record-to-report flows so each rule reflects a real financial reporting risk, not a generic role pattern.
• Simulate access before provisioning completes Test every requested entitlement against cross-application SoD rules before approval so you can stop conflicting access before it enters production.
• Join entitlement data to transaction evidence Correlate access changes, workflow rights, and transaction logs so auditors can trace the conflict from provisioning through business activity.
• Assign ownership to mitigating controls Document who owns each mitigation, how often it is reviewed, and what triggers its use when a conflict cannot be fully prevented.

Key takeaways

• SoD is no longer just a finance control inside ERP, because identity accumulation across systems can create the same business risk without any single role looking unsafe.
• The article’s strongest evidence is the shift from periodic checks to preventive simulation, continuous monitoring, and auditable mitigation across in-scope SOX processes.
• Practitioners should treat SoD as part of the wider identity operating model, with provisioning-time enforcement and process-linked evidence as the decisive controls.

Key terms

• Segregation of Duties: Segregation of duties is an access control principle that prevents one identity from combining incompatible actions within a business process. In practice, it reduces the chance that a single user or workload can create, approve, and conceal the same financial event.
• Control Reliance: Control reliance is the degree to which auditors and management depend on a control to prevent or detect material risk. For SoD, it means the control must be demonstrably linked to the process it protects, not just documented as a policy.
• Mitigating Control: A mitigating control is a compensating safeguard used when a full SoD conflict cannot be prevented. It must have clear ownership, defined frequency, and evidence that shows how it reduces the financial risk created by the conflict.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 governance maturity, it is worth exploring.

This post draws on content published by SafePaaS: Automating Segregation of Duties controls for SOX compliance. Read the original.