Why SAP S/4HANA Cloud Public Edition changes your authorisation concept

Executive Abstract

For executives responsible for cloud transformation, risk and technology, authorisations in SAP S/4HANA Cloud Public Edition are more than a technical design decision. They’re a critical control point to manage risk, keep programme delivery on track, and protect the return on your cloud investment.

• Risk: Reusing legacy access concepts or using untailored SAP standard role templates can create over-access, segregation of duties conflicts, weak governance, and audit exposure.  
• Delivery: Setting a clear role and restriction model early in implementation programmes cuts late rework, speeds up user provisioning, and keeps delivery following SAP standard processes.  
• ROI: Least-privilege, tailored access helps avoid unnecessary authorisations and licensing exposure, safeguarding the business case for your cloud move. 

Introduction

In SAP S/4HANA Cloud Public Edition, the familiar on-premises authorisation toolkit no longer applies in the same way. The traditional tools used to build roles and maintain authorisation defaults, notably the PFCG and SU24 transactions, no longer apply in the same way, and there are no back-end shortcuts for accelerating role creation. If your security team approaches Public Cloud with an on-premises or private-cloud mindset, your authorisation concept may become difficult to govern before you go live.

Recent S/4HANA Cloud Public Edition releases have increased the granularity available in authorisation design. This increased granularity creates new opportunities for least-privilege access, but it also exposes weaknesses in legacy role concepts, SoD rulesets, operational maintenance models, and licensing assumptions. For SAP leaders, a passive, “set-and-forget” security strategy is not viable.

This article outlines the key authorisation design shifts in S/4HANA Cloud Public Edition, their impact on Segregation of Duties (SoD) compliance, and the practical steps required to build an audit-ready security model.

Making Shared Responsibility Work in Practice

Some organisations move to the cloud with the assumption that SaaS shifts most security responsibilities to SAP. In practice, this can create a costly governance gap when ownership is not clearly defined. Under the Cloud Shared Responsibility Model, the boundary is clear:

• SAP manages the cloud service, platform operations, and delivery of standard content such as business role templates and business catalogues.
• The customer remains responsible for user provisioning, custom business role design, organisational restriction values, access approvals, and the enforcement of Segregation of Duties.

Assigning SAP-delivered business role templates unchanged to productive users can create significant audit and SoD compliance exposure. These templates are intentionally broad and useful during Fit-to-Standard evaluation because they show the available functional scope. However, their catalogue scope may not match the customer’s actual job design, which can lead to over-access and SoD exposure if they are not tailored.

This tailoring is mandatory for productive use. To remain upgrade-stable, roles should stay aligned with SAP standard process design rather than creating a disconnected parallel role architecture. A practical approach is to use SAP templates as a functional baseline, remove unnecessary catalogues or apps, maintain appropriate restrictions, and document the resulting custom role design against the principle of least privilege.

To manage cloud security effectively, leadership needs to understand how the core structure of the authorisation architecture has changed. SAP S/4HANA Cloud Public Edition shifts the focus from technical role maintenance to a business-oriented model built around business roles, catalogues or apps, access categories, and restrictions:

In this model, access is defined by the apps a user can use, the access level granted, and the organisational scope in which that access applies. The actual organisational limits, such as plants, company codes, sales organisations, or purchasing organisations, are maintained as restrictions on the custom business role.

1. Using Direct App Assignment Where It Adds Control

Where available in the customer’s release and scope, direct IAM app assignment allows selected individual Fiori apps to be assigned directly to custom business roles without relying solely on broader business catalogue assignment.

Direct app assignment should be considered for roles where business catalogues grant more access than the user’s job requires. It can support cleaner least-privilege design by reducing unnecessary access that may be introduced through broader catalogues.

However, direct assignment is not the right or available option for every app, dependency, or process. Business catalogue assignment therefore remains a necessary part of the design. The authorisation concept should define clear decision rules for when to use direct app assignment, when to use business catalogue assignment, and how both approaches are governed through ownership, approval, and documentation requirements.

2. Designing Roles for Sustainable Maintenance

In S/4HANA Cloud Public Edition, customers no longer have the same back-end access, custom ABAP utilities, or database-level shortcuts that may have existed in on-premises landscapes. Role maintenance is performed through SAP-delivered applications and lifecycle mechanisms, which makes the initial role architecture and governance model much more important.

Because customers have fewer bespoke automation options than in on-premises systems, repetitive role changes can become operationally heavy if the design is not structured well from the start. Leading and derived business roles are a prime example: they can reduce maintenance effort when role content is consistent and only organisational restrictions differ, but the restriction strategy must be designed carefully.

This operational reality makes the initial leading/derived business role architecture a critical design decision. Leading business roles should hold the common functional content, such as business catalogues, apps, spaces, pages, and common restrictions. Derived business roles inherit this content and can be enhanced with specific organisational restriction values where required.

A structured role setup helps keep role maintenance predictable over the long term.

3. Authorisations as a Financial Lever: Licensing Exposure

Authorisation design can influence licensing cost as well as compliance. Depending on the customer’s contract and SAP service use description, assigned capabilities may affect the user category or commercial exposure. Role design should therefore be reviewed with the licensing or commercial team to confirm that users receive the access they need for their role, without assigning broader capabilities that may create avoidable cost or governance risk.

The flexibility of the cloud authorisation model creates a significant compliance challenge: traditional t-code-centric or catalogue-only SoD rulesets are incomplete for S/4HANA Cloud Public Edition.

Many traditional GRC rulesets were designed around transaction codes or high-level business catalogue assignments. In the new cloud architecture:

• Rulesets that only check at the catalogue level may miss risks introduced through direct app assignments, where these are used.
• The same rulesets may also generate false positives if they cannot evaluate the effective app-level access, access category, or restriction context actually granted to the user.

A cloud-ready ruleset strengthens SoD reporting by considering assigned catalogues, apps, access categories, and restrictions. This gives the organisation a more reliable view of effective access and supports clearer remediation decisions.

Four success factors define a strong SAP S/4HANA Cloud Public Edition authorisation implementation: SAP-aligned role design, clear ownership for roles and restrictions, cloud-ready SoD analysis based on effective access, and operational governance across maintenance, licensing, and audit evidence. Together, these elements turn cloud authorisation design into a controlled and scalable governance model. They help organisations translate SAP standard content into tailored business roles, apply restrictions consistently, make SoD risks visible, and maintain clear ownership from project delivery through to post-go-live operations.

PwC Switzerland helps organisations to:

• Design a clean leading/derived business role framework with documented rules for when to use direct app assignment and when to use business catalogues.
• Close the SoD ruleset gap by mapping risks to business roles, catalogues, IAM apps where relevant, access categories, restrictions, and mitigating controls.
• Reduce licensing by aligning assigned capabilities with actual business tasks and validating the impact with the customer’s commercial team.

If you are preparing for an SAP S/4HANA Cloud Public Edition implementation or need to remediate your authorisation model post-go-live, PwC Switzerland can help you design a secure, compliant, maintainable, and cost-conscious access architecture.

Learn more about PwC Switzerland’s SAP Access Management services: pwc.ch - SAP Access Management as a Service