Segregation of duties at scale in ERP finance and access controls

At a glance

What this is: This is an analysis of why segregation of duties breaks down in ERP finance and access control environments, especially when identities can span vendor creation, payment, and approval paths.

Why it matters: It matters because IAM, PAM, and IGA teams need to govern conflicting entitlements across human and non-human identities before financial transaction authority becomes self-authorizing.

👉 Read SafePaaS's analysis of segregation of duties automation in ERP finance

Context

Segregation of duties is the rule that no single identity should be able to originate, approve, and complete a financially material transaction. In ERP environments, that control is meant to prevent one user or service account from holding conflicting permissions that create fraud, posting, or payment risk.

The governance gap appears when access is reviewed by role instead of by transaction path, because conflicts can span multiple applications and change over time. That makes SoD a lifecycle and access architecture problem, not just a finance policy issue.

Cross-system separation is especially hard when ERP, procurement, and payment platforms each see only part of the entitlement picture. The article reflects a common enterprise pattern: policies exist, but control visibility does not keep pace with entitlement growth.

Key questions

Q: What breaks when segregation of duties is only checked at the role level?

A: Role-level checks miss the way separate permissions combine into a harmful transaction path. An identity can appear compliant in each system while still being able to create vendors, approve payments, or post journals end to end. Effective SoD must evaluate the sequence of actions, not just the labels on access groups.

Q: Why do cross-application SoD conflicts create more risk than single-system conflicts?

A: Cross-application conflicts are harder to detect because each platform sees only part of the workflow. A user may create records in one system and approve or release them in another, which defeats isolated certification. The risk is larger because the full conflict only appears when entitlements are analysed together.

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

A: SoD is working when no identity can complete a financially material transaction chain without independent oversight, and when entitlement reviews catch conflicts before they reach production use. Evidence should show joined access analysis across systems, timely removal of exceptions, and no self-authorizing approval paths.

Q: Who is accountable when the same identity can request and approve access?

A: Accountability sits with the identity governance and control owners who allow request and approval to collapse into one path. In audited environments, that weakness can also trigger SOX exposure because it undermines logical access controls. The fix is separation of duties in both process design and system enforcement.

Technical breakdown

Role-level SoD checks miss transaction-level conflicts

Segregation of duties controls often look sound at the role layer because each individual entitlement appears reasonable in isolation. The failure emerges at the transaction layer, where a user can combine benign permissions into a complete financial workflow, such as creating a vendor and then approving payment. That is why SoD analysis must trace end-to-end process paths, not just static role membership. In practice, this is a control-mapping problem: the conflict lives in the workflow sequence, not the job title.

Practical implication: evaluate SoD at the transaction path level, not just against role definitions.

Cross-application SoD gaps in ERP and finance systems

Modern ERP estates rarely sit inside one platform. A person may create a vendor in one system, approve invoices in another, and reconcile results in a third, which means the toxic combination only appears when entitlements are correlated across applications. Traditional access review tooling often stops at the boundary of each system, so the conflict remains invisible. This is where lifecycle governance and access governance intersect: the issue is not only who has access, but whether any single identity can complete a financially material chain across SAP, Coupa, NetSuite, or similar platforms.

Practical implication: join entitlement data across finance, procurement, and ERP systems before certifying access.

Privilege creep turns temporary access into permanent financial power

SoD failures at scale are usually accumulation failures. Access is granted for a project, exception, or temporary duty, then never fully removed, leaving identities with latent combinations that were never intended to coexist. Over time, manual review cycles become too slow to catch the buildup, especially when approvals are distributed across teams. That creates a standing-risk pattern: the user does not need to break a control if the control drifted into an unsafe state on its own.

Practical implication: treat entitlement removal as part of SoD enforcement, not as a separate hygiene task.

Threat narrative

Attacker objective: The objective is to gain end-to-end control over financially material transactions without triggering independent approval or detection.

1. Entry occurs when a legitimate identity accumulates conflicting financial permissions through role expansion or cross-system access drift.
2. Escalation happens when that identity can combine vendor creation, payment approval, or journal posting privileges across ERP and finance workflows.
3. Impact follows when the identity can execute a full transaction chain without effective oversight, enabling fraud, unauthorized disbursement, or financial statement manipulation.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Zacks Investment Research breach — Zacks breach exposed 12M customer records including credentials.

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

NHI Mgmt Group analysis

