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

At a glance

What this is: This analysis says SAP authorization in S/4HANA has become a multi-layer control problem that now includes Fiori, CDS checks, non-human identities, and AI-assisted execution.

Why it matters: IAM and GRC teams need to revisit SAP role design, SoD rules, and lifecycle governance because legacy ECC assumptions no longer cover the identities and paths that can now trigger high-risk business actions.

Context

SAP authorization in S/4HANA now spans more than transaction-code roles. The control surface includes layered Fiori authorisations, CDS-based checks, Communication Arrangements for API access, non-human identities, and AI-assisted execution.

Legacy ECC models assumed a simpler relationship between role assignment and business action. In S/4HANA, that assumption breaks because a single user, service account, or AI assistant can traverse multiple control layers before a high-risk action is completed.

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. That mismatch can hide real conflicts or create false confidence that segregation exists. Teams need to revalidate the ruleset against the current app and data control surface.

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. In SAP, those permissions can be embedded in Communication Arrangements and API flows, so the conflict is real even when no human user is directly involved. The governance problem is the same as with people, only less visible.

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. If teams cannot quickly explain who has access, why they have it, and whether that access is still justified, governance is already drifting out of control.

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.

Technical breakdown

Layered authorisation in Fiori and CDS

S/4HANA authorization is no longer just about PFCG roles or transaction codes. A Fiori app can require start authorization for the OData service provider, start authorization for the model provider, and business authorization on the underlying data. At the same time, many ECC-era objects are now enforced through CDS-based checks rather than the old object set. That means a legacy SoD matrix can miss both access paths and effective permissions if it was built around the older model.

Practical implication: re-map SAP roles against the current authorization objects and app-level dependencies instead of reusing ECC rulesets.

Communication Arrangements as non-human identity control points

In S/4HANA Cloud, Communication Users, Communication Systems, and Communication Arrangements define API-level access for service accounts and integrations. These are non-human identities, but they still participate in business processes that can create SoD conflicts. When a communication user can trigger vendor creation, payment runs, or other sensitive flows, the risk is not theoretical; it is the same privilege combination problem that GRC teams already manage for people, only expressed through API access.

Practical implication: include Communication Arrangements and service accounts in SoD analysis and approval workflows.

AI-assisted execution removes friction from SoD conflicts

SAP Joule inherits the authorization of the user invoking it, so AI assistance does not replace governance, it amplifies the permissions already in place. A user who previously needed to navigate several transactions manually may be able to complete conflicting duties much faster through AI-mediated execution. That changes the value of mitigations that relied on operational friction or manual sequencing, because speed and orchestration can collapse the practical barrier between conflicting steps.

Practical implication: test SoD mitigations against AI-assisted workflows, not only against manual user behaviour.

Threat narrative

Attacker objective: The objective is to complete a sensitive SAP business transaction by combining permissions that should have remained separated.

1. Entry occurs when a user, communication user, or AI-assisted workflow is granted legitimate access across multiple SAP control layers.
2. Credential or permission abuse follows when those permissions span business authorisations, OData access, or API-enabled actions that were not analysed together.
3. Escalation happens when the identity can combine otherwise separate duties, such as master data maintenance and payment-related actions, without detection.
4. Impact is the completion of a high-risk SAP business process end to end, creating fraud, audit, or compliance exposure.

Breaches seen in the wild

• SAP SQL Anywhere Monitor hard-coded credentials (CVE-2025-42890): Hard-coded credentials in SAP SQL Anywhere Monitor scored CVSS 10.0 (CVE-2025-42890); SAP removed the tool, and no exploitation was seen.
• SAP Kubernetes secrets exposure 2023: Kubernetes secrets committed to GitHub exposed 203 valid registry credentials, including SAP artifact repository access. SAP closed it after Aqua's report.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Non-human identities now carry the same governance burden as business users. Communication Users, service accounts, and API integrations can combine duties just as easily as human users, but traditional GRC programs still tend to classify them as technical exceptions. That is a governance blind spot, not a niche edge case. The implication is that identity review, role design, and exception handling must extend to machine-mediated SAP access as a first-class control domain.

AI-assisted execution collapses the friction that once masked SoD conflicts. The assumption that conflicting duties are operationally hard to complete was always a weak control, but it becomes worse when Joule can carry out actions at machine speed. The practical question is not whether an identity has access in principle, but whether it can complete the full conflict path quickly enough to defeat human review. Practitioners should re-evaluate any mitigation that depends on delay rather than separation.

Continuous proof of end-to-end segregation is becoming the real control requirement. SAP environments now span cloud apps, APIs, AI assistance, and multiple identity types, so static role reviews are no longer sufficient evidence of control. The governing concept here is identity blast radius: if one identity can move from request to fulfillment without interruption, the programme has not actually constrained the business action. Security teams should measure whether any single identity can still complete a high-risk transaction chain end to end.

Clean Core is changing authorisation design from flexibility to discipline. The move away from custom Z objects and toward released APIs and CDS-based access control reduces local variation but also removes excuses for uncontrolled exceptions. That shifts SAP governance toward standardised patterns, traceable approvals, and tighter lifecycle discipline. Practitioners should treat custom authorization logic as technical debt unless a release-based path is unavailable.

From our research library:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs

What this signals

Identity blast radius is now the SAP governance metric that matters. If one identity can move from access request to payment or master-data impact inside a single control plane, static SoD certification is only partial evidence. SAP teams need to prove that no human, service account, or AI-assisted workflow can chain permissions into a completed business event without interruption.

Non-human identities should be treated as first-class SAP business actors. Communication Users and API integrations are not background plumbing when they can trigger the same financial outcomes as a clerk or approver. That means policy, evidence, and remediation workflows must cover them in the same lifecycle as human access, not as an exception list.

Fiori layered authorization changes the testing problem as much as the design problem. The controls now span app launch, service access, and business data checks, so teams need to validate each layer independently and then test the combined path. A role can look clean in isolation while still allowing a prohibited end-to-end action in production.

For practitioners

• 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. Validate every high-risk path against the Fiori Apps Reference Library instead of assuming old object mappings still hold.
• 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. Review whether any non-human identity can initiate and complete a sensitive business flow without an independent control step.
• 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. Rework mitigations that depend on manual effort or process delay.
• Separate API approval from business approval Define ownership for Communication Arrangements, approval criteria for service access, and review points that are distinct from business role approvals. Keep API access decisions visible in the same governance record as SoD analysis.
• Plan for SAP GRC and IDM transition together Align access governance, certification campaigns, and deprovisioning processes with the SAP GRC for HANA 2026 roadmap and the retirement of SAP Identity Management 8.0. Build a migration path that preserves lifecycle control across the change.

Key takeaways

• 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.
• The governance gap is not just incomplete roles. It is the inability to prove that one identity cannot carry a high-risk SAP process from start to finish.
• The control that matters most is end-to-end segregation across human and non-human actors, with current rulesets and lifecycle reviews aligned to the modern SAP control surface.

Key terms

• 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.
• Layered authorization: Layered authorization is a control pattern that combines roles, scopes, and request-level detail so no single mechanism carries the full security burden. It is useful in NHI-heavy ecosystems because it separates who may ask from what they may ask for and what is ultimately enforced.
• Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
• Clean Core: A clean core is an SAP operating model that keeps the digital core minimally customised and pushes extensions into supported layers. For identity governance, that means access controls, SoD rules, and audit evidence must work through stable interfaces instead of embedded modifications that break during upgrades.

Deepen your knowledge

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