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.
Why Cross-System Access Reviews Need One Business-Process View
Access reviews around SAP rarely fail because reviewers lack a list of entitlements. They fail because the certification boundary is too narrow. If a manufacturing approver only sees SAP access in isolation, the review misses whether that same identity can trigger the transaction in a MES, workflow tool, or downstream integration, which changes the real business risk. A process-level view is what makes recertification meaningful.
That is why governance should follow the business transaction, not the application catalogue. The reviewer needs to know what the role enables, which systems participate in the process, and whether privileged pathways elsewhere can amplify the impact of a single approval. The most useful review item is often not "does this user still need SAP role X?" but "does this user still need the ability to complete this manufacturing action across the connected stack?" For broader identity governance context, NIST Cybersecurity Framework 2.0 remains a useful anchor for governance, access control, and oversight. In practice, many teams discover excessive access only after a cross-system transaction has already been over-privileged for months.
How Access Review Works in Connected Manufacturing Environments
Effective review design starts by mapping business roles to process outcomes, then tying those outcomes back to the systems that can execute, approve, or alter them. In SAP-led manufacturing environments, that usually means joining ERP roles with MES, maintenance, quality, identity, integration, and automation components before the certification cycle begins. Reviewers should see a single package that explains the workflow, the systems involved, and the effective reach of the identity across the transaction chain.
The operational test is whether the reviewer can answer three questions without leaving the page:
- What production or supply-chain action does this access enable?
- Which connected systems can be used to reach the same outcome?
- Does any additional access elsewhere increase the blast radius if this identity is misused?
This model is especially important when SAP permissions are paired with API access, integration credentials, shared technical users, or delegated approvals in adjacent systems. A reviewer who sees only the SAP role may approve access that is harmless in isolation but risky when combined with a maintenance console, a scheduling tool, or a data interface that can influence the same process. Controls for identity governance and periodic access review are also well covered in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where access recertification, least privilege, and system accountability need to be operationalised.
Manufacturing teams should also remember that connected-system reviews are only as good as the underlying entitlement inventory. If role data, application mappings, or third-party connections are stale, the certification becomes a paperwork exercise instead of a control. These controls tend to break down when roles are replicated across plants or business units faster than the review model is updated, because reviewers lose sight of which access paths are still active.
Common Variations and Edge Cases
Tighter certification models often increase review effort, so organisations have to balance completeness against reviewer fatigue and cycle time.
One common variation is the shared-service or plant-wide role. These roles may be valid for multiple lines or sites, but that does not mean they should be certified generically. The review should still show which plant, line, or business process the access supports, because a role that is acceptable in one site may be excessive in another with different segregation-of-duties requirements. Another edge case is emergency or break-glass access, which should usually be reviewed on a separate cadence because its purpose, approval path, and time bound are materially different from standard business access.
Connected automation creates a further nuance. Where a human identity can act through a workflow that also invokes technical accounts or interfaces, the review needs to reflect the full chain of authority, not just the human-facing ticket or SAP role. Current guidance suggests treating that chain as a single governance object when the same decision can cause the same business action. The practical rule is simple: if two access paths can complete the same manufacturing transaction, reviewers should assess them together, even if different teams own the systems. Ultimate Guide to NHIs is useful here for understanding how cross-system access, lifecycle control, and visibility gaps compound when technical access is left outside the certification model.
For manufacturing teams, the real edge case is not complexity itself, it is fragmented ownership. When SAP, OT-adjacent platforms, and integration teams certify access on different calendars, the resulting approvals may all be technically correct and still fail to govern the business process.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication and Access Control | Cross-system access reviews are an identity and access governance control. |
| GV.RM — Risk Management Strategy | Process-level recertification should reflect business risk, not isolated entitlements. | |
| DE.CM — Continuous Monitoring | Accurate reviews depend on visibility into active entitlements and connected-system activity. | |
| Recommendation — Map manufacturing access reviews to PR.AA and verify each identity's effective access across SAP and connected systems. Align certification scope to business-process risk and review combined access paths that change impact. Maintain current entitlement and integration visibility so reviewers can validate access against live system relationships. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Periodic review and validation of account access is central to access certification. |
| AC-6 — Least Privilege | Combined SAP and connected-system access must be limited to the minimum business need. | |
| AU-2 — Event Logging | Reviewers need evidence of what access actually enables and where it is used. | |
| Recommendation — Use AC-2 to enforce periodic recertification of accounts and remove outdated access promptly. Apply AC-6 to reduce excess access across SAP and adjacent systems to the minimum required. Log cross-system access events so certification decisions can be checked against real transaction usage. | ||
Practitioner Guidance
What to prioritise: Start by defining the certification unit as the business process, then list every system that can complete, approve, or alter that process. If reviewers cannot see the whole chain, the review is too narrow to trust.
What to verify: Verify that each certification item includes role meaning, downstream systems, and any parallel access that changes the risk. If a user can reach the same manufacturing outcome through more than one path, those paths should be visible in the same review decision.
Decision rule: If access is reusable across plants, lines, or integrated applications, treat it as higher-risk than a single-system entitlement and require stronger evidence for continued approval. If the role is emergency-only or time-bound, use a separate governance path rather than folding it into routine recertification.
Practitioner takeaway: The goal is not to certify every application separately, it is to certify whether the identity still deserves the business capability end to end.
Related resources from NHI Mgmt Group
- How should IAM teams govern access reviews across multiple systems?
- How should security teams automate user access reviews across SAP and connected applications?
- How should security teams run access reviews for non-human identities?
- How should security teams govern non-human identities that have persistent access?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
