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.
Where SAP SoD Stops Being Enough
SAP segregation of duties is useful when the control question is confined to SAP role design, SAP transactions, and SAP-native conflicts. It becomes incomplete when the compliance objective is broader than SAP, because manufacturing access decisions are often exercised through Segregation of Duties (SoD) Guide style rules but enforced across multiple systems, not one ERP instance.
That matters in manufacturing because a person or contractor can hold a clean SAP profile and still have effective access through directories, HR platforms, plant workflow tools, shared admin consoles, or vendor portals. If the review only certifies the SAP slice, the organisation may falsely conclude the whole access path is compliant when the real risk is distributed across connected systems.
The practical break point is traceability. A control that cannot connect the human, the account, the role, and the action across the full chain cannot prove that the same person who is segregated in SAP is also segregated in the supporting systems that actually move work forward.
Why the Compliance Assertion Becomes Incomplete
The first failure mode is scope mismatch. SAP SoD can identify conflicting combinations inside SAP, but manufacturing compliance often depends on whether access is consistent across identity directories, onboarding and offboarding records, timekeeping systems, contractor administration, and workflow automation. Once those sources are excluded, the control stops testing the true entitlement footprint.
The second failure mode is hidden privilege inheritance. A user may not hold an explicit toxic combination in SAP, yet still inherit effective power through group membership, delegated admin rights, shared service accounts, or workflow approvals. That is why access governance has to cover both role conflict and the paths by which access is granted or operationalised.
The third failure mode is evidence fragmentation. Auditors usually need a reproducible chain from request to approval to provisioning to current access. If SAP is the only system in scope, the programme can produce a neat report but not a complete compliance story, which weakens assurance even when the SAP review itself is technically correct.
For a broader segregation model, the SAP Kubernetes secrets exposure 2023 example is a reminder that risk often appears outside the primary application boundary, where the control owner was not looking.
How to Treat SAP SoD as One Control, Not the Control
A better manufacturing control design treats SAP SoD as one layer in a wider access-governance chain. The SAP review should be paired with identity inventory, contractor coverage, joiner-mover-leaver checks, and validation of the systems that grant, inherit, or execute access outside SAP.
That broader view is especially important where access is operationally distributed. Manufacturing environments often rely on HR feeds, plant scheduling tools, quality systems, badge-linked workflows, and temporary contractor access, so the real question is whether the same segregation principle holds across every place where authority is created or used.
The control objective is not to abandon SAP SoD, but to prove that SAP is the starting point of a traceable compliance chain rather than the endpoint. When that chain is intact, SAP findings become meaningful evidence; when it is broken, SAP only describes part of the exposure surface.
NIST SP 800-82 Rev 3 is useful here because manufacturing control environments depend on segmentation, boundary clarity, and disciplined control scope, even when the exact access problem sits in adjacent business systems.
Risk and Threat Considerations
When SAP SoD is treated as the only manufacturing compliance control, the organisation can miss the path an attacker or insider actually uses to gain operational influence. The control may look clean in SAP while the real abuse path flows through directories, contractor systems, or workflow approvals that were never tested for conflicts.
Failure mechanism: Scope reduction hides effective access outside SAP, so conflicting roles, delegated rights, or inherited permissions remain untested and can still be used to approve, alter, or execute sensitive manufacturing actions.
Impact: The programme certifies only part of the risk surface, which can leave segregation failures undiscovered, weaken audit defensibility, and create a false sense of compliance around production-related access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Manufacturing SoD depends on limiting effective access across systems. |
| AU-2 — Audit Events | Cross-system SoD needs auditable evidence of requests, approvals, and access use. | |
| IA-5 — Authenticator Management | Distributed access control depends on managed credentials beyond SAP roles. | |
| Recommendation — Enforce least privilege across SAP and connected systems. Log access decisions and privilege use across every system in scope. Manage credential lifecycle for users, contractors, and shared accounts. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access governance must span all systems that influence manufacturing compliance. |
| A.5.18 — Access rights | The question turns on whether access rights are reviewed beyond SAP. | |
| Recommendation — Define access rules that cover the full operational environment. Review and recertify access rights across SAP and adjacent platforms. | ||
Practitioner Guidance
What to verify: Confirm that every compliance assertion has a system-by-system evidence path, not just a SAP report. If the control cannot show how directories, HR, contractor, and workflow accounts are tied back to the same person or process, the assurance statement is incomplete.
Decision rule: If an access path can influence manufacturing work without touching SAP, it belongs in the SoD scope or in a documented compensating control. If it cannot be observed and reconciled, it should not be treated as cleared risk.
Practitioner takeaway: SAP SoD is a valid control, but only for the portion of access it can actually see; manufacturing compliance becomes credible when the control model follows the full identity and workflow path, not the ERP boundary.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org