Segregation of duties is failing at the transaction path, not the role definition. ERP governance often treats access as a static permission set, but the risk lives in the sequence of actions an identity can perform. When vendor creation, payment approval, and posting rights can be combined across workflows, the control has already failed before any transaction is executed. Practitioners should stop treating SoD as a role catalog exercise and start treating it as transaction-chain containment.

Cross-application conflicts are the modern SoD blind spot. SAP, Coupa, and other finance platforms frequently divide the control surface, which makes conflicting access hard to see in any single tool. That means SoD assurance requires identity correlation across systems, not isolated certification in each application. The implication is straightforward: if entitlements are not evaluated as a joined set, the enterprise is certifying partial truth.

Privilege creep is the mechanism that turns a temporary exception into standing financial risk. SoD failures rarely begin with malicious intent. They begin with accumulated access that outlives the business reason for granting it, especially in operations where duties shift frequently. The governance lesson is that SoD cannot be separated from lifecycle control, because revoked access is what keeps temporary exceptions from becoming permanent conflict.

Self-authorizing access is the named failure mode this article exposes. Access provisioning plus access approval creates a self-authorizing control loop, which was designed for separate reviewers and separate grantors. That assumption fails when the same identity can both request and approve its own financial access across systems. The implication is not merely to add more review, but to recognise that the approval model itself collapses when identity boundaries are not independent.

Financial control frameworks need identity correlation to remain credible. Segregation of duties is not only an ERP control, it is part of the logical access evidence base that auditors and risk teams rely on. When identities can move between systems without a unified conflict view, the assurance story weakens even if individual applications look compliant. Practitioners should therefore align SoD with broader IAM and IGA governance rather than leaving it inside finance operations.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• That lifecycle gap is explored further in NHI Lifecycle Management Guide, which helps practitioners connect control design to entitlement removal and rotation.

What this signals

Self-authorizing access is becoming the hardest SoD failure to defend against. When request and approval move through the same identity path, the control story breaks even if the workflow looks formal on paper. Practitioners should watch for this pattern in ERP and finance administration, where convenience often masks a collapsed control boundary.

Cross-application review is now the minimum viable SoD standard for any finance stack that spans ERP, procurement, and payment platforms. If teams only certify access inside one application at a time, they are not reviewing segregation of duties, they are reviewing fragments of it.

The next maturity step is to connect SoD evidence to lifecycle governance, especially where temporary access and project-based exceptions are common. The more frequently identities change roles, the more quickly standing conflicts can reappear unless removal is enforced as part of the access process.

For practitioners

• Map SoD at the transaction level Trace the full procure-to-pay, order-to-cash, and record-to-report paths so you can identify combinations that let one identity originate, approve, and complete the same financial flow.
• Correlate entitlements across systems Join access data from ERP, procurement, finance, and admin tools so cross-application conflicts such as vendor creation plus payment approval are visible in one review cycle.
• Remove access as part of SoD enforcement Treat offboarding and temporary access expiry as control actions, not hygiene tasks, so one-time exceptions do not become permanent financial authority.
• Separate request and approval authority Ensure no identity can both provision access and approve that same access across the finance stack, because self-approved entitlements undermine logical access controls.

Key takeaways

• Segregation of duties fails most often when separate permissions combine into a single end-to-end transaction path.
• The main evidence problem is cross-application visibility, because finance conflicts often span multiple systems rather than living inside one role model.
• Practitioners should tie SoD enforcement to entitlement lifecycle control so exceptions do not become standing financial authority.

Key terms

• Segregation Of Duties: A control principle that prevents one identity from completing all parts of a sensitive transaction. In ERP and finance environments, it stops the same person or account from creating, approving, and executing the same monetary action, reducing fraud and unauthorized change risk.
• Transaction Path: The full sequence of steps an identity can take to complete a business process, such as creating a vendor, approving a purchase order, and releasing payment. SoD must be assessed along this path, because conflicts often appear only when separate permissions are combined.
• Privilege Creep: The gradual accumulation of access beyond what was originally intended or justified. In SoD programmes, it is the main reason temporary exceptions become permanent control failures, especially when access is reviewed by role instead of by actual transaction capability.

Deepen your knowledge

NHI governance, identity lifecycle management, and secrets management 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 in your organisation, it is worth exploring.

This post draws on content published by SafePaaS: Segregation of duties and ERP financial control breakdowns. Read the original.