SAP authorization in S/4HANA now spans NHI and AI risk

At a glance

What this is: This is an analysis of how SAP authorization design has changed in S/4HANA, with the key finding that legacy ECC-era controls no longer cover layered app access, non-human identities, and AI-assisted execution.

Why it matters: It matters because IAM, IGA, and PAM teams now have to govern SAP access as a cross-identity risk problem, not just a human role-design exercise.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.

👉 Read SafePaaS's analysis of SAP authorization changes in S/4HANA

Context

SAP authorization in S/4HANA is no longer a single role-mapping exercise. The control model now spans Fiori app layers, CDS-based checks, Communication Arrangements, and non-human identities such as service accounts and API users, which means old ECC assumptions about how access is granted and reviewed no longer hold.

That shift matters because segregation of duties in SAP has always depended on knowing who can initiate, approve, and complete a business process. Once API users, bots, and AI-assisted execution are part of the path, the governance question becomes whether the identity model can still prove separation across the full transaction chain.

For teams that still anchor their programme in transaction codes and legacy objects, the risk is not just weaker detection. It is a false sense of coverage while the actual access path has moved to layered services and cross-application workflows.

Key questions

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. The practical test is whether a non-human identity can initiate, modify, and complete a sensitive business process without human separation of duties. If it can, the control model is incomplete and the audit trail is too narrow.

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. 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.

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. Mitigating controls that depend on human delay or operational friction become weaker, because the risky combination can be executed before review or intervention happens. Governance has to account for speed, not just authority.

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.

Technical breakdown

Fiori-layered authorisation changes the control path

In S/4HANA, a Fiori app is not authorised by a single check. Access typically spans start authorisations for OData service data providers, start authorisations for model providers, and the business authorisation behind the underlying data. That layered model means a user can appear correctly provisioned at one layer while still being blocked or overexposed at another. It also makes legacy ECC rulesets unreliable because transaction-code logic does not capture service-level access. The S_SERVICE object becomes central, but it is only one part of the path.

Practical implication: validate SAP access at the service, model, and business layers before approving any role redesign.

CDS view authorisation replaces many ECC checks

S/4HANA shifts many access decisions from older authorisation objects to CDS view-based checks. That matters because the effective control point may move from a familiar ECC object to a new analytical or service-layer object that your SoD rules do not inspect. If role design still assumes old object names and old transaction paths, conflicts can disappear from reporting while remaining active in execution. The result is not just missed access, but missed accountability because the wrong entitlement model is being measured.

Practical implication: rebuild SoD rulesets around CDS-based access checks instead of reusing ECC matrices.

Communication Arrangements turn API access into an identity problem

In S/4HANA Cloud, API access is mediated through Communication User, Communication System, and Communication Arrangement. That is an identity construct, not just an integration setting, because the arrangement defines which scenarios the non-human identity can execute. If a communication user can both create vendors and trigger payments, the SoD risk is equivalent to a human user holding both rights. Traditional GRC programmes often miss this because they analyse only named human accounts.

Practical implication: bring Communication Arrangements and service users into the same SoD review cycle as human roles.

NHI Mgmt Group analysis

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.

Legacy ECC SoD logic fails because the control objects have changed underneath it. ECC-era transaction-code rules do not reliably map to Fiori-layered authorisation, CDS checks, or cloud communication constructs. This creates a governance blind spot where access appears clean in one model and risky in the live system. The practitioner conclusion is straightforward: if the ruleset is still keyed to old objects, it is measuring the wrong thing.

Non-human identities in SAP create the same segregation-of-duties risk as human users. A communication user that can both initiate master-data changes and approve downstream financial execution breaks the same control principle that protects against fraud in human access. The difference is visibility, not materiality, because many GRC programmes still exclude service accounts from formal SoD analysis. Teams should extend accountability to machine identities before audit findings do it for them.

AI-assisted execution removes the friction that used to make some conflicting duties harder to complete. The article's Joule example shows that an assistant can compress multi-step work across functional boundaries into seconds. That does not create a new category of SoD, but it does collapse the practical delay that some mitigating controls quietly depended on. The implication is that time-based assumptions inside SAP governance need to be re-evaluated.

Clean Core makes custom authorisation workarounds less defensible over time. When SAP pushes organisations toward released APIs and CDS-based access control, custom Z* objects become technical debt rather than a stable control strategy. That does not mean every customisation is wrong, but it does mean the authorisation model has to move with the platform instead of trying to freeze it. Practitioners should align role design with the platform's supported control surface.

From our research:

• 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.
• For a broader control lens, review NHI Lifecycle Management Guide for provisioning, rotation, and offboarding practices that map directly to SAP service accounts.

What this signals

Invisible service identities will keep expanding the SAP governance gap. When machine accounts are not visible to the same review process as human users, SoD reporting becomes a partial picture rather than a control statement. The practical move is to align access review cadence with identity type, because SAP risk is now distributed across people, integrations, and assistant-driven execution.

Clean Core is also a control-design decision. If an organisation leans on custom authorisation objects to preserve old role logic, it risks carrying legacy governance debt into S/4HANA migration work. Teams should use the platform's supported control surface, then measure whether their review process still catches conflicts across Fiori, CDS, and communication constructs.

The broader signal is that SAP authorisation is converging with NHI governance and IGA maturity at the same time. That makes cross-functional ownership essential, because finance controls, identity operations, and application security now have to answer the same question: can any identity complete a high-risk business action end to end?

For practitioners

• 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.
• Separate clean-core design from custom control exceptions Document where released APIs and CDS-based access should replace custom authorisation objects, and treat any remaining Z* exceptions as controlled technical debt.

Key takeaways

• SAP authorisation in S/4HANA is no longer adequately governed by ECC-era transaction roles and legacy SoD matrices.
• Non-human identities and AI-assisted execution now create the same control exposure as human access, but with faster paths and less visibility.
• The practical response is to rebuild SoD analysis around current platform controls, including Fiori services, CDS checks, and Communication Arrangements.

Key terms

• Segregation Of Duties: Segregation of duties is the control principle that splits sensitive business tasks so one identity cannot initiate and complete a high-risk process alone. In SAP, it prevents a single user or service account from combining conflicting rights that could enable fraud, misuse, or unauthorised financial execution.
• Communication Arrangement: A Communication Arrangement is the S/4HANA Cloud construct that binds an application scenario to a communication user and communication system. It is effectively the identity and access wrapper for API-level access, so it must be treated as a governed entitlement rather than a technical integration setting.
• Clean Core: Clean Core is SAP's approach to limiting custom code and keeping the core system closer to standard, supported functionality. For identity teams, it changes authorisation design by pushing access control toward released APIs, CDS-based checks, and controlled extension patterns instead of custom Z* objects in the core.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or lifecycle governance, it is worth exploring.

This post draws on content published by SafePaaS: SAP authorization design for S/4HANA, non-human identities, and AI assistants. Read the original.