SAP segregation of duties conflicts expose manufacturing control gaps

At a glance

What this is: This is an analysis of five high-risk SAP segregation of duties conflicts in manufacturing and the financial exposure they create.

Why it matters: It matters because IAM, IGA, and audit teams must stop treating SAP access as job-based only and start governing conflicting role combinations before they become fraud or compliance findings.

By the numbers:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read OpenIAM's analysis of the five most dangerous SAP SoD conflicts

Context

SAP does not stop segregation of duties violations on its own. It assigns access by role, which means the real control question is whether governance can detect dangerous role combinations before a user can create, approve, and settle a transaction without independent oversight.

In manufacturing environments, access accumulates through promotions, temporary coverage, project roles, and emergency access that is never removed. That same pattern appears in NHI programmes when service accounts and credentials persist after the original job, system, or control need has changed.

The primary issue here is not SAP configuration alone. It is identity governance discipline, because the same accumulation logic that creates human SoD conflicts also creates privilege creep in machine identities and other non-human access paths.

Key questions

Q: What breaks when SAP users can create and approve their own transactions?

A: Independent control breaks down. The user can complete an end-to-end financial action without a second person validating necessity, accuracy, or beneficiary details. In practice that can mean self-approved purchase orders, journal entries, or payments that look legitimate in the audit trail but bypass the control objective the workflow was meant to enforce.

Q: Why do SoD conflicts keep appearing even when access was originally justified?

A: Because role accumulation is normal in real organisations. Promotions, emergency access, project work, and temporary coverage often remain in place after the original need ends. The conflict is usually created by entitlement drift over time, not by a single bad provisioning decision, which is why ongoing review matters more than initial approval.

Q: How can IAM teams reduce SAP fraud risk without slowing operations?

A: By separating creation, approval, and execution into distinct identities and then applying risk-based compensating controls where teams are small. The goal is to preserve business throughput while preventing any one user from controlling both the setup and the release of value.

Q: Who should own SoD remediation when auditors find conflicts?

A: The business process owner should own the remediation, with IAM and security enforcing the access change. Audit can identify the issue, but finance, procurement, or plant leadership must decide whether to redesign the workflow, add countersignature controls, or remove conflicting access.

Technical breakdown

Why SAP role-based access creates SoD conflict risk

SAP grants access according to business function, not separation of duties. That model works for operational efficiency, but it breaks down when one person accumulates multiple roles over time. A user can hold individually legitimate permissions that become dangerous in combination, especially when temporary access, emergency access, or old job roles remain active. The key technical problem is that SAP itself does not reason about transaction combinations as a governance layer would. It sees authorised transactions, while SoD risk emerges only when an external rule engine evaluates role intersections and control objectives across the full access set.

Practical implication: enforce SoD rules in an IGA layer, not by relying on SAP role design alone.

How vendor master and payment access combine into payment fraud

The vendor-master-plus-payment-run conflict is the classic procure-to-pay abuse pattern. If a user can create or change supplier records and also execute payments, they can direct company funds to an account they control or influence. The technical weakness is not a single transaction code, but the absence of a second independent approval boundary between payee creation and disbursement. In well-governed environments, those actions are deliberately split so that no one actor can both define the recipient and release the money. Without that split, the fraud path is straightforward and difficult to detect until after settlement.

Practical implication: separate supplier maintenance from payment execution and require dual approval on payment runs.

Why purchase order and journal-entry self-approval defeats control design

Self-approval conflicts remove the independent review step that makes procurement and financial close trustworthy. In SAP, purchase order release and journal entry approval are meant to validate necessity, scope, and accounting correctness before commitment or posting. When the same user can prepare and approve, the system still records the control step, but the control has no independence. That creates an audit trail that looks complete while failing its real purpose. The architectural issue is not visibility, but lack of separation between origination and authorisation in the workflow itself.

Practical implication: make approval technically impossible for the same identity that created the transaction.

Threat narrative

Attacker objective: The objective is to complete or disguise a financial fraud path while making each individual action appear legitimate in isolation.

1. entry: A legitimate SAP user accumulates overlapping roles through promotion, project coverage, or emergency access that was never revoked.
2. escalation: The user combines vendor maintenance, bank master, purchase order, or journal-entry permissions into a conflict that bypasses independent oversight.
3. impact: The user can redirect payments, approve spend, or manipulate financial records before an audit detects the role combination.

Breaches seen in the wild

• Zacks Investment Research breach — Zacks breach exposed 12M customer records including credentials.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

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 fails first as an identity problem, not an audit problem. The post’s real lesson is that SAP role design creates a governance dependency on continuous entitlement review. Once emergency access, promotions, and temporary coverage accumulate, the conflict is already present even if no one intended abuse. Practitioners should treat SoD as lifecycle governance across human access, not a point-in-time audit exercise.

