SAP SoD is not enough for manufacturing compliance

At a glance

What this is: This analysis explains why SAP SoD is necessary but insufficient for manufacturing compliance, because auditors evaluate identity governance and evidence across SAP plus connected systems.

Why it matters: IAM and IGA teams need to govern roles, lifecycle events, and certifications across the whole control plane, or they will keep producing audit gaps even when SAP conflicts are detected.

Context

Manufacturing compliance fails when SAP segregation of duties is treated as the full control surface instead of one part of a broader identity governance model. The problem is not only whether a conflict exists inside SAP, but whether the organisation can prove who reviewed it, what decision was made, and what happened next across every connected system.

In practice, auditors test access control, identity lifecycle, and access certification across SAP, directories, HR systems, and operational applications that process financially material transactions. That means the audit scope follows the business process and the evidence trail, not the boundary of a single ERP system.

Key questions

Q: What breaks when SAP SoD is used as the only manufacturing compliance control?

A: SAP SoD still finds conflicting roles inside SAP, but it breaks down when auditors test access across directories, HR systems, contractor platforms, and workflow tools. The programme then certifies only part of the actual risk surface, which leaves a traceability gap even when the SAP review itself looks complete.

Q: Why do manufacturing auditors care about evidence after a conflict is found?

A: Because a detected conflict is not a complete control outcome. Auditors want to see who reviewed it, what was decided, when remediation happened, and whether any accepted risk had a documented compensating control. Without that chain, the organisation can prove detection but not governance.

Q: What are the signs that an SoD programme is missing cross-system risk?

A: Common signs include clean SAP conflict reports alongside unresolved directory privileges, incomplete certification context, contractor access outside the HR feed, and remediation actions that are not timestamped or retrievable. Those symptoms show the governance model is limited to one system instead of the full identity path.

Q: Should organisations prioritise SAP SoD or identity lifecycle governance first?

A: They should treat them as linked, but identity lifecycle often exposes the deeper failure because access changes must flow through SAP and all connected systems. If joiner, mover, and leaver events are not governed end to end, SoD findings will recur and certifications will remain evidentially weak.

Technical breakdown

Why SAP SoD only covers one part of the control problem

SAP segregation of duties is a transactional control. It detects whether one user can perform conflicting steps in the same business process, such as creating a vendor and approving payment, or initiating a purchase order and confirming goods receipt. That matters because the risk is concentrated inside a single system boundary. But manufacturing environments rarely live inside one system. The real control question is whether the same identity can combine partial privileges across SAP, directories, HR platforms, and workflow systems to create a complete conflict outside SAP's native rule set.

Practical implication: treat SAP SoD as one detection layer, not the full compliance boundary.

How cross-system access creates blind spots in manufacturing governance

Cross-system conflicts emerge when access in one platform completes or amplifies access in another. A user may not look risky inside SAP alone, yet their Active Directory, Entra ID, HR, or ServiceNow privileges can combine to create the effective conflict auditors care about. This is where identity governance, not just application-level SoD, becomes the governing discipline. If the entitlement review only sees SAP roles, the organisation is certifying an incomplete picture. The control failure is structural, because the risk is distributed across systems that were never analysed together.

Practical implication: map financially material access across SAP and connected systems before certifying any role package.

Why access evidence is the real audit deliverable

The article's central point is that manufacturing does not have an access-data problem. It has an access-evidence problem. Detecting a conflict is only the first step. Auditors want to see the reviewer, the decision, the timestamp, the remediation action or accepted-risk justification, and proof that the outcome actually happened. Without that chain, the organisation can say it found the issue but cannot prove governance over it. In audit terms, the absence is not detection. It is traceability.

Practical implication: store review decisions, remediation, and timestamps as one retrievable evidence chain.

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

Manufacturing SoD is an access-evidence problem, not an SAP-only control problem. The article is right to separate conflict detection from audit readiness. Auditors care about whether the organisation can reconstruct identity decisions across SAP and connected systems, not whether a single module can flag a risky role pair. Practitioners should therefore treat evidence continuity as the control objective, not as a reporting afterthought.

