Segregation of duties is becoming a continuous identity control

At a glance

What this is: This is SafePaaS's analysis of why segregation of duties is moving from point-in-time review to continuous identity control across ERP and business applications.

Why it matters: It matters because IAM, IGA, PAM, and NHI programmes now have to prove that conflicting access cannot be assembled and used across systems before finance activity completes.

Context

Under SOX, segregation of duties is not a reporting afterthought. It is a control design problem that must limit how far any one identity can move through financial processes such as procure-to-pay, order-to-cash, and record-to-report.

In complex ERP environments, the governance gap is that access now spans multiple applications, transaction paths, and sometimes non-human identities. That makes periodic review too slow to catch accumulated privilege before it is used in a high-risk financial workflow.

Key questions

Q: What breaks when SoD is only reviewed at provisioning time?

A: Point-in-time review misses conflicts that appear later through role drift, cross-application access, or automated transaction paths. In ERP and finance environments, that gap allows an identity to become conflicted after approval and still complete a high-risk process before anyone rechecks the entitlement set.

Q: Why do SoD conflicts matter more in complex ERP environments?

A: Because risk no longer sits inside one application. It emerges when access, workflow permissions, and transaction rights combine across systems, which is exactly how users and non-human identities can move from ordinary access to a financial control failure.

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.

Q: What should teams do when a SoD conflict cannot be removed immediately?

A: Use a documented mitigating control with a named owner, a defined frequency, and a clear link to the affected financial process. If those elements are missing, the exception exists without defensible governance and will be difficult to justify in SOX testing.

Technical breakdown

Pre-provisioning SoD simulation across ERP and business apps

Segregation of duties simulation checks whether a requested entitlement would create a conflict before access is granted. In complex estates, the control has to evaluate role combinations, inherited permissions, and cross-application business functions rather than rely on a single-role comparison. That matters because a user can be clean in one ERP and conflicted once downstream business apps and process-specific permissions are included. For SOX, the control objective is not only detection but prevention at the point of provisioning.

Practical implication: run SoD simulation before access is approved, not after the identity is already active.

Continuous monitoring of access changes and transaction activity

Continuous SoD monitoring links identity events to business activity instead of treating reviews as a periodic audit task. The model watches for access changes, transaction execution, and conflict creation across systems so that new risk is identified as soon as it appears. This is a stronger control pattern than static role design because identity risk accumulates after provisioning, not just at onboarding. In a SOX context, the question becomes whether the control can prove that no identity can complete a high-risk transaction path without interruption.

Practical implication: correlate provisioning events with transaction logs so SoD violations are visible in near real time.

Mitigating controls and evidence linkage for SOX auditors

When a SoD conflict cannot be removed immediately, organisations rely on mitigating controls with clear ownership and frequency. The important part is evidence linkage: auditors need to see how the conflict maps to the relevant financial process and what compensating control reduced the risk. Without that traceability, the control may exist on paper but fail in audit testing. SoD evidence therefore has to connect identity conflict, business process, and compensating control in one defensible record.

Practical implication: document compensating controls against the exact SOX process and keep the audit trail attached to the conflict.

Threat narrative

Attacker objective: The objective is to move through financial workflows in a way that enables manipulation of results or misuse of in-scope SOX processes without detection.

1. Entry begins when an identity already has access that spans multiple ERP or business applications and can reach a financial process path.
2. Escalation occurs when additional entitlements, inherited permissions, or cross-system combinations create a SoD conflict that was not visible in a single application view.
3. Impact follows when the identity can execute a high-risk transaction end-to-end without a preventive control or timely compensating review.

Breaches seen in the wild

• Zacks breach claim 2025: A hacker leaked 12 million Zacks accounts in 2025, claiming domain admin access in 2024; HIBP verified the data, Zacks has not confirmed.

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 static role-design exercise; it is a continuous identity control. The article makes clear that auditors now expect preventive enforcement, simulation, monitoring, and evidence linkage rather than point-in-time checks. That shifts the control from governance paperwork to runtime assurance, which means the operating model must be able to prove conflict-free execution across the actual business process, not just the access catalogue.

The real failure mode is accumulated access across systems, not a single bad role. In ERP-heavy environments, conflict often emerges only when entitlements are combined across applications and transaction paths. Cross-system SoD visibility: that is the named control problem here, because the risk sits in the intersection of identities, business apps, and process permissions. Practitioners should treat cross-application conflict detection as a core control design requirement, not an exception workflow.

Non-human identities belong inside the same SoD governance model. The article explicitly notes that NHIs can execute end-to-end business transactions, which means SoD assumptions built around named users are incomplete. This does not create a separate governance universe; it widens the blast radius of poor entitlement design. The implication is that SoD policy, evidence, and monitoring must cover service accounts and automated actors wherever they can touch financial processes.

Continuous SoD changes the auditor conversation from access review to control proof. Auditors are not just asking whether conflicts exist, but whether the organisation can demonstrate, continuously, that conflicts were prevented or mitigated in scope. That makes evidence capture and ownership as important as the rule library itself. Practitioners should align SoD operations to the financial assertion being protected, then prove the control works at transaction level.

What this signals

Continuous SoD becomes a control architecture problem, not a review cadence problem. Once identities can accumulate permissions across ERP, finance, and workflow systems, quarterly recertification cannot prove that a transaction path stayed clean. Practitioners need transaction-aware SoD controls that evaluate the state of access at the moment business activity occurs.

Cross-system conflict visibility is now the governance baseline. A role that looks safe in isolation can still create a SOX issue when combined with permissions in another platform. Identity programmes should therefore treat access paths, not just roles, as the object of control.

Mitigating control evidence must be attached to the business process. If the exception record does not show which financial process was affected and who owns the compensating control, the control may exist operationally but will be weak in audit scrutiny.

For practitioners

• Implement pre-provisioning SoD simulation Check requested access against the full ERP and business-app rule set before approval so conflicting combinations never reach production.
• Expand SoD scope across applications Map access conflicts across connected ERPs, finance tools, and workflow systems instead of assessing each role in isolation.
• Monitor access changes and transactions continuously Tie provisioning events to transaction activity so new conflicts are detected as soon as access changes are made.
• Document mitigating controls with audit evidence Record the owner, frequency, and financial process linkage for every compensating control used to cover an unresolved conflict.
• Include non-human identities in SoD governance Treat service accounts and automated process identities as subjects of the same conflict analysis when they can execute financial transactions.

Key takeaways

• SoD is evolving from periodic review into a continuous control that has to stop risky access before it is used in financial workflows.
• The article points auditors toward simulation, monitoring, and evidence linkage because conflicts now emerge across systems, not just inside one role model.
• Organisations that cannot connect access conflicts to compensating controls and transaction evidence will struggle to defend SOX control effectiveness.

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.
• Mitigating control: A mitigating control is a compensating safeguard used when risky access cannot be eliminated. It may be a reconciliation, approval workflow, detective report, or exception review. In practice, the control is only meaningful if a team can prove it executed for the relevant users and period.
• Continuous Controls Monitoring: Continuous controls monitoring is the ongoing evaluation of transactions, access, and configuration changes against policy rules. It replaces occasional sample testing with near-real-time detection, which gives security, audit, and finance teams faster evidence and a better chance to correct drift before it becomes a finding.
• Financial Assertion: A statement in financial reporting that a control is designed to protect, such as completeness, accuracy, or validity. SoD controls are often mapped to these assertions so auditors can judge whether the control meaningfully reduces reporting risk.

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 building or maturing an IAM programme, it is worth exploring.