Standing access accumulation is the underlying failure mode in both SAP and NHI governance. The same logic that leaves a finance user holding incompatible SAP roles also leaves service accounts and API credentials over-privileged after the original need has passed. The result is privilege combinations that look individually defensible but become risky in aggregate. Practitioners should align SoD remediation with entitlement recertification and revocation discipline.

Identity blast radius is the right concept for manufacturing control design. If one identity can create a supplier, approve payment, and reverse an entry, the blast radius is already too large. That is why the control objective is not simply to reduce errors, but to prevent any single actor from completing a financially meaningful chain alone. Practitioners should map the maximum transaction path each role can complete without independent oversight.

Role-based access can satisfy job function while still failing governance. SAP is built to enable work, not to infer risk across role intersections. The assumption that role assignment equals safe access collapses once business users accumulate access across time and exception handling. Practitioners should rebuild approvals around independence, not convenience.

Manufacturing environments need SoD rules that reflect production and finance together. The post shows that financial abuse and operational manipulation can emerge from the same access model. In plants, BOM changes and production releases can create quality and compliance consequences as well as accounting exposure. Practitioners should govern production access with the same rigor as payment and ledger access.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• If you are building the control side of this problem, the NHI Lifecycle Management Guide is the right next step for provisioning, rotation, and offboarding discipline.

What this signals

Standing-access drift is the programme risk most teams underestimate. The SAP pattern here is the same governance failure that affects non-human access: permissions stay active because the original business need changed faster than the review cycle. If your entitlement reviews are still monthly or quarterly, you are already behind the pace at which role combinations can become unsafe.

Manufacturing IAM teams should watch for control gaps at the junction of workflow and identity, not just inside SAP. If a user can accumulate privilege across purchasing, treasury, or finance support roles, the control failure is lifecycle-related and must be handled through recertification, revocation, and exception expiry. The NHI Lifecycle Management Guide is useful here because the governance pattern is the same even when the actor changes.

Identity blast radius should become a reporting metric. In practice, that means tracking how many distinct financial outcomes a single identity can trigger without independent review. Once that number exceeds one, your programme is relying on trust in the user instead of trust in the control design. That is the point at which access governance stops being administrative and becomes risk management.

For practitioners

• Rebuild SAP SoD rules around transaction combinations Map the exact T-code pairings that create end-to-end fraud paths, then test those pairs across every role and derived role in the system.
• Separate supplier maintenance from payment execution Remove payment-run access from anyone who can create or change vendor masters, and require a named second approver before any disbursement file is generated.
• Enforce independent approval for purchase orders and journal entries Configure workflows so the preparer cannot release their own purchase order or approve their own journal entry, with the system blocking the combination rather than relying on policy.
• Review emergency and temporary access for revoked conflict risk Trace emergency access, project roles, and promotion leftovers to verify that conflicted permissions were removed after the business need ended, especially before audit testing.

Key takeaways

• SAP SoD conflicts are a lifecycle problem as much as an audit problem, because access drift creates dangerous role combinations over time.
• The manufacturing risk is material because a single user can sometimes create, approve, and execute financially meaningful actions without independent oversight.
• Effective remediation depends on separating duties in the workflow itself and removing conflicted access before audit season exposes it.

Key terms

• Segregation Of Duties: Segregation of duties is the practice of splitting a business process so no single identity can complete a full high-risk transaction alone. In SAP and other enterprise systems, it is enforced through role design, approval workflows, and conflict rules that prevent one user from both initiating and authorising the same value-moving action.
• SoD Conflict: A SoD conflict exists when one identity accumulates permissions that combine into an unsafe end-to-end capability, such as creating a supplier and approving payment. The conflict may be harmless in isolation, but together the permissions remove independent oversight and create fraud, error, or compliance exposure.
• 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.
• Identity Blast Radius: Identity blast radius is the amount of damage one identity can cause before another control intervenes. In a well-governed environment it is narrow, with each role limited to one part of a transaction chain. When it is wide, a single account can move funds, alter records, or approve its own actions.

What's in the full article

OpenIAM's full article covers the operational detail this post intentionally leaves for the source:

• Exact SAP transaction codes and authorization objects for each of the five SoD conflicts
• Plain-language fraud scenarios that map each conflict to a specific manufacturing control failure
• Remediation guidance for each conflict, including compensating controls for small teams
• The full manufacturing rule set across FI, MM, SD, PP, CO, QM, Basis, HR/Payroll, and Plant Maintenance

👉 OpenIAM's full post includes the specific T-codes, control objectives, and remediation guidance for each conflict.

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.