Legacy role models often mirror old transaction structures and do not fit newer interfaces such as Fiori. As a result, teams overgrant access, miss unused privileges, and struggle to prove that users only have what they need. In migration programmes, that mismatch increases operational friction, audit findings, and the chance of role sprawl.
Why Legacy SAP Role Models Become a Risk in Modern ERP
Legacy SAP role design was built for a different access surface: transaction codes, batch jobs, and tightly scoped on-premise workflows. Modern ERP landscapes add Fiori apps, APIs, integrations, and cross-system automation, but old role models rarely evolve at the same pace. That gap drives overassignment, hides unused entitlements, and makes it difficult to show that access is still justified under current business processes.
The risk is not just audit friction. When roles continue to mirror outdated transaction structures, teams often preserve access “just in case,” which erodes least privilege and increases segregation-of-duties exposure. Current guidance from the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both reinforce the same operational lesson: access models must match current execution paths, not inherited ones. NHI Mgmt Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is the same pattern seen when ERP roles are left to accumulate unused rights.
In practice, many security teams discover the mismatch only after a migration, audit finding, or production incident reveals how much dormant access was still active.
How It Works in Practice
Modern ERP environments usually fail when role engineering is treated as a one-time migration task instead of an ongoing governance process. The first issue is structural: older roles often bundle many transactions into broad composites, while Fiori and API-based access demand finer-grained, task-based controls. The second issue is operational: business teams approve access based on familiar job titles rather than actual work performed, so roles become a snapshot of past processes rather than present need.
Practitioners usually need a mix of role redesign, privilege cleanup, and continuous validation. That often includes:
- mapping legacy transaction usage to current Fiori apps, API calls, and workflow steps;
- removing unused authorisations rather than cloning old profiles into new ones;
- testing SoD conflicts against current process flows, not historic org charts;
- reviewing privileged access separately from business user access;
- using evidence from logs and actual usage to support recertification.
This is where identity governance and NHI discipline overlap. SAP background jobs, interfaces, and service users should be treated as NHIs, with tightly controlled secrets, short-lived access where feasible, and clear ownership. The Ultimate Guide to NHIs — Key Challenges and Risks highlights how excessive privilege and poor rotation drive exposure, and that same pattern appears when old SAP service accounts remain active long after the process they supported has changed. For control design, NIST SP 800-53 Rev. 5 is useful for linking access reviews, account management, and least privilege to concrete control expectations.
These controls tend to break down in heavily customised SAP landscapes because bespoke transactions, cloned roles, and parallel authorisation objects make usage analysis incomplete and slow.
Common Variations and Edge Cases
Tighter role engineering often increases migration effort and business disruption, so organisations must balance access reduction against operational continuity. That tradeoff is real in SAP, especially where global templates, country-specific legal controls, and heavily customised business add-ons all coexist.
One common edge case is dual-track access: a user may need narrow Fiori access for daily work but broader technical access during cutover or exception handling. Best practice is evolving here, and there is no universal standard for exactly how to model temporary elevation across every ERP programme. Another frequent complication is third-party support and integration accounts. These identities often sit outside traditional user-role reviews, yet they can still inherit broad privileges and long-lived secrets. NHIMG research warns that only 5.7% of organisations have full visibility into service accounts, which is a strong signal that hidden ERP access is usually worse than the visible user catalogue suggests.
Security teams should also watch for the false comfort of “clean” roles that still point to stale authorisations, inactive tcodes, or reused composites. Where SAP is integrated with identity governance tooling, recertification should focus on actual business process use, not just role membership. Where it is not, manual reviews tend to miss dormant privileges until the next audit cycle. In modern ERP estates, the safest assumption is that legacy access patterns are incomplete evidence, not proof of need.
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 AI RMF, NIST CSF 2.0 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-03 | Covers overprivileged non-human accounts common in SAP integrations. |
| CSA MAESTRO | G1 | Applies least-privilege governance to automated and machine-operated ERP access. |
| NIST AI RMF | GOVERN | Supports accountability for dynamic access decisions in complex ERP changes. |
| NIST CSF 2.0 | PR.AC-4 | Addresses access permissions and least-privilege control in ERP identity governance. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero trust reinforces continuous verification for ERP users and service accounts. |
Inventory SAP service identities and remove excess access, then rotate and reissue secrets on a strict schedule.
Related resources from NHI Mgmt Group
- Why does SAP cloud migration create new access governance risk for enterprises with legacy ERP estates?
- Why does manual user access provisioning create control risk in cloud and mobile ERP environments?
- Why do non-human identities create audit risk in modern environments?
- Why do non-employee identities create more access risk in healthcare environments than many teams expect?
