SAP access conflicts in manufacturing expose weak SoD governance

At a glance

What this is: This analysis shows how SAP segregation of duties conflicts in manufacturing create fraud, compliance, and evidence gaps when one user can span setup and execution across business processes.

Why it matters: IAM, IGA, and PAM teams need to treat SAP SoD as an enterprise governance problem, because adjacent identity systems can weaken compensating controls even when SAP itself is reviewed.

Context

SAP segregation of duties is the control principle that prevents one person from both setting up and completing a sensitive transaction. In manufacturing SAP environments, the risk increases when access crosses business-process boundaries such as finance, procurement, HR, quality, and plant maintenance.

The core governance gap is not limited to detecting bad combinations inside SAP. The article argues that surrounding identity systems such as Active Directory, Microsoft Entra ID, ServiceNow, HR systems, and plant applications can undermine compensating controls if they are not governed as part of the same access model.

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 SoD conflicts create a broader governance risk than a single access finding?

A: Because the same access often depends on surrounding identity systems as well as SAP itself. If Active Directory, Entra ID, ServiceNow, HR, or plant applications are weakly governed, a compensating control can look sound in SAP while remaining fragile in practice. The risk is enterprise-wide accountability, not just a bad role in one application.

Q: What are the signs that SAP SoD reviews are missing the real conflict?

A: Common signs include role reviews that focus on module names, conflicts that only appear after an audit, and toxic combinations that span finance, procurement, HR, or Basis. If a review cannot explain the full transaction path and who approves each step, it is probably blind to the highest-risk exposure.

Q: How should manufacturers handle SAP SoD conflicts that depend on other identity systems?

A: They should treat the external identities and workflow systems as part of the control surface, not as separate exceptions. The decision trail must show who approved the access, what evidence supported the approval, and how any remediation was documented across the full identity chain. Otherwise, the compensating control is incomplete.

Technical breakdown

Cross-functional SAP role conflicts break the control boundary

SAP SoD conflicts become dangerous when a single user holds two functions that belong to different parts of a transaction lifecycle, such as vendor creation and payment execution. The risk is not the module itself but the transaction path that spans setup, approval, and completion. Because each role can look harmless in isolation, single-module reviews miss the combined exposure. In manufacturing, that boundary often sits between finance, procurement, production, quality, HR, and Basis administration, where the same user can initiate and finish a sensitive workflow without a second check.

Practical implication: Map roles to transaction paths across business processes, not just to modules, so cross-functional combinations are visible before access is approved.

Role-name reviews miss the underlying authorization objects

The article repeatedly shows that dangerous SAP access can be invisible if teams review only role names or transaction codes. In SAP, the effective permission is often determined by authorization objects and the way multiple functions combine, not by a simple label. That is why combinations like post goods receipt plus invoice verification or create user plus assign roles can be missed until a full SoD rule set is applied. The technical problem is aggregation: separate permissions merge into one effective ability to create, approve, or conceal an action.

Practical implication: Validate SAP access against authorization objects and toxic combinations, not against role titles or single T-codes.

Compensating controls fail when surrounding identity systems are weaker

A compensating control only works if the systems it depends on are governed with similar rigor. The article points out that SAP users also hold identities in Active Directory, Entra ID, ServiceNow, HR platforms, and plant systems, and those accounts can influence the same business process. If those adjacent systems allow weak approvals, stale access, or unmanaged exceptions, the control around the SAP conflict becomes fragile. In practice, SoD governance has to extend beyond the ERP boundary to preserve evidence and accountability end to end.

Practical implication: Treat adjacent identity systems as part of the SoD control surface when validating compensating controls and audit evidence.

Threat narrative

Attacker objective: The objective is to complete or conceal a sensitive transaction while bypassing independent oversight and leaving the organisation with weak audit evidence.

1. Entry occurs through ordinary SAP role assignment, where a user is granted two permissions that should remain separate.
2. Credential or account abuse follows when the user exercises both functions in sequence, such as creating a supplier and executing a payment or creating a user and assigning roles.
3. Escalation happens when the combined access lets the user initiate, approve, or conceal a financially or operationally sensitive transaction without a second reviewer.
4. Impact is fraud, falsified operational records, or audit findings that show the control structure failed at the boundary between setup and execution.

