SAP access conflicts in manufacturing expose weak SoD governance

At a glance

What this is: This is an analysis of the 10 most dangerous SAP segregation of duties conflicts in manufacturing and the control failures that let one user complete sensitive transactions alone.

Why it matters: It matters because IAM, IGA, and PAM teams must govern toxic SAP access across SAP and surrounding identity systems, not just inside a single application boundary.

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities , 46% confirmed, 26% suspected.

👉 Read OpenIAM's analysis of the 10 most dangerous SAP access conflicts in manufacturing

Context

In SAP manufacturing environments, the core governance problem is Segregation of Duties, where one identity should not be able to create, approve, and complete a sensitive transaction. When access spans finance, procurement, quality, payroll, or plant maintenance, the control failure is not theoretical. The primary keyword here is SAP access conflicts, and it describes where cross-functional permissions collapse the separation that audit and fraud controls depend on.

The article argues that the highest risk sits at the boundary between business processes rather than inside a single module. That matters for identity governance because role design, access review, and compensating controls must account for cross-system evidence, not just SAP-native visibility. Manufacturing teams that treat this as a module-level issue will keep missing the combined exposure that auditors and fraud investigators look for first.

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 SAP access conflicts in manufacturing need process-level review?

A: Because the risk is created by combinations across business processes, not by one permission in isolation. A user may look unremarkable in Finance or Procurement alone, yet become high risk when those entitlements are paired. Process-level review exposes the transactional path that module-level access checks miss.

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: Who is accountable when SAP SoD findings are not remediated?

A: Accountability sits with both the access governance function and the business owners who accept the process risk. If a conflict is only reported as a technical issue, remediation stalls. When it is mapped to a business process and tied to an approval or exception path, ownership becomes much harder to defer.

Technical breakdown

Why cross-functional SAP access conflicts are harder to detect

Segregation of Duties in SAP is not just about individual transactions. The risk emerges when a user can pair two functions that are harmless alone but dangerous together, such as creating a vendor and executing a payment run. Single-module reviews often miss these combinations because they do not map how authorization objects intersect across business processes. In manufacturing, that boundary problem is amplified by finance, procurement, quality, HR, and plant maintenance sharing the same operational backbone. The result is a control blind spot where the transaction path, not the module, defines the fraud opportunity.

Practical implication: Map toxic combinations across business processes, not only inside module-specific access reviews.

Why SAP role names hide SoD exposure

Role-level review is often too coarse because SAP risk sits in the underlying activities and authorization objects, not in the label on the role. A user may appear to hold ordinary access until two separate permissions are combined, at which point they can create and complete a transaction without independent check. That is why T-codes alone are insufficient. The control question is whether the entitlement set enables both setup and execution, or request and approval, within the same identity. In practice, effective governance depends on entitlement-level analysis and business-process mapping.

Practical implication: Review authorization objects and activity pairs, not just role names or visible T-codes.

Why evidence matters after an SAP SoD violation

Finding a conflict is only the first step. Audit-ready remediation requires a record of who identified the issue, who assessed it, what decision was made, and what control, if any, compensated for the risk. Spreadsheet checks often fail because they do not preserve the decision chain or show that the access was blocked before use. In manufacturing, where access often spans SAP and adjacent systems such as Active Directory, Entra ID, or HR platforms, the evidence problem extends beyond SAP itself. A defensible process must show both the conflict and the governance action taken across the full identity path.

Practical implication: Retain decision evidence for every conflict and extend the audit trail beyond SAP into surrounding identity systems.

Threat narrative

Attacker objective: To complete a financially or operationally sensitive transaction without an independent control stopping it.

1. entry: A user is granted a cross-functional SAP role combination that allows both setup and execution across separate business processes.
2. escalation: The same identity uses the combined access to create conditions for a sensitive transaction and then approve or complete it without independent oversight.
3. impact: The organisation records fraudulent, unauthorised, or noncompliant financial and operational activity that is difficult to detect in module-by-module reviews.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

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

NHI Mgmt Group analysis

