If you learned SAP security on ECC or S/4HANA on-premise, your muscle memory says PFCG. In S/4HANA Cloud (public edition), PFCG doesn't exist for you. Neither does SU01. Instead, authorizations are built in a Fiori app called Maintain Business Roles — and while the concepts carry over, the mechanics are different enough to trip up experienced consultants.
Why PFCG had to go
PFCG is powerful, but it's also a GUI transaction built for an era of green screens and basis administrators. S/4HANA Cloud is API-driven, multi-tenant, and updated continuously — SAP needed an authorization model that fits Fiori apps, business catalogs, and a clean core where customers can't touch the underlying roles SAP ships.
The replacement splits the old world into cleaner pieces. Instead of SU01 you have the Maintain Business Users app. Instead of PFCG you have Maintain Business Roles. And instead of transaction codes in a role menu, you work with business catalogs — SAP-delivered bundles of Fiori apps grouped by business function, like "Accounts Payable — Processing" or "Manage Bank Accounts."
Key takeaway: In S/4HANA Cloud you don't build menus from transactions. You assemble SAP-delivered business catalogs into business roles, then fine-tune what each role can actually do with restrictions.
Anatomy of a business role
Open Maintain Business Roles and create a new role. The first thing you'll notice is there's no menu tab. Instead, you add business catalogs on the "Business Catalogs" tab. Each catalog brings a set of Fiori apps (tiles) that appear on the user's launchpad. SAP ships hundreds of these catalogs, and you generally don't modify them — you pick the ones matching the job.
The real authorization work happens under Restrictions. For each catalog, you set two things: read access and write access, each with an access context. "Unrestricted" means everything. "Restricted" lets you scope it down — by company code, plant, purchasing organization, and so on. This is the cloud equivalent of maintaining org-level fields in PFCG, and it's where most of the design effort goes.
A role for an AP clerk in company 1000 might therefore contain the AP processing catalogs with write access restricted to company code 1000, plus a few display-only catalogs for reporting. The user sees exactly the apps they need, and the data they can touch is fenced off by the restrictions.
What carries over from PFCG thinking
The design discipline is identical: build roles around jobs, not people. One role per job function, named clearly. Resist the urge to create a bespoke role per user — the same sprawl that ruins PFCG systems ruins business role catalogs too.
Segregation of duties still applies, arguably more so, because the catalog model makes it tempting to just keep adding catalogs until the user stops complaining. The same toxic combinations (create vendor + pay vendor, for instance) need to be designed out at the role level, not discovered by the auditor.
And testing still matters. S/4HANA Cloud gives you a preview of the role as a specific user would see it — use it. Check the launchpad tiles, try the restricted transactions, confirm the scoping actually fences the data. Finding out in production that "restricted to company 1000" didn't apply to one catalog is an unpleasant surprise.
The practical differences to remember
A few things catch PFCG veterans out. First, you can't see or change the authorization objects underneath — SAP abstracts them away behind the catalog and restriction model. That's deliberate; it keeps the core clean across upgrades, but it means less fine-grained control than PFCG's traffic lights.
Second, transports work differently. Business roles move through the cloud's transport lifecycle (export/import via the "Export Customizing Transports" or transport management in Central Business Configuration), not TMS. Plan your landscape strategy accordingly.
Third, SAP delivers new catalogs with every release. After each upgrade, review what's new — there's often a catalog that replaces a workaround you built, or a restriction option that finally covers a gap. The continuous-innovation model only pays off if someone actually looks at what's new.
Maintain Business Roles is simpler than PFCG on the surface, but don't mistake simpler tooling for simpler decisions. The hard part was never the transaction — it's deciding what each job should be allowed to do, and having the discipline to say no to everything else.