Breaches seen in the wild

• 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

Cross-functional SoD is the real manufacturing control problem: the dangerous failure mode is not excessive access inside a single module but a user holding both sides of a business process. That collapses the separation the control model depends on, especially where finance, procurement, HR, quality, and plant maintenance intersect. Practitioners should govern transaction paths, not just application silos.

Compensating controls are only as strong as the surrounding identity estate: SAP access does not exist in isolation, and that is why enterprise identity governance matters. If the user can also move through Active Directory, Entra ID, ServiceNow, or HR systems without equivalent rigor, the apparent control in SAP becomes conditional rather than real. The implication is that audit evidence must span the full identity chain, not the ERP alone.

Authority without separation is the named governance gap: one person with both request and approval authority can create a toxic combination that no detective review can safely unwind after the fact. This is a classic SoD failure because the control was designed for separate ownership, not dual-role concentration. Practitioners should treat dual authority as a governance defect, not a review finding.

Evidence retention is part of the control, not an administrative extra: the article is clear that a completed spreadsheet is not enough if the decision trail is missing. Auditors need who reviewed, what was decided, what changed, and when each step happened. That makes governed workflow and exportable audit evidence a core control requirement, not a reporting convenience.

Enterprise SoD governance is where SAP, IAM, and IGA converge: the article’s strongest point is that SAP-native review alone cannot close the gap when surrounding systems remain weakly governed. That means manufacturing teams need one identity model for request, approval, and remediation decisions across the estate. The practical conclusion is that SoD remediation must be enterprise-scoped, not SAP-scoped.

What this signals

Authority without separation is the failure mode that matters most here: manufacturing teams often assume the risk sits inside SAP, but the real control break is when one account can both request and complete a sensitive transaction. That matters because governance has to follow the transaction path, not the application boundary.

Enterprise SoD governance now depends on adjacent identity systems: compensating controls that rely on Active Directory, Entra ID, ServiceNow, or HR workflows can be undermined if those systems are not governed to the same standard. Practitioners should therefore evaluate access evidence across the full identity chain before relying on a remediation decision.

Role splitting remains the cleanest remediation when it is feasible: separating initiation from approval removes the dual-authority condition that makes these conflicts dangerous. When separation is not possible, the remaining control has to be explicit, documented, and auditable across the wider identity estate.

For practitioners

• Map toxic SAP combinations across business processes Review access by transaction path, not by individual module, so vendor creation, payment execution, purchasing, HR, quality, and Basis conflicts are evaluated together.
• Block access at request time Validate proposed roles before assignment and stop any request that would create a toxic combination unless a documented risk acceptance is approved.
• Split roles where dual authority exists Remove combinations that let one user both initiate and complete the same sensitive transaction, especially in vendor, payroll, production, and maintenance flows.
• Extend SoD evidence beyond SAP Require the approval trail, reviewer identity, remediation decision, and timestamps from adjacent systems such as Active Directory, Entra ID, ServiceNow, and HR.

Key takeaways

• Manufacturing SAP SoD conflicts are dangerous because they let one user hold both sides of a sensitive transaction across business processes.
• The article shows that the highest-risk exposures often hide at the boundary between SAP and surrounding identity systems, not inside one module alone.
• The practical response is to prevent toxic combinations before assignment, split roles where possible, and retain a full decision trail for audit evidence.

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.
• 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.
• Toxic Risk Combinations: Toxic risk combinations are unsafe interactions between datasets, access permissions, and AI workflows that only become problematic when combined. Individually they may appear harmless, but together they can expose sensitive information, enable re-identification, or create unintended inferences that traditional controls may miss.
• Identity evidence trail: The records that show how identities were created, granted access, reviewed, rotated, and removed. For NHI governance, this includes service accounts, tokens, certificates, and related audit logs that prove controls were enforced over time.

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.