SU24 — SU24 Authorization Default Values Maintenance

SU24 maintains the authorization object check indicators and default field values that PFCG reads when a transaction code is added to a role menu. The output lands in the customer tables USOBX_C (check indicator per transaction/object) and USOBT_C (proposed field values). The one fact that explains most confusion: SU24 is a proposal-generation table, not an enforcement mechanism. The actual AUTHORITY-CHECK statement is compiled into the ABAP program and fires regardless of what SU24 says. Setting an object to 'No Check' in SU24 stops PFCG from proposing it in new or re-read role menus; it does nothing to a check that the program executes unconditionally. Consultants who edit SU24 expecting it to suppress a live authorization error are solving the wrong layer of the problem.

Reached for during role design and redesign projects, when a custom transaction or Z-program needs its authorization objects registered so PFCG proposes something sensible instead of an empty authorization tab, and after a support package or upgrade when SAP delivers new standard checks that have to be merged into the customer tables via SU25. It also gets pulled up mid-incident when SU53 or a trace shows a failed check on an object that PFCG never proposed for that transaction, meaning the SU24 entry is missing, set to 'No Check', or was never re-read into the role after being added. It is a build-time and design-time tool, not something consulted during normal transaction execution.

In SE16, open USOBX_C and filter on the transaction code field to see every authorization object registered for it and its check indicator. Cross-check the same transaction and object combination in USOBT_C to see the proposed field values. Compare against the standard USOBX and USOBT entries for the same key to see whether a customer override exists and differs from what SAP delivers. If an object is missing from USOBX_C entirely for that transaction, PFCG never proposed it and no manual addition happened either.

SU24 itself is structurally unchanged on S/4HANA. The check indicator model, the USOBX_C/USOBT_C customer tables, and the SU25 upgrade comparison workflow all work the same way. Fiori apps have their own authorization mapping through app-to-object assignments that sit alongside classic transaction-based checks, but any classic transaction code still maintained through PFCG uses SU24 exactly as before. No version-specific behavior change to call out here.

Functional ownership sits with the security or role design team, since SU24 decisions drive what a role actually contains. ABAP development flags new or changed authorization objects introduced in custom code so security can register them. A clean handover states the transaction code, the object and field values expected, and trace evidence from SU53 or ST01 showing the actual runtime check, not just a description of the symptom.

SU25 is the natural next stop, since it wraps the SU24 comparison logic into an upgrade workflow and is where missed merges after a support package usually surface. PFCG is the consumer of everything SU24 produces and is where the disconnect between updated proposals and unchanged existing roles becomes visible. SU21 is worth knowing for anyone defining new custom authorization objects that later need SU24 entries. SUIM and ST01 round out the troubleshooting side, showing what a user's buffer actually contains versus what SU24 says should have been proposed.