TL;DR: SAP segregation of duties helps manufacturing teams catch conflicting actions inside SAP, but OpenIAM argues that auditors test access control, identity lifecycle, and certification across SAP plus connected systems. The real gap is evidence: a conflict finding is only useful when reviewer decisions, remediation, and timestamps are all retrievable.
At a glance
What this is: This is an analysis of why SAP segregation of duties alone does not satisfy manufacturing compliance, and its key finding is that auditors test access and evidence across SAP plus connected systems.
Why it matters: It matters because IAM, IGA, and PAM teams in manufacturing must govern cross-system access, lifecycle events, and certification evidence, not just SAP roles.
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- Only 5.7% of organisations have full visibility into their service accounts.
👉 Read OpenIAM's analysis of why SAP SoD is not enough for manufacturing compliance
Context
SAP segregation of duties is a control for preventing one user from completing conflicting steps in a financially material process, but it does not equal manufacturing compliance. The article argues that auditors test access control, identity lifecycle, and certification evidence across SAP and every connected system that shapes procurement, payroll, reporting, and approvals.
For manufacturing identity governance, the important shift is from boundary thinking to evidence thinking. Once access decisions, review outcomes, and offboarding records live in different systems, a compliant-looking SAP control can still leave an audit gap if the reviewer cannot show what was decided, by whom, and when.
The same logic applies to service accounts and other non-human identities that support plant, payroll, and finance workflows. A governance programme that only checks SAP roles is operating inside a narrow slice of the real control surface.
Key questions
Q: What breaks when SAP SoD is only enforced inside one application?
A: Cross-system conflicts remain invisible. A user can be clean inside SAP while still holding directory, HR, contractor, or workflow access that creates the real risk. Manufacturing compliance fails when the control boundary is narrower than the business process boundary, because auditors test the full access path, not just the ERP rule set.
Q: Why do auditors care about evidence after an SoD conflict is found?
A: Because detection alone does not prove governance. Auditors want the reviewer, the decision, the outcome, and the timestamped remediation or accepted-risk record. If the organisation cannot produce that chain, it cannot prove that the conflict was handled in a controlled way.
Q: How should manufacturing teams govern access reviews across SAP and connected systems?
A: Use one certification model for the business process, not separate reviews for each application. Reviewers need context on what the role enables, which systems participate in the transaction, and whether the same identity has access elsewhere that changes the risk.
Q: What is the difference between SAP SoD detection and enterprise identity governance?
A: SAP SoD detection finds conflicting role combinations inside SAP. Enterprise identity governance connects SAP with directory, HR, contractor, and workflow systems so lifecycle changes, approvals, and evidence are governed across the full environment where the transaction actually happens.
Technical breakdown
Why SAP SoD only detects part of the risk
SAP SoD rules operate by comparing role combinations inside SAP against predefined conflicts, such as vendor creation plus payment execution. That works for conflicts that stay inside one application boundary. It does not natively see that the same person may also hold directory, HR, contractor-management, or workflow access that creates a composite conflict across systems. In practice, the control is only as broad as the rule set and connectors behind it, which is why cross-system manufacturing risk often remains invisible until auditors ask for a full access picture.
Practical implication: Extend SoD analysis beyond SAP-native rules to include connected systems that contribute to the same business process.
How identity lifecycle breaks audit scope
Lifecycle governance is the record of how access changes as a person or account joins, moves, and leaves. In manufacturing, that matters because a leaver can lose SAP access while retaining active directory, HR, or contractor-system access long enough to remain a risk. The audit issue is not just stale access. It is that the governance record stops at one system while the identity continues elsewhere, leaving the organisation unable to prove that access was actually removed everywhere it mattered.
Practical implication: Tie joiner, mover, and leaver workflows to every system that can influence financially material transactions.
What evidence auditors expect after a conflict is found
Auditors are not satisfied by a detected conflict alone. They want the access state, the SoD risk classification, the reviewer decision, the remediation or accepted-risk outcome, and the timestamped evidence trail that ties those steps together. That evidence must be retrievable later, not reconstructed from memory. In other words, the control is no longer just detection. It is detection plus decision plus proof.
Practical implication: Capture reviewer identity, decision outcome, compensating control, and remediation timestamp in one auditable record.
Threat narrative
Attacker objective: The objective is to use overlapping access paths to execute or conceal financially material actions without effective independent review.
- Entry occurs when a user or contractor receives conflicting access across SAP and connected systems, often through ad hoc provisioning or inherited roles. Escalation follows when that access spans more than one business function, creating a composite conflict no single-system SoD rule can see. Impact is an undetected ability to initiate and complete financially material transactions without independent oversight, which turns a governance gap into fraud or audit exposure.
Breaches seen in the wild
- Coupang Signing Key Breach — Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Manufacturing compliance is an identity governance problem, not a single-application control problem. SAP SoD is necessary, but auditors test the broader path by which access is granted, changed, and evidenced across SAP, directory services, HR systems, and approval workflows. A programme that stops at the SAP boundary can look controlled while still failing the actual audit question, which is whether the organisation can prove who had access, who reviewed it, and what changed after the finding.
Access evidence is now the control surface. The article gets this right: manufacturing does not have an access-data shortage, it has an access-evidence shortage. The real failure mode is fragmented proof, where detection, review, remediation, and acceptance live in different records that cannot be reconciled quickly under audit pressure. Practitioners should treat evidence integrity as part of the control itself, not as documentation after the fact.
Cross-system SoD is the named gap auditors increasingly exploit. A user can be clean inside SAP and still hold a material conflict through Active Directory, Entra ID, ServiceNow, HR, or contractor platforms. That is the governance blind spot because the conflict is distributed across systems, not absent. The practical conclusion is that manufacturing SoD programmes must be designed as enterprise governance models, not SAP-local rule engines.
Contractor and temporary identities are the hardest part of manufacturing SoD to govern. These identities often sit outside HR-driven lifecycle workflows and therefore outside the normal review cadence. When the identity source of truth is incomplete, recertification decisions become partial by design. The result is a governance perimeter that excludes the very access paths auditors are most likely to question.
NHI governance matters here because manufacturing environments increasingly rely on service accounts and other machine identities to move data between finance, plant, and workflow systems. Those identities often escape the same lifecycle scrutiny applied to human users, yet they can carry equally powerful approval or posting rights. The discipline must therefore extend beyond human SoD and into non-human lifecycle control.
From our research:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
- Follow the NHI Lifecycle Management Guide to connect lifecycle control with offboarding evidence and ownership.
What this signals
Manufacturing teams should read this as a warning that ERP-focused governance no longer defines the real control boundary. The operational question is whether access reviews, joiner-mover-leaver workflows, and compensating controls can be evidenced across every connected system that influences a financially material transaction.
Access evidence gap: the same problem that weakens SAP SoD also weakens NHI governance when service accounts, API keys, and other non-human identities are excluded from lifecycle review. With the Ultimate Guide to NHIs showing that only 20% of organisations have formal offboarding and revocation processes for API keys, the pattern is clearly broader than ERP compliance.
Boards and audit committees will continue to push for proof, not assertions. Teams that can trace access from request to certification to revocation across SAP, directory, and machine identities will be in a stronger position than teams that can only report on SoD flags inside one application.
For practitioners
- Expand SoD scope beyond SAP-native rules Map financially material workflows end to end, including SAP, Active Directory, Entra ID, HR, contractor platforms, and any approval system that participates in the transaction chain.
- Bind lifecycle events to every in-scope system Ensure joiner, mover, and leaver changes revoke or adjust access across all systems that can create or complete a conflicted transaction, not only the SAP role assignment.
- Capture evidence as part of the workflow Record who reviewed the conflict, what they decided, what compensating control was accepted, and when remediation occurred in a single retrievable record.
- Include contractor and temporary identities in recertification Fold plant contractors, seasonal staff, and third-party accounts into the same certification model used for employees so access outside HR does not remain invisible.
- Govern service accounts with the same rigor as users Inventory non-human accounts that post, approve, transfer, or reconcile data across manufacturing systems and make their ownership and offboarding explicit.
Key takeaways
- SAP SoD is necessary but insufficient because manufacturing auditors test access and evidence across SAP plus connected systems.
- The main failure mode is an access-evidence gap, where conflicts are found but reviewer decisions, remediation, and timestamps cannot be proved.
- Manufacturing teams need enterprise identity governance that spans human users, contractors, directories, and non-human identities.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorisations | Cross-system manufacturing access control maps directly to permission governance. |
| Recommendation — Map SAP and connected-system entitlements to PR.AC-4 and enforce least privilege across the full transaction path. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | SoD conflicts are a least-privilege failure when conflicting access is retained. |
| Recommendation — Apply AC-6 to remove conflicting permissions across ERP, directory, and workflow systems. | ||
| CIS Controls v8 | CIS-5 — Account Management | Identity lifecycle and contractor access are central to the article's audit gap. |
| Recommendation — Use CIS-5 to track account ownership, review cycles, and offboarding across every in-scope system. | ||
| ISO/IEC 27001:2022 | A.8.2 — Privileged Access Rights | Privileged access in SAP and adjacent systems is part of the governance problem. |
| Recommendation — Control privileged access rights across SAP, directory, and supporting platforms under A.8.2. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Improper Offboarding | Service accounts and machine identities can escape manufacturing lifecycle governance. |
| Recommendation — Inventory non-human identities and revoke access through explicit offboarding workflows. | ||
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 Governance: Identity lifecycle governance is the set of processes that create, change, review, rotate, and revoke access across human and non-human identities. It matters because access risk usually increases when lifecycle events are slow, incomplete, or disconnected from the systems that rely on them.
- 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 SAP-specific SoD conflict examples used in manufacturing audits and how they map to common financial control objectives.
- The five-step evidence chain auditors expect after a conflict is detected, including review, decision, remediation, and timestamps.
- The seven-step manufacturing governance model that extends beyond SAP into HR, directory, contractor, and service-account controls.
- The platform treatment of how SoD findings are documented and tracked across connected 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 or IGA programme, it is worth exploring.
Published by the NHIMG editorial team on September 11, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org