The misframing that produces audit findings
Most access-governance planning treats an S/4HANA move as a re-implementation of the same GRC tooling on a new box: migrate SAP Access Control, reconnect the plugins, carry the ruleset, done. That plan misses the real disruption. S/4HANA’s authorization design is Fiori-centric — business catalogs, spaces and pages, a front-end/back-end split — and it reshapes what a role is. Since your segregation-of-duties (SoD) ruleset is a set of statements about roles and the actions inside them, changing the role model changes what the ruleset measures. Authorization redesign and GRC redesign are one program, not two. Run them separately and the gap between them becomes your auditor’s finding.
What “new role model” actually means
Three facts anchor the redesign. First, the old Fiori launchpad groups concept is deprecated since SAP S/4HANA 2021 FPS01, with spaces and pages as the successor layout model — assigned through the user’s business role, with SAP providing migration tooling to create launchpad pages from existing groups. Any conversion or upgrade today forces this layout decision, which makes it the natural moment to redesign roles rather than transplant them.
Second, the deployment shape drives the role count: in the embedded front-end-server deployment, only one PFCG role is required in the S/4HANA system, while a standalone front-end server requires both a front-end and a back-end role. Third, the build mechanics change: a Fiori business role is created by building a PFCG role and populating its menu with SAP Fiori catalogs, which pull in the start authorizations for the activated OData services.
The split that changes what SoD sees
The structural novelty versus ECC is the separation of concerns: Fiori separates UI access — catalogs, spaces and pages — from data access — the OData service authorizations, where classic ECC roles bundled transaction-code start authorization and data authorization together.
For access-risk purposes this cuts both ways. Done well, the split gives you cleaner, more auditable granularity: what a user can see and what a user can change become separately governable. Done carelessly — catalogs assigned broadly for “user experience” reasons while data authorizations are copied forward from ECC role exports — it manufactures both false positives (conflicts flagged on UI reachability the user cannot actually exercise) and false negatives (real data-level conflicts invisible to a ruleset still written in transaction-code vocabulary). That is the concrete mechanism behind the headline: the ruleset and the role model must be redesigned against each other.
Mapping SAP Access Control 12.0 onto the new model
The tooling itself is familiar. SAP Access Control 12.0 comprises Access Risk Analysis (ARA), Access Request Management (ARM), Business Role Management (BRM), and Emergency Access Management (EAM — the “firefighter” capability), plus periodic user-access and SoD reviews. ARA analyzes user access proactively against a predefined SoD and critical-access ruleset; BRM manages business roles and synchronizes them with the S/4HANA roles; EAM logs privileged firefighter activity for supervisor review.
What changes is not the module list but the content flowing through it. BRM’s business roles must now be composed against catalog-based PFCG roles. ARM’s provisioning workflows must assign the right combination of front-end and back-end access. EAM’s log reviews must make sense of Fiori app activity, not just transaction codes. Each module works on S/4HANA; each needs its content rebuilt to describe the new landscape.
The ruleset migration itself
In SAP Access Control, SoD “functions” wrap the actions that perform a task, and “risks” combine two or more conflicting functions — with the effective rule count driven by action and permission-level combinations. Migrating from an ECC transaction-action vocabulary to one that includes Fiori applications and OData services therefore materially changes ruleset content, not just its connector settings. Mechanically, SAP delivers rulesets activated via BC Sets, and any ruleset change requires regenerating the rules (GRAC_GENERATE_RULES) — but the mechanical step is the easy part. The design work is deciding, function by function, what the S/4HANA-era action set for each business task actually is, then validating the delivered ruleset against your customized reality instead of trusting it blind.
Plan for a false-positive triage period after the first regeneration: a ruleset rebuilt against a redesigned role model will surface conflicts that are artifacts of the migration, and burning them down is real work that belongs in the plan, not a surprise.
Compliance reporting when roles are catalogs
Your audit narrative shifts with the model. Risk-analysis reports, mitigations, and periodic access reviews are now statements about catalog-based business roles and OData-level access — which means reviewers signing off on access need to understand what a space, a page, and a catalog grant. Budget for that education: a periodic review performed by reviewers who do not understand the new grants is a control that exists on paper only.
The cloud horizon: IAG and the bridge
Direction of travel matters for a multi-year program. SAP Cloud Identity Access Governance (IAG) is SAP’s cloud-native access-governance service, and the AC–IAG “bridge” lets an existing Access Control 12.0 environment remain primary while extending risk analysis and provisioning to cloud applications such as S/4HANA Cloud, Ariba, SuccessFactors, and Concur. For hybrid landscapes the pragmatic pattern is exactly that: AC stays the system of record on-premise, IAG extends the perimeter — and the decision of what governance lives where should be made deliberately, on your application roadmap, not by default.
A pragmatic sequence
Stated plainly as IOTEK’s recommended program shaping (guidance from delivery experience, not an SAP-published sequence): design the Fiori business-role architecture first, on paper, including the catalog/space/page structure and the front-end/back-end split; recompose SoD functions and risks against that architecture; regenerate and validate the ruleset in a test tier against realistic role assignments; then migrate the AC content and cut over reporting. Roles first, ruleset against roles, tooling last. Organizations that run it in the other order spend their first audit cycle explaining false positives.
Access risk on S/4HANA is not a tooling migration — it is a redesign of the thing your ruleset describes. Redesign the role model and the ruleset as one workstream, and the audit becomes a formality; run them apart, and the gap between them is exactly where the finding will be written.