Topic starter
24/06/2026 10:34 pm
TL;DR: SAP authorization in S/4HANA now spans layered Fiori access, CDS-based checks, Communication Arrangements, non-human identities, and AI-assisted execution, according to SafePaaS. Legacy ECC role models and SoD rules no longer map cleanly to the current control surface, and the real governance gap is continuous proof that no identity can complete a high-risk business action end to end.
Editorial analysis by NHI Mgmt Group, based on content published by SafePaaS: “SAP Authorisation Best Practices: Avoiding Segregation of Duties Conflicts”.
Key questions
Q: What breaks when ECC-era SAP SoD rules are used in S/4HANA?
A: ECC-era rules break because they model transactions and old authorization objects, while S/4HANA adds Fiori start authorizations, CDS-based checks, and API access paths.
Q: Why do service accounts create SoD risk in SAP environments?
A: Service accounts create SoD risk when they can combine duties that should stay separate, such as master data change and payment-related actions.
Q: What are the signs that SAP access governance is failing?
A: Common warning signs include delayed offboarding, role changes that leave old permissions in place, inconsistent policy enforcement, unresolved SoD conflicts, and manual review processes that cannot keep up with the environment.
Practitioner guidance
- Rebuild SAP SoD rulesets for S/4HANA Map legacy ECC transaction-based conflicts to the current layered model, including Fiori start authorizations, CDS checks, and business authorizations.
- Bring non-human identities into SoD governance Include Communication Users, service accounts, and API-level access in the same conflict analysis used for human users.
- Test AI-assisted workflows for hidden duty conflicts Simulate Joule-enabled execution for the most sensitive SAP processes and check whether speed, orchestration, or reduced user friction lets one identity execute both sides of a conflict.
Bottom line: S/4HANA authorization now spans layered app access, CDS checks, API arrangements, and AI-assisted execution, so ECC-era SoD models are no longer enough on their own.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 7:18 am
Legacy SAP SoD models are no longer authoritative for S/4HANA. ECC-era rulesets were built for a simpler authorization surface where transaction codes, not layered app and data checks, carried most of the control burden. In S/4HANA, Fiori start authorizations, CDS-based checks, and API access through Communication Arrangements change what constitutes effective privilege. Practitioners should treat older SoD logic as a historical baseline, not a current control model.
A few things that frame the scale:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should teams govern AI-assisted execution in SAP SoD programs?
A: Treat AI-assisted execution as a privilege amplifier, not a separate access model. If Joule inherits the user's authorization, then SoD logic must evaluate what the user can complete at machine speed, not just what they could do manually. Mitigations that assume friction or delay should be retested against the AI-enabled path.
👉 Read our full editorial: SAP authorization in S/4HANA now spans NHI and AI risk