Because S/4HANA shifts authorisation from transaction-code logic to layered controls that include Fiori services and CDS-based checks. An ECC ruleset can miss the actual access path, which leads to false negatives in SoD analysis and a misleading view of risk. Teams need to validate roles against the current platform, not the legacy model.
Why This Matters for Security Teams
ECC-era SAP roles are built around an older authorisation model that assumed transaction codes, stable job functions, and a narrower set of access paths. S/4HANA changes that reality. Security teams that keep using legacy role logic can miss service-based access, CDS-driven checks, and indirect execution paths, which weakens segregation of duties analysis and creates a false sense of control.
This is not just a technical migration issue. It affects audit evidence, risk acceptance, and business continuity because access can appear clean in a legacy report while the actual runtime path is not. Current guidance from the NIST Cybersecurity Framework 2.0 supports control validation against the environment in use, not the one that existed before the platform shift. The same logic applies in SAP modernization reviews, where the real question is whether the role still maps to how work is executed today. NHI Management Group has also highlighted how hidden access paths distort risk visibility in practice, including in the DeepSeek breach, where exposed credentials and unmanaged access surfaces compounded impact.
In practice, many security teams discover role drift only after an audit exception, a failed SoD review, or a business user reports that the “wrong” access still works.
How It Works in Practice
S/4HANA does not simply replace one set of transactions with another. It shifts authorisation logic into a layered model where access may be enforced through Fiori apps, OData services, backend authorisation objects, and CDS-based checks. A role that looked complete in ECC can therefore fail to represent the actual runtime access path. That is why legacy roles often produce false negatives in SoD testing: the ruleset is checking what used to matter, not what the platform now enforces.
Practical validation starts by mapping business activities to current execution paths. Security and GRC teams should test roles against the S/4HANA application layer, not just the old transaction catalog. Typical steps include:
- Identify which business functions now run through Fiori, APIs, or embedded analytics instead of classic GUI transactions.
- Review CDS-based authorisation checks and service-level controls where data exposure can differ from ECC.
- Rebuild critical roles from current process flows, then compare them to the legacy design to find unused, missing, or over-broad access.
- Retest SoD rules against the actual S/4HANA path, including indirect access and technical users where relevant.
This is especially important because older assumptions about “single transaction equals single risk” no longer hold. The The State of Secrets in AppSec research shows how control confidence can diverge from real operational practice, and the same pattern appears in SAP when teams trust a legacy matrix more than live authorisation behaviour. For implementation discipline, the NIST Cybersecurity Framework 2.0 reinforces the need to validate controls continuously rather than once during design. These controls tend to break down when organisations keep ECC roles unchanged through conversion, because the underlying access model has already changed.
Common Variations and Edge Cases
Tighter role reconstruction often increases migration effort, so organisations have to balance audit accuracy against delivery speed. That tradeoff is real in large SAP landscapes where custom developments, workflow extensions, and hybrid Fiori deployments make perfect role mapping expensive.
Best practice is evolving, and there is no universal standard for every S/4HANA scenario. Some environments can retain portions of ECC role design where the transaction is still valid, but that is an exception that should be proven, not assumed. Others need a near full redesign because service-based access and embedded analytics have replaced the old execution path. The biggest risk is treating “compatible” as “correct.”
Security teams should also watch for edge cases such as shared technical accounts, emergency access, and composite roles that span classic and modern interfaces. Those patterns can make a legacy rule set look compliant while still leaving excessive effective privilege in place. NHI Management Group’s analysis of the DeepSeek breach is a reminder that access risk often hides in the paths teams do not test first. In SAP, that hidden path is frequently the one auditors care about most.
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 and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Legacy roles miss current access paths, weakening least-privilege validation. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Stale authorisation models create hidden privilege and access drift risks. |
| NIST AI RMF | Role misalignment is a governance and measurement problem needing continuous review. |
Revalidate SAP access against live S/4HANA paths and remove entitlements that no longer match the process.
