Notifications
Clear all
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.
NHIMG editorial — based on content published by SafePaaS: SAP authorization design for S/4HANA, non-human identities, and AI assistants
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
Questions worth separating out
Q: How should security teams govern SAP non-human identities in S/4HANA?
A: Treat SAP service accounts, API users, and Communication Arrangements as first-class identities in SoD analysis.
Q: Why do ECC-era SAP roles fail in S/4HANA environments?
A: Because S/4HANA shifts authorisation from transaction-code logic to layered controls that include Fiori services and CDS-based checks.
Q: What breaks when AI assistants can execute SAP workflows at speed?
A: The assumption that conflicting duties are hard to complete collapses when an assistant can move across functions almost instantly.
Practitioner guidance
- Rebuild SAP SoD rulesets for S/4HANA access paths Map roles against Fiori app layers, OData services, CDS-based checks, and business authorisations instead of reusing ECC transaction-code matrices.
- Extend SoD governance to communication users and API arrangements Include Communication User, Communication System, and Communication Arrangement objects in access reviews, conflict analysis, and audit evidence collection.
- Test AI-assisted execution against existing mitigating controls Review whether controls that relied on manual effort, workflow friction, or execution delay still hold when an assistant can complete both sides of a conflict quickly.
What's in the full article
SafePaaS's full article covers the operational detail this post intentionally leaves for the source:
- Practical SAP role design patterns for Fiori, CDS, and Clean Core constraints
- Detailed examples of SoD conflicts across S/4HANA, Ariba, Concur, and SuccessFactors
- Migration considerations for SAP GRC for HANA 2026 and SAP IDM retirement
- Platform-specific guidance for building and reviewing Communication Arrangements
👉 Read SafePaaS's analysis of SAP authorization changes in S/4HANA →
SAP authorization in S/4HANA: are your controls keeping up?
Explore further
25/06/2026 7:18 am
SAP authorization has become a multi-actor governance problem, not a transaction-control problem. The article shows that S/4HANA, non-human identities, and AI-assisted execution all sit inside the same authorisation fabric. That means the old assumption that a single role model can describe risk is no longer sufficient, because access can now be activated through services, APIs, and assistant-driven workflows. Practitioners need to treat SAP as a cross-identity control surface, not a set of isolated user roles.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means most SAP programmes cannot claim complete machine-identity oversight.
A question worth separating out:
Q: Who is accountable for SoD risk when SAP access spans humans and machine identities?
A: The owning control function is still accountable, but it has to govern every identity type that can carry the risk. If human users are reviewed while service accounts and communication users are ignored, the programme is only partially accountable. The right model ties responsibility to the business process, not just the named person.
👉 Read our full editorial: SAP authorization in S/4HANA now spans NHI and AI risk
