SAP segregation of duties conflicts expose manufacturing control gaps

At a glance

What this is: This is OpenIAM’s analysis of five SAP segregation of duties conflicts in manufacturing, showing how legitimate role growth can create fraud paths when independent review is missing.

Why it matters: IAM and audit teams should treat SAP SoD as a governance control problem, because role accumulation and emergency access can create financial exposure long before an audit finds it.

Context

In SAP environments, segregation of duties is the control that stops one user from completing an entire financial transaction alone. The problem is not a missing feature in SAP so much as role accumulation over time, where promotions, temporary access, and emergency privileges create conflicting access combinations.

OpenIAM’s article frames this as a manufacturing governance issue because SOX ITGC testing, internal controls reviews, and COBIT-based access checks all look for the same role conflicts. Once the same person can create, approve, and pay, the control boundary has already failed.

The article is also explicit that SAP does not prevent these conflicts natively. That makes the IAM and IGA layer the real enforcement point, especially where manual reviews are too slow to catch day-to-day access drift.

Key questions

Q: What breaks when SAP users accumulate conflicting roles over time?

A: Segregation of duties breaks when users keep temporary, emergency, or legacy access that combines two sides of the same process. The result is not just excess privilege, but a path where one identity can create, approve, and execute a transaction without independent oversight. That is a governance failure, not a single bad grant.

Q: Why do SAP SoD conflicts create audit and fraud risk in manufacturing?

A: They let one person complete a financial control path alone, which can lead to fictitious supplier payment, bank redirection, self-approved journals, or self-released purchase orders. In manufacturing, those paths are especially dangerous because procurement and finance volumes are high, so the abuse can remain hidden until review or audit.

Q: How should teams detect SAP segregation of duties conflicts before audit season?

A: Use conflict rules that evaluate role combinations against the business process, not just whether each role is individually justified. Focus on pairings that collapse independent review, then verify the access is still needed and that a different approver owns the approval step. The goal is to prove process separation, not role ownership.

Q: What should security teams do when SAP exceptions keep reappearing?

A: Treat repeat exceptions as evidence that the control design is too permissive or the offboarding process is failing. Escalate the pattern, remove standing access where possible, and require a compensating control that is stronger than policy language alone. If the same conflict keeps returning, the review process is not closing the loop.

Technical breakdown

Why SAP role design creates SoD conflict accumulation

SAP grants access through roles that reflect job function, not process separation. That design works until users inherit temporary access, emergency access, or old role memberships that are never removed. The result is a permissions graph where each role looks defensible on its own, but the combination breaks the control objective. In practice, the risk is not a single toxic role but the overlap created across time as people move between duties. For manufacturing environments, that overlap often lands in finance, procurement, and production workflows where a second approver is supposed to exist.

Practical implication: review role combinations, not individual roles, when testing SAP SoD exposure.

How SAP payment and vendor conflicts enable direct fraud

The highest-risk SAP conflicts are those that let one person create the payment recipient and also release the payment. In the vendor master plus payment run pattern, the user can create a supplier record with a controlled bank account and then trigger the pay run. In the bank master plus bank transfer pattern, the user can redirect funds to a different account and immediately send the payment. These are not complex exploits. They are governance failures that convert ordinary business functions into a complete fraud chain because the approving control sits with the same identity that initiated the record change.

Practical implication: separate master-data maintenance from payment execution and require independent review of both.

Why self-approved journals and PO releases are control failures, not process shortcuts

Journal entry posting and purchase order release are meant to be independent checks on financial accuracy and spend authorization. When the same person can post and approve a journal entry, they can alter revenue, expenses, provisions, or intercompany balances without another reviewer. When the same person can create and release a purchase order, they can bypass budget control and self-authorize spend. In manufacturing, these conflicts are common because teams optimise for speed, but the shortcut removes the very control that proves legitimacy. The issue is structural, not procedural.

Practical implication: enforce system-level separation so the preparer cannot approve their own journals or purchase orders.

Threat narrative

Attacker objective: The objective is to complete a full financial transaction path without independent oversight, enabling fraud, misstatement, or unauthorized spend.

1. Entry begins with legitimate SAP access that has expanded through job changes, temporary coverage, or emergency privileges that were never revoked.
2. Credential or role abuse follows when a single user holds both record-creation and payment or approval authority inside the same business process.
3. Escalation occurs as the user turns that overlap into a complete transaction path, such as creating a supplier, changing bank details, posting journals, or releasing orders.
4. Impact is financial and audit-related, ranging from redirected payments and misstated ledgers to reportable deficiencies and re-testing findings.

