SU25 — SU25 Authorization Default Values Upgrade Wizard

SU25 is the transaction that performs the initial copy and the subsequent upgrade comparison of authorization default values from SAP's delivered reference tables into the customer's working tables. It does not let anyone edit a single transaction's check indicators directly; that maintenance happens in SU24. The structural fact that explains most confusion: SU25 is a migration and reconciliation wizard run at discrete points in the system lifecycle, not a day-to-day maintenance screen. Its output determines what SU24 shows and what PFCG pulls in when a role menu references a transaction, so a system where SU25 has never been run correctly, or was skipped at an upgrade, has a stale or empty foundation underneath every role built afterward.

SU25 is run exactly twice in the normal lifecycle of a system: once during initial setup, before anyone starts building PFCG roles, to populate the customer check indicator tables from the SAP delivered ones; and again after every support package, enhancement pack, or S/4HANA conversion, to compare what SAP changed in its shipped defaults against what the customer already customized in SU24. A consultant reaches for SU25 specifically at those two moments, never as a substitute for SU24 when adjusting an individual transaction's authorization proposal, and never as a substitute for PFCG when a role itself needs authorization values changed.

Open SE16 on USOBX_C and filter by transaction code to see the current check indicator for each authorization object tied to it; compare against USOBX filtered the same way to see whether SAP's shipped indicator diverges from what the customer table holds. Join the transaction code and object fields against USOBT_C to pull the associated field value proposals and compare with USOBT. A mismatch between USOBX and USOBX_C for a transaction that was recently upgraded is the direct evidence that SU25 step 2A/2B was never run or was left incomplete for that transaction.

SU25 exists in the same form on S/4HANA and is run the same way after an S/4HANA conversion or a subsequent upgrade, since the underlying mechanism of comparing delivered check indicator tables against customer tables has not changed. There is no dedicated Fiori app for it because it is a lifecycle migration wizard rather than an operational transaction; it stays a backend SAP GUI activity performed by the security team at conversion and upgrade time.

This is a security team activity, run by whoever owns the authorization concept, with Basis coordinating timing around the upgrade or conversion cutover. Functional module leads should be consulted before accepting or rejecting individual check indicator changes in step 2B/2C, since they know whether a newly introduced check reflects a real control requirement. A good handover includes the list of affected transactions from step 2C and the corresponding list of PFCG roles still pending regeneration.

Read SU24 next, since it is where the values SU25 populates get maintained transaction by transaction and it is the tool consultants confuse SU25 with most often. Follow with PFCG to understand how role generation consumes the check indicators SU25 and SU24 maintain, and why profile regeneration is the missing final step after an SU25 run. SUIM is useful afterward for tracing which roles and users are actually affected by a given authorization object once SU25 has surfaced a change.