Your SAP Security Roles Are Already Broken

If you administer SAP security and your organization is moving to S/4HANA, there is an uncomfortable fact to state up front: your existing roles are not merely outdated. They are structurally invalid — incompatible with the new data model, not just in need of a tidy-up. The clearest illustration is a single transaction. FD03, used to display customer master data, no longer exists in S/4HANA; it is the Business Partner transaction now. Every role referencing FD03 references something that is not there, and that pattern repeats across the entire simplification list.

Why brownfield doesn't save you

A common assumption is that a brownfield conversion carries the roles across untouched. It does not. Backend roles continue to exist, but the transactions inside them that were replaced by Fiori apps have to be removed, and Fiori roles have to be added for the frontend. That is work in two directions, and the removal half is the one that gets skipped — because adding access makes users happy and removing it makes them call you. The result is roles that are both broken and over-privileged.

The structural change: two layers

Classic authorisation was essentially one layer. Fiori splits it in two. When a user opens a Fiori app it calls an OData service implemented on the backend, so the user needs two distinct things: start authorisation for the OData service itself (the frontend piece, IWSG) and every business authorisation for the data the app displays (the backend piece, IWSV). The app does not work unless both are right — and a user can have perfect business authorisations and still get nothing, because the service start authorisation is missing. That failure looks nothing like a classic missing-authorization error. How much duplication you manage depends on whether deployment is embedded or central-hub.

The good news: catalogs do the work

You do not have to hand-assemble all of that. The PFCG role menu has, in SAP's own word, “smarts.” Add a business catalog to the role menu and the system automatically determines the required authorisations — the OData services (IWSG, IWSV, or both for embedded), GUI transaction codes, ABAP Web Dynpro applications and Web Client UI executables. And when the catalog changes, the authorisations re-derive. That is the difference between roles that survive an upgrade and roles you rebuild every time — which tells you where the craft went. Catalog design is the authorisation craft now.

The 500-role trap

SAP ships more than 500 job-based role templates, prefixed SAP_BR_ — Asset Accountant, Purchaser, Inventory Manager and so on. It is tempting to adopt them wholesale. Do not, without checking: the SAP standard is defined generously, and a single one of those roles may carry access to 50 to 100 Fiori applications. In a regulated environment that is a segregation-of-duties problem arriving pre-installed. Use the templates as a reference, then tighten with restrictions before an access report reaches an auditor.

SU25 is now mandatory

In ECC, SAP shipped pre-filled Profile Generator tables, so many administrators never touched SU25. In S/4HANA it is a mandatory initialisation step. Orientation: SU22 is SAP's delivered values, SU24 is your customer version, and SU25 is the tool that moves between them. Step 2A copies the standard values into your customer tables where there is no conflict; step 2B shows the transactions where your mapping was changed; step 2C identifies which roles are affected and need merging again.

Why discipline suddenly compounds

The economics changed underneath all of this. In the old world, a manual authorisation tweak cost you once. In S/4HANA, feature updates cannot be deferred forever, so upgrades are more frequent — and every manual change has to be revisited at every upgrade, one role at a time. But keep authorisations clean in SU24, with nothing changed by hand, and roles merge automatically with the adjusted values. So an organization with clean SU24 defaults absorbs upgrades almost automatically, while one with thousands of manual tweaks does the work again every quarter. That gap widens every release.

Public cloud is a different profession

If the destination is public cloud, this is not an evolution of the job but a different one. There is no PFCG, no SU01, no SU25. A fresh system arrives with three standard roles — Administrator, BPC Expert, Manager. Activating scope items generates catalogs and role templates, which you consume to build business roles, controlling access through restrictions maintained at catalog level. And you cannot customize catalogs in public cloud; that is on-premise only. The roles expire, but the judgment about who should have access to what does not — and a conversion is the cheapest opportunity you will ever get to clean up the segregation-of-duties conflicts a long-lived role concept accumulates.

Sources & further reading

• SAP Community — Understanding SAP Business RolesThe 500+ SAP_BR_ templates and catalog-based authorisation model. Verified live in prior research.
• SAP Community — SAP S/4HANA AuthorizationsThe two-layer OData model: IWSG front end, IWSV back end. [Verify link.]
• SAP Help — SU25 authorization upgradeThe mandatory SU25 initialization and steps 2A/2B/2C. [Please verify — help.sap.com deep paths shift by release.]

Authorisation objects, catalog behavior, deployment options and cloud role models vary by release and edition. Classic transactions still exist in S/4HANA — specific ones were removed or replaced. Verify against SAP Help. SAP guidance, transaction availability and dates change between releases and editions. Verify anything here against SAP Help for your own situation before you commit to it. This article is independent commentary and is not affiliated with SAP or any implementation partner.