Breaches seen in the wild

• SAP SQL Anywhere Monitor hard-coded credentials (CVE-2025-42890): Hard-coded credentials in SAP SQL Anywhere Monitor scored CVSS 10.0 (CVE-2025-42890); SAP removed the tool, and no exploitation was seen.
• SAP Kubernetes secrets exposure 2023: Kubernetes secrets committed to GitHub exposed 203 valid registry credentials, including SAP artifact repository access. SAP closed it after Aqua's report.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SoD in SAP is a lifecycle governance problem, not a software defect. The article shows that most conflicts emerge after the original access grant, when promotions, temporary coverage, and emergency access create cumulative privilege combinations. That means the control failure sits in joiner-mover-leaver discipline and periodic recertification, not in the initial provisioning event. The practitioner conclusion is simple: what matters is how access changes over time, not whether each individual grant looked reasonable when issued.

Emergency access that is never revoked becomes governance debt. OpenIAM’s analysis makes clear that the riskiest conflicts often start as legitimate exceptions and later harden into standing access. That is a classic segregation of duties failure mode because the exception outlives its justification and silently expands the user’s authority. The practitioner conclusion is to treat every temporary SAP exception as a time-bound liability that must be actively retired.

Access review alone does not solve SAP SoD if the review is not conflict-aware. The point of SoD is not simply to count roles, but to detect combinations that let one identity complete a financial process end to end. That is why role mining, entitlement review, and transaction mapping have to be joined together. The practitioner conclusion is that review evidence must prove process separation, not just access ownership.

Manufacturing exposes a specific control pattern: operational convenience overriding financial control. The article repeatedly shows that teams relax separation because a buyer, planner, or finance user seems to need faster throughput. That convenience creates the exact condition auditors test for, because the same user can now both initiate and finalise spend or accounting changes. The practitioner conclusion is that speed exceptions must never replace independent authorization.

Segregation of duties is the control that defines accountability in ERP finance. The core assumption is that no single individual should be able to create and complete a transaction path on their own. SAP’s role model does not enforce that assumption by itself, so the identity governance layer must. The practitioner conclusion is to treat SoD as a control architecture requirement, not an audit afterthought.

What this signals

SoD conflict drift: SAP access reviews need to move beyond role existence and into transaction-path analysis, because the risk appears when two otherwise valid permissions combine into one complete business process. Manufacturing teams should watch for users whose access changed repeatedly over time, especially where temporary coverage and emergency privileges were involved.

The control gap is usually not a missing policy but a missing enforcement point. If the same person can create a supplier, change bank details, post a journal, or release a purchase order, the business process itself is no longer independently verified. That is the point where IAM, IGA, and SAP workflow design have to be treated as one governance problem.

For practitioners

• Map SAP roles to transaction combinations Build a conflict matrix that links SAP transaction codes and authorization objects to the financial process they affect, then test for role combinations that complete the full path alone.
• Remove standing emergency access Revoke emergency and temporary SAP access once the business event ends, and require a time-bounded approval record for every exception that remains open.
• Separate master data from execution paths Ensure vendor master changes, bank detail changes, journal posting, purchase order creation, and payment execution are held by different named users or groups.
• Enforce system-based approval boundaries Configure SAP workflows so the same identity cannot post and approve journals, or create and release purchase orders, even when the team is small.
• Prepare SoD evidence for auditors Keep documented remediation tickets, dual-approval evidence, and review results ready for SOX ITGC, internal controls, and COBIT access testing.

Key takeaways

• SAP segregation of duties fails when role accumulation creates a single identity that can both initiate and complete a financial process.
• The article ties these conflicts to audit findings, reportable deficiencies, and fraud exposure in manufacturing environments.
• The practical fix is structural separation, with system-enforced approval boundaries and removal of standing exceptions.

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.
• Conflicting Roles: Conflicting roles are access combinations that look valid on their own but together allow one identity to bypass independent oversight. In SAP, they often emerge through promotions, temporary access, or emergency grants that are not removed after the original need ends.
• Compensating Control: A compensating control is a measure that reduces risk when the ideal fix, such as immediate patching or redesign, is not possible. In OT, compensating controls often include session recording, access restriction, and tighter monitoring. They do not eliminate the underlying issue, but they narrow exposure until safer remediation can happen.
• Role Accumulation: Role accumulation is the gradual build-up of access through promotions, temporary coverage, emergency grants, and historical permissions that were never removed. It is a lifecycle governance failure, not just a provisioning issue, because access remains valid after the original business need has changed.

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.