Enterprise SU24 Governance: Landscape Consistency, Transport Strategy, and S/4HANA/Fiori Migration
Design an enterprise-grade governance model for SU24 maintenance that keeps authorization defaults consistent across a multi-system, multi-track landscape, survives S/4HANA and Fiori transitions, and supports auditable, low-risk change management.
Explanation
SU24 data is deceptively small in scope but disproportionately influential: every custom transaction, every Fiori catalog/target mapping, and every role built with the role menu depends on accurate check indicators and default field values. At architect level the problem is not 'how do I add an object to a transaction' but 'how do I guarantee that authorization defaults remain correct, traceable, and synchronized across development, quality, and production, across ECC and S/4HANA tracks, and across classic GUI transactions and Fiori app-to-service mappings, over a multi-year lifecycle that includes upgrades, cloud extensions, and organizational role redesigns.' The core architectural risk is landscape drift. SU24 defaults are stored per system and are not automatically kept identical across a transport landscape unless deliberately transported and reconciled. If a security architect allows ad hoc SU24 changes directly in quality or production (a common shortcut during urgent go-lives), the systems diverge: a role built in development with one set of defaults will not reproduce the same authorization footprint after transport, causing either excessive access (missing check indicators suppress checks that should exist) or broken access (defaults that were never proposed, causing values to be missed during role build). This is one of the most common root causes of 'it worked in QA but not in production' authorization defects, and it is entirely preventable with governance. A mature governance model treats SU24 maintenance as a controlled configuration change, not an ad hoc security task. That means: changes are requested with business/technical justification, made only in a designated development system, captured in a transport request with a clear description referencing the requesting transaction or Fiori app, peer-reviewed before release, and validated in quality with a rebuild or delta comparison of affected roles before production transport. Large programs typically maintain a register mapping each customer transaction and each Fiori app-to-OData-service target to its SU24 proposal status, so that during audits or upgrades the organization can demonstrate which objects have been reviewed and which are still using SAP-delivered defaults, if any. S/4HANA and Fiori materially change the SU24 conversation. In classical ECC, SU24 proposals are almost entirely transaction-code driven. In S/4HANA and especially with Fiori launchpad-based access, the object being protected is often a Fiori tile or target mapping backed by an OData service, and the relevant authorization objects may originate from the underlying business logic rather than a single transaction. This means the architect must plan SU24 governance to cover custom Fiori apps and custom OData services deployed through the Fiori development toolchain, not only custom ABAP transactions. Because SAP periodically updates delivered content (SU25 and related upgrade tooling reconcile SAP-delivered proposals against customer changes), governance must include a defined upgrade procedure: before every S/4HANA support package or feature pack upgrade, run the comparison step, review deltas, and explicitly decide whether to adopt, ignore, or override new SAP proposals rather than silently accepting them, since silent acceptance can widen or narrow the effective default footprint used by every future PFCG role built from templates. For BTP and hybrid landscapes, note that SU24 as a transaction and concept is specific to the ABAP-based authorization model (ECC and S/4HANA, including embedded and side-by-side Fiori on ABAP stacks). BTP services generally use role collections and scopes defined in the cloud cockpit, not SU24-style check indicator maintenance; treat this as a genuinely different authorization model requiring its own governance artifact, and avoid describing BTP scope assignment in SU24 terminology, which is a common documentation mistake in hybrid programs. Governance must also define retention and audit evidence: who approved each SU24 change, what testing validated no unintended access expansion, and how the change ties to a segregation-of-duties risk assessment if the object touches a sensitive risk in the organization's SoD ruleset. Architect-level decisions include whether to centralize SU24 ownership in a single security configuration team (better consistency, potential bottleneck) versus distributing ownership to application teams with a security gatekeeper review (faster but harder to govern), and how to structure regression testing so that SU24 changes are validated against a representative sample of roles before broad rollout, not just the role that triggered the request.
Real project scenario
A global manufacturer running a phased S/4HANA rollout across five regional production systems discovered that two regions had diverging authorization behavior for the same custom Fiori app: one region's users could see a supplier list app, the other could not, despite identical PFCG roles. Root cause analysis traced the difference to an SU24 check indicator for a supporting OData authorization object that had been added directly in one region's production system months earlier during a hotfix, without a corresponding transport to development or the other region, and without documentation. The security architecture team implemented a governance model requiring all SU24 maintenance to originate in a single global development system, mandated transport-based propagation with a change ticket reference in every transport description, and introduced a quarterly landscape reconciliation report comparing SU24 tables across all production systems to detect drift early, closing the gap before the next regional go-live.
Common mistakes
ā¢ Allowing SU24 changes to be made directly in quality or production systems as a shortcut, causing undetected drift from development ā¢ Treating Fiori app authorization gaps purely as PFCG role problems without checking whether the underlying OData service object ever received a correct SU24 proposal ā¢ Silently accepting all new SAP-delivered proposals during an upgrade reconciliation step without reviewing what changed and why ā¢ Assuming SU24 governance extends to BTP role collections and scopes, which use a fundamentally different cloud authorization model ā¢ Failing to maintain a register of which custom transactions and Fiori apps have documented, reviewed SU24 proposals versus relying on undocumented tribal knowledge ā¢ Not including SU24 changes in the organization's formal change management and SoD risk review process, treating them as low-risk technical tweaks
Best practices
ā¢ Restrict SU24 maintenance to a single designated development system per landscape track and enforce transport-based propagation to all downstream systems ā¢ Require a change ticket or business justification reference in every transport description touching SU24 tables ā¢ Maintain a living register mapping custom transactions and custom Fiori apps/OData services to their SU24 review status ā¢ Run and formally review the upgrade reconciliation step before every S/4HANA support package or feature pack upgrade, deciding explicitly on each delta rather than accepting defaults silently ā¢ Perform periodic cross-system reconciliation of SU24 content in multi-region or multi-track landscapes to detect drift proactively ā¢ Keep SU24 governance clearly scoped to ABAP-stack authorization; document BTP role collection and scope governance as a separate, explicitly cloud-specific process ā¢ Tie significant SU24 changes affecting sensitive authorization objects into the organization's segregation-of-duties risk assessment workflow
Interview angle
Architect-level interviewers probe whether a candidate understands SU24 as a landscape governance problem, not just a per-object configuration task. Expect questions on preventing environment drift across transport landscapes, handling the SU24-to-SU25 upgrade reconciliation lifecycle in S/4HANA, correctly scoping SU24 relevance for Fiori/OData versus classic transactions, and clearly explaining why BTP authorization is out of SU24's scope. Strong answers reference concrete governance controls: designated maintenance system, transport-based propagation, documented change tickets, periodic reconciliation reporting, and integration with SoD risk assessment, rather than describing SU24 as a simple checkbox screen.