Identity lifecycle governs the finding as much as the role model does. A leaver whose SAP access is removed but whose directory account remains active still creates a governance failure because the control boundary stopped before the identity was fully offboarded. That is an IGA problem, not just an SAP configuration issue. The implication is that lifecycle evidence must be tied to the systems auditors actually inspect.

Access certification only works when reviewers can see business context. A completed campaign that shows role names without the underlying conflict rationale produces weak assurance. Reviewers cannot make defensible decisions if the certification workflow hides the transaction context, the connected-system access, or the remediation history. Practitioners need certification design that preserves decision quality, not just campaign completion rates.

The audit scope now follows the transaction chain, not the ERP boundary. Manufacturing governance increasingly spans SAP, directories, HR systems, contractor platforms, and plant-level applications because financially material risk is distributed across them. That makes point-in-time SAP SoD checks insufficient as a programme design assumption. Teams should model compliance around the full control path, from access request to reviewer decision to enforced change.

Connected-system governance is now the named concept that matters here. SAP SoD can surface conflicts inside one application, but connected-system governance determines whether those conflicts remain visible once access crosses into directories, workflow tools, and source systems. That shift changes how practitioners scope audits, define certification evidence, and defend control effectiveness. The practical conclusion is simple: audit scope must follow the identity path, not the application name.

What this signals

Connected-system governance: manufacturing compliance now depends on how access moves across SAP, directories, HR platforms, contractor systems, and workflow tools. If certification only sees one application, the organisation is governing the label on the role, not the effective transaction path. That shifts programme design from isolated SoD checks to end-to-end identity governance.

Review evidence has become part of the control itself, not just the audit trail around it. When reviewers cannot see the conflict rationale, the certification context, and the remediation status in one place, completion metrics become misleading. Practitioners should expect auditors to challenge evidence quality even when the access review formally closed.

For teams modernising governance, the practical signal is that ERP-centric controls are no longer enough on their own. The scope now extends to lifecycle events, privileged directory access, and third-party identities that sit outside the SAP boundary. Identity governance and access certification need to be designed as a connected system problem.

For practitioners

• Expand SoD rules beyond SAP Build conflict rules that include directory, HR, contractor, and workflow entitlements so a risky access combination is visible before it becomes an audit exception.
• Link certification records to review evidence Require each access review to store the reviewer, decision, timestamp, remediation status, and any accepted-risk justification in one retrievable record.
• Model lifecycle events across connected systems Verify that joiner, mover, and leaver changes reach SAP, Active Directory, Entra ID, and any plant or contractor systems that carry financially material access.
• Govern contractor and temporary identities explicitly Track project-based, seasonal, and third-party access outside the core HR feed so these identities are not omitted from SoD and certification scope.

Key takeaways

• SAP SoD is useful, but manufacturing compliance fails when the control stops at one application boundary.
• The audit challenge is evidential as much as technical, because reviewers must prove what happened after a conflict was found.
• A complete programme ties lifecycle changes, certification decisions, and remediation records together across every system in scope.

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.
• Access Certification: Access certification is the periodic review of whether an identity still needs its current entitlements. For NHIs, certification is only reliable when reviewers know the identity's owner, purpose, and expiry, otherwise stale machine access can persist long after the original use case has ended.
• Identity Lifecycle Event: A business event that changes a person’s access, obligations, or record status, such as hiring, role change, or offboarding. In HR programmes, these events often drive entitlement changes and evidence requirements, so they need to be governed as part of the identity lifecycle rather than handled as isolated paperwork.
• Connected-System Governance: Connected-system governance is the discipline of managing identity risk across multiple linked applications rather than inside one platform. It matters when a conflict or entitlement becomes material only after access crosses SAP into directories, HR, or other operational systems.

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 building or maturing an IAM programme, it is worth exploring.