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 of

authorization — (1) start authorizations for OData service data providers, (2) start

authorizations for model providers, and (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”.”

 

That is the standard modern control

The post SAP Authorisation Best Practices: Avoiding Segregation of Duties Conflicts appeared first on Safepaas.

*** This is a Security Bloggers Network syndicated blog from Safepaas authored by SafePaaS. Read the original post at: https://www.safepaas.com/blog/sap-authorisation-best-practices-avoiding-segregation-of-duties-conflicts/