SAP authorization design is the backbone of a secure, compliant SAP environment. Done right, SAP authorization enables productivity while controlling segregation of duties and sensitive access; done wrong, it becomes a constant source of audit findings and emergency role changes.

But SAP authorization in 2026 looks fundamentally different from even a few years ago. The shift to S/4HANA, the rise of non-human identities, SAP´s Clean Core strategy, and the introduction of AI assistants like Joule have all changed what “best practice” means. Organizations still designing roles the way they did in ECC are building on a foundation that no longer exists.

SAP authorization fundamentals — what has changed in S/4HANA

SAP still uses role-based access control, but S/4HANA has introduced a layered authorization model that goes well beyond traditional transaction code-based design: Fiori-layered authorization: Every Fiori app now requires three layers ofauthorization 

(1) start authorizations for OData service data providers,

(2) start authorizations for model providers

(3) traditional business authorizations for the underlying data.

The S_SERVICE authorization object is central to controlling

OData service access.

CDS view-based authorization checks: Many ECC authorization objects have been replaced by CDS Views. For example, storage location authorization (M_MATE_LGO in ECC) may now be handled via F_LGORT_AU through a CDS authorization check. This means legacy SoD rulesets built for ECC may not map correctly to S/4HANA.

Spaces and Pages replace Fiori Groups: Since S/4HANA 2021, Fiori Groups mode has been deprecated. S/4HANA 2025 further evolves the Launchpad with Spaces and Pages layouts, where unauthorized content is automatically hidden.

Task-based role design: Instead of broad, “catch-all” roles, leading organizations build smaller, task-based roles and group them into composite roles that reflect actual responsibilities. SAP recommends keeping space-to-role assignments separate from business authorizations.

Fiori Apps Reference Library: This is now the authoritative source for identifying required authorization objects per app, supplementing the traditional SU24 approach.

Where SAP authorization and segregation of duties collide

In large SAP landscapes, with thousands of roles and users, it´s easy for SoD conflicts to slip into production. Even if each individual role looks acceptable, the combination of roles assigned to a user can create hidden segregation of duties risks.

Common SAP SoD risk areas:

Procure-to-pay: vendor master maintenance plus invoice posting and payment approval.

Order-to-cash: customer master changes plus credit management and revenue posting.

FI/CO: journal entry creation plus posting and approval rights.

Basis/security: user provisioning and role maintenance combined with finance transaction access.

Emerging SoD risk areas in S/4HANA:

Non-human identities: In S/4HANA Cloud, API authorization is managed through Communication Arrangements — a combination of Communication User, Communication System, and Communication Arrangement that ties them to specific scenarios. Service accounts, bots, and API keys are now the fastest- growing identity category in SAP environments, yet most SoD analysis still focuses exclusively on human users. A Communication User that can both create vendors via API and trigger payment runs represents the same SoD risk as a human user with those permissions — but is often invisible to traditional GRC Tools.

AI-amplified access risk: SAP Joule, now embedded across S/4HANA, inherits the authorization of the user invoking it. A user with broad access can use Joule to execute conflicting duties at speed and scale — the practical friction that used to mitigate some SoD risks (navigating multiple transactions, manual data entry) disappears when an AI assistant can act across functional areas in seconds.

Cross-system conflicts: A user “Invoice Approval” in S/4HANA and “Purchase Order Approval” in Ariba creates a procurement fraud risk that no single-system analysis would detect.  SAP Cloud IAG released comprehensive new cross-system rulesets in Q2 2025 covering Concur, SuccessFactors, Ariba, and BTP — a clear signal that cross-system SoD is no longer a theoretical concern.

For SOX-focused SoD guidance, see:

SOX Separation of Duties (SoD) Best Practices:

A practical approach to SAP authorization and SoD

To get SAP authorization right and keep SoD risk under control, leading organizations  follow a repeatable, policy-driven process.

1. Define your access and SoD policy

• Agree on which SoD conflicts are unacceptable vs. which can be accepted with

mitigation.

• Align the policy with SOX, internal audit, and business stakeholders, and clearly

document expectations.

• Extend the policy scope to non-human identities — Communication Users,

service accounts, and API integrations should be governed under the same SoD

framework as human users.

• Address Joule and AI access — decide which roles should include the “Joule

privilege” and whether AI-assisted execution changes the risk profile of existing

SoD exceptions.

2. Design or refine your SAP role model

• Build task-based roles that separate configuration from transaction activities

wherever possible.

• Standardize naming and patterns to simplify ongoing analysis and maintenance.
• Account for S/4HANA´s layered authorization model — roles now need to

cover OData service access (S_SERVICE), CDS view-based checks, and

business authorizations. Roles migrated from ECC without adjustment will have

gaps.

• Align with SAP´s Clean Core strategy — SAP´s A-D extensibility framework

(formalized August 2025) classifies custom authorization objects (Z* objects) as

