They are built around SAP authorisation constructs and transaction logic, so they work best when the process stays inside the ERP boundary. Once approvals, execution, and evidence move across different systems, the control model loses continuity and requires manual reconciliation.
Why This Matters for Security Teams
ERP-native governance tools are effective when the full workflow stays inside one suite, but multi-application business processes rarely do. A requisition may start in ERP, move through an ITSM or procurement platform, trigger a workflow engine, and finish with evidence in a separate repository. Once control points span systems, the ERP view becomes partial, and review teams lose a consistent chain of approval, execution, and audit evidence.
That gap matters because identity, authorisation, and evidence are not just configuration details. They are the control fabric that proves who approved what, who executed it, and whether the action matched policy. NHI Management Group’s Top 10 NHI Issues repeatedly shows that visibility and lifecycle gaps become operational risk as soon as credentials or approvals leave the original system boundary. Current guidance in the NIST Cybersecurity Framework 2.0 also emphasizes coordinated governance across assets and identities, not isolated control islands. In practice, many security teams discover the control gap only after an audit request or incident forces them to reconstruct a process that was never designed to be end-to-end.
How It Works in Practice
ERP-native governance usually depends on transaction codes, role mappings, workflow approvals, and logs that are meaningful inside the ERP. That model works when the control decision and the action occur in the same place. In multi-application environments, however, governance has to follow the business process rather than the application. The practical problem is not just access to ERP objects, but continuity of identity, approval state, and evidence across systems.
Teams typically need to separate three layers:
-
Authorisation: which role, entitlement, or delegated approval is valid at each step.
-
Execution: which system actually performed the action, and under what identity.
-
Evidence: where the immutable record is stored so review and audit teams can trace the full path.
That is why the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is relevant here: lifecycle control has to extend beyond a single platform and cover provisioning, rotation, revocation, and review across the process chain. Mature teams often complement ERP controls with external identity governance, workflow orchestration, and centralized logging so that evidence can be correlated even when the action is executed elsewhere. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful for this because auditors care less about which tool hosted the control and more about whether the control was complete, consistent, and reviewable.
In practice, this means mapping ERP roles to enterprise-wide business capabilities, synchronizing approvals with downstream systems, and preserving evidence outside the ERP boundary when a transaction changes state elsewhere. These controls tend to break down when downstream systems use local roles or API tokens without a shared approval record, because the ERP cannot reliably reconstruct what happened after the handoff.
Common Variations and Edge Cases
Tighter governance across multiple applications often increases integration overhead, requiring organisations to balance stronger control continuity against slower change management and more complex ownership. That tradeoff becomes more pronounced when business units run different SaaS tools, when regional ERPs differ, or when legacy interfaces expose only partial logs.
Current guidance suggests a few patterns, but there is no universal standard for this yet. Some organisations keep ERP as the system of record for approvals while using a separate governance layer for cross-application access reviews. Others treat the ERP as one evidence source among several and rely on SIEM or GRC tooling to assemble the audit trail. Both can work, but only if the handoff between systems is explicit and consistently logged.
Edge cases also include temporary vendors, robotic process automation, and service accounts that execute transactions without a human in the loop. Those identities can be easy to miss because the process appears “business owned” even though the execution is machine driven. In those environments, the right question is not whether ERP-native controls exist, but whether they can prove continuity once an approval or transaction leaves the ERP boundary. That becomes especially difficult when finance, procurement, and IT each maintain separate evidence standards or retention rules.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers lifecycle control for non-human identities across multiple systems. |
| NIST CSF 2.0 | PR.AC-4 | Addresses least-privilege access across distributed applications and approvals. |
| NIST AI RMF | GOVERN | Supports governance accountability when workflows span multiple systems and owners. |
| NIST Zero Trust (SP 800-207) | SA-3 | Relevant because cross-system trust should be evaluated per request, not assumed by boundary. |
| CSA MAESTRO | Applies to orchestrated agentic and workflow environments with distributed control points. |
Map ERP and downstream entitlements to PR.AC-4 and remove standalone app access that lacks business justification.