Cross-functional SAP access is the real SoD failure mode: The most dangerous risk is not a single toxic permission, but an identity that spans two separate business processes. That combination collapses the control model because the same user can initiate and finish a transaction without another reviewer ever seeing the full path. Manufacturing environments should treat cross-process overlap as a governance defect, not a narrow role design issue.

Role labels obscure the actual control problem: SAP access reviews that stop at module or role naming will miss the entitlement pairs that matter. The dangerous pattern is held in the underlying activities, authorisation objects, and process boundaries, which is why SoD analysis must be mapped to business functions rather than technical convenience. The implication is that governance teams need a process-level view of access, not a catalogue of roles.

Evidence retention is part of the control, not an afterthought: In SoD governance, a remediation that is not documented is not defensible. The article is correct to frame the decision trail as part of the operating objective because auditors want to see the identified conflict, the reviewer, the rationale, and the final action. Without that chain, the organisation cannot prove that the risk was contained rather than merely observed.

Enterprise-wide identity governance is now the baseline for SAP risk: SAP-native controls cannot resolve exposure when compensating controls depend on Active Directory, Entra ID, HR, or plant systems. That is a structural governance issue, not just a tooling gap. The practical conclusion is that manufacturing programmes must govern SAP access in the context of the wider identity estate, or they will keep underestimating the true blast radius.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
• For a broader control model, NHI Lifecycle Management Guide shows how provisioning, rotation, and offboarding discipline changes when identity scope expands.

What this signals

Identity governance is moving from application-centric review to process-centric control. SAP manufacturing access cannot be safely governed by role names alone when one identity can span vendor setup, payment execution, quality release, or payroll. Teams that still separate SAP review from the surrounding identity estate will continue to understate their audit exposure.

SoD programmes now need evidence continuity across systems. A conflict that is detected in SAP but resolved in a spreadsheet outside the workflow does not create durable assurance. The governance signal is whether the access decision, remediation decision, and compensating control are all traceable in one chain from request to closure.

For practitioners

• Define toxic SAP process pairs Build the SoD catalogue around business-process combinations such as vendor creation plus payment execution, not around isolated T-codes or module ownership. Use process maps to identify where one identity can both set up and complete a transaction.
• Review authorisation objects, not just roles Validate conflicting access at the authorisation-object level so hidden combinations do not survive role-name review. Tie each high-risk pair to the business process it affects and the control owner responsible for it.
• Block dangerous requests before assignment Move toxic combination checks into the request approval path so access that would create a conflict is flagged or stopped before it becomes active. Reserve compensating controls for exceptions with documented risk acceptance.
• Extend SoD governance beyond SAP Include Active Directory, Entra ID, HR, ServiceNow, and plant systems in the evidence chain when compensating controls depend on them. If those systems are weakly governed, the SAP control is weaker than the audit record suggests.
• Retain a complete remediation trail Record who identified the conflict, who reviewed it, the decision made, the action taken, and the timestamp for each step. Keep that trail exportable so auditors can verify the full governance path.

Key takeaways

• The real SAP SoD risk in manufacturing is cross-functional access that lets one identity complete a transaction alone.
• Module-level reviews miss the dangerous combinations, which is why entitlement-level and process-level governance matter more than role labels.
• Auditable remediation requires a complete decision trail and governance that extends beyond SAP into the wider identity estate.

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.
• Toxic Access Combination: A toxic access combination is a set of permissions that becomes dangerous when granted together, even if each entitlement looks acceptable on its own. In identity governance, these combinations matter because they can enable misuse, separation-of-duties failures, or broader compromise.
• 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.

What's in the full article

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

• The 10 SAP conflict examples broken down by manufacturing process and transaction path.
• The remediation logic for split roles versus compensating controls when a conflict already exists.
• The evidence expectations auditors look for when a toxic combination is discovered.
• The broader governance argument for linking SAP decisions to adjacent identity systems.

👉 OpenIAM's full article covers the manufacturing examples, remediation approach, and audit evidence expectations.

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 governance maturity, it is worth exploring.