SU25: Upgrading Authorization Proposals the Right Way

SU25 is the transaction for updating the authorization proposal data after an SAP upgrade or support package installation. It is one of the most commonly skipped post-upgrade steps, and its absence is a frequent root cause of both missing access and excess access in systems that have been through upgrades.

What SU25 Does and Why It Matters

When SAP releases an upgrade or support package, the set of authorization checks performed by transactions can change. New objects may be added to existing transactions. Field value requirements may be modified. Entirely new transactions may be introduced.

The authorization proposal — the default authorization data that PFCG uses when you maintain a role — is stored in the customer table USOBT_C. The SAP-delivered default proposals are stored in USOBT. After an upgrade, USOBT has been updated with SAP's new recommendations, but USOBT_C — which is what PFCG actually reads — has not yet been updated. SU25 synchronises the customer table with the new SAP-delivered content.

Skipping SU25 means your roles are built from outdated proposals. Roles regenerated after an upgrade may be missing authorization objects for new checks, causing access failures. Or they may still include objects for checks that no longer exist, granting access that was intended to have been removed.

USOBT_C and USOBX_C

USOBT_C maps transaction codes to the authorization objects that should be included in roles containing those transactions. USOBX_C controls whether each object is included automatically (check status A), manually (check status M), or not included (check status N) in proposals.

These tables are the authorisation proposal database. SU25 compares SAP's current USOBT table against your USOBT_C and presents the differences for review. Understanding these tables is important because SU25's comparison output can be dense — knowing what you are looking at speeds up the process significantly.

The Five Steps

SU25 presents a five-step wizard. The steps are sequential — do not skip forward.

Step 1 imports the new SAP standard authorization data from USOBT into a comparison table. This step is read-only and should always be run first. It establishes the baseline for the comparison.

Step 2 compares SAP's new proposals (USOBT) against your current customer proposals (USOBT_C) and presents the delta. This is the step that requires the most attention — see below.

Step 3 applies the new proposals from USOBT into USOBT_C for transactions where you have not made customer-specific adjustments. SAP's new defaults overwrite the old defaults for unmodified entries.

Step 4 addresses transactions where your USOBT_C entries differ from SAP's new proposals. You review each difference and decide whether to accept SAP's new proposal or retain your customisation.

Step 5 updates the role menu checks — verifying that transactions in existing roles still have valid authorization proposals after the update.

Step 2 in Detail: The Comparison

Step 2's output categorises differences into new transactions added by SAP, transactions where SAP has changed the proposed authorization objects, and transactions where you have made customer-specific modifications that now differ from SAP's updated proposals.

New transactions (green) are straightforward — add their proposals to USOBT_C. Changed proposals for unmodified transactions (yellow) can usually be accepted wholesale. The cases requiring careful review are the ones where SAP has changed a proposal for a transaction you have customised.

For each customised transaction with a proposal change, compare SAP's new proposal to your current one. Identify whether SAP has added new authorization objects, removed objects, or changed recommended field values. Decide whether to accept SAP's change, retain your customisation, or merge the two. Document your decision for each case — this documentation becomes important when the next upgrade happens.

Common Mistakes

The most common mistake is running SU25 and accepting all defaults without reviewing the differences. This overwrites customer-specific adjustments without preserving the reasoning behind them, creating a new set of access problems.

The second most common mistake is running SU25 partially — completing Steps 1 and 2 but not Steps 3 through 5. The comparison without the update accomplishes nothing, and the roles remain out of sync with the new proposals.

The third mistake is running SU25 but not regenerating affected roles afterward. Updating USOBT_C changes the proposal data, but existing roles are not automatically updated — they still contain the old generated profile. Roles must be regenerated in PFCG for the updated proposals to take effect.

After SU25: Role Regeneration

After SU25 is complete, identify which roles are affected by the proposal changes. The SU25 output includes a list of affected transaction codes — cross-reference these against your roles using PFCG or the role management reports in SU10.

Regenerate each affected role in PFCG. Review the regenerated authorization data before saving — PFCG will flag any new authorization objects added by the proposal update. For each new object, verify that the field values are appropriate before activating the role.

Test the affected roles before deploying to production. The post-SU25 regeneration cycle is an excellent opportunity to have the business verify that the roles still behave as expected.

> Editorial note: SU25 behaviour and the specific steps available vary between SAP releases. Consult SAP Note 1539556 (SU25 documentation) for your specific release. Always run SU25 first in a non-production system.