Level C/D risk. New role designs should use released APIs and CDS-based access control rather than creating custom authorization objects in the S/4HANA core. In S/4HANA Cloud Public Edition, custom authorization objects cannot be created at all.

• Include Communication Arrangement governance — define standards for how API-level access is designed, who approves Communication Arrangements, and how they are included in SoD analysis.

3. Run SoD analysis on roles and users

• Analyze SAP roles and user assignments against a defined SoD ruleset — but ensure your ruleset has been updated for S/4HANA. ECC-era SoD matrices that rely on transaction codes and legacy authorization objects will produce false negatives in S/4HANA environments where CDS views and OData services have changed the authorization landscape.

• Include cross-application access if you have multiple ERPs or SAP cloud products (Ariba, Concur, SuccessFactors).

• Extend SoD analysis to non-human identities — Communication Users and service accounts with API access to multiple functional areas represent the same SoD risk as human users.

• Identify high-risk users, roles, and "hot spot" processes; remediate conflicts through role redesign or reallocation of duties.

4. Implement mitigating controls where needed

• For SoD conflicts you cannot eliminate without impacting operations, define mitigating controls like independent reviews, reconciliations, or targeted monitoring.

• Document risk acceptance, mitigations, and approvals so auditors can see a clear decision trail.

• Factor in AI-assisted execution — a mitigating control that relies on "practical difficulty of executing both sides of a conflict" may no longer be effective if Joule can automate both actions in seconds. Consider whether existing mitigations need strengthening.

5. Continuously monitor SAP authorisation

• Run periodic access reviews focused on SoD and sensitive access, not only dormant accounts.

• Re-run SoD analysis when roles, org structures, or connected systems change.
• Monitor beyond access design — recent high-severity vulnerabilities demonstrate that authorization design alone is not sufficient. CVE-2025-31324, a CVSS 10.0 zero-day in NetWeaver Visual Composer, allowed unauthenticated code execution. CVE-2026-0509, a CVSS 9.6 missing authorization check, enabled low-privileged users to bypass intended access controls entirely. Continuous monitoring must be complemented by aggressive patch management.

• Track the SAP GRC roadmap — SAP GRC for HANA 2026, the unified successor to Access Control 12.0, Process Control, and Risk Management, is expected in Q3 2026. It introduces AI/ML-powered access reviews, Joule integration for conversational GRC, and sandbox simulations. Organizations should be evaluating their GRC migration path now.

• Plan for SAP IDM retirement — SAP Identity Management 8.0 reaches end of mainstream maintenance in December 2027 with no SAP successor product. Microsoft Entra ID is the recommended enterprise-wide replacement. This fundamentally changes how authorization lifecycle management — provisioning, deprovisioning, certification campaigns — will work in SAP environments.

Useful resources:

Guidebook for SOX Internal Controls Compliance:

What ITGC Controls Are Required for SOX Compliance?:

How SafePaaS helps you design and monitor SAP authorization

The SAP authorization landscape is more complex than ever — S/4HANA´s layered authorization model, non-human identities, cross-system SoD, AI-assisted access, and Clean Core constraints all demand a control layer that goes beyond what SAP´s native tools provide today.

SafePaaS provides a policy-driven control platform across SAP and other business- critical systems, so you can design cleaner roles, prevent SoD issues before provisioning, and maintain continuous visibility into access risk — across human and non-human identities, across applications, and across deployment models.

Platform strengths:

Pre-built SoD rule sets that include SAP S/4HANA processes and authorization objects — updated for CDS view-based checks and Fiori-layered authorization. Fine-grained, cross-application SoD and sensitive-access analysis across SAP and non-SAP applications, including detection of conflicts that span S/4HANA, Ariba, Concur, and SuccessFactors. “What-if” analysis to check SoD impact before you grant new access or change roles — critical during S/4HANA migrations where role redesign is inevitable. Automated workflows for access requests, approvals, SoD remediation, and periodic certifications — with full audit trails. Non-human identity governance — visibility into Communication Arrangements, service accounts, and API-level access within the same SoD framework. Dashboards and reports aligned to ITGC and SOX requirements, with evidence ready for auditors at any time.

Start exploring:

ITGC SOX: The Basics and 6 Critical Best Practices for 2026:

Segregation of Duties — Automation Guide:

What CISOs should rethink about SAP authorization

SAP authorization is no longer just transaction codes and PFCG roles — it is a multi-layered model spanning OData services, CDS views, Spaces, and Communication Arrangements Non-human identities must be governed within the same SoD framework as human users — they represent the same financial risk SAP´s Clean Core strategy means custom authorization objects are technical

debt, not design flexibility AI assistants like Joule remove the practical friction that once mitigated some SoD risks — policies must account for speed and scale of AI-assisted

Execution

SAP GRC for HANA 2026 and the SAP IDM retirement are two platform shifts happening simultaneously — organizations need a migration strategy for both The question is no longer “Do we have SAP authorization controls” — it is: “Can we prove, continuously, that no identity — human or non-human — can execute a high-risk transaction end-to-end across our SAP landscape”.”