SU22 — Maintain SAP Authorization Default Data
SU22 is used to display and, in development contexts, maintain SAP-delivered authorization default proposals used by the Profile Generator. It is most useful when developers or security architects analyze application authorization proposals and distinguish SAP defaults from customer-specific SU24 values. For reliable SAP support, capture the exact system, client, user, time and object context first, then use the transaction's evidence before making configuration or data changes.
Verified practitioner reference for SU22 — Maintain SAP Authorization Default Data. It explains what the transaction does, when it is appropriate, which parameters and evidence matter, how to use it safely, common diagnostic traps, and how its role changes or remains relevant in S/4HANA.
Published 19 Sept 2026· 639 words
Diese Seite ist noch nicht auf Deutsch verfügbar.
Purpose
display and, in development contexts, maintain SAP-delivered authorization default proposals used by the Profile Generator. The transaction is most valuable when used as part of an evidence chain rather than as a shortcut. Start from the exact business or technical incident, preserve its user, time, system and object context, and distinguish display/analysis functions from actions that can alter system state.
When it is used
SU22 is typically used when developers or security architects analyze application authorization proposals and distinguish SAP defaults from customer-specific SU24 values. Consultants also use it during project testing and post-change validation because a repeatable selection gives objective evidence. In production, keep the initial scope narrow and widen it only after confirming that the first result matches the reported incident.
How to use it in practice
- Select the exact application whose defaults are being analyzed.
- Understand whether the system is SAP development or a customer system before attempting maintenance.
- Compare delivered SU22 data with customer-specific SU24 values.
- Use authorization trace evidence when defining defaults for custom applications.
- Transport/customize through the supported authorization-default process.
Key data objects
These are the most useful anchors for work in SU22. Capture them in incident notes or test evidence so another consultant can reproduce the same result.
- application type/name — verify the exact value and its relationship to the affected execution or business object.
- authorization object — verify the exact value and its relationship to the affected execution or business object.
- check indicator — verify the exact value and its relationship to the affected execution or business object.
- default status — verify the exact value and its relationship to the affected execution or business object.
- proposed field values — verify the exact value and its relationship to the affected execution or business object.
How to prove it in the data
Build a reproducible before-and-after proof. Capture the exact selection or object, record the status, log or result that demonstrates the issue, then apply one controlled correction and repeat the same check. Correlate with neighboring SAP logs, documents or repository objects where needed. A successful retry with changed input is not the same as proving the original root cause.
ECC vs S/4HANA
SAP documents SU22 as the delivered/development authorization-default layer and SU24 as the customer-maintained layer, including modern ABAP application types. Availability of a classic transaction does not automatically make it the preferred implementation pattern for new work; distinguish support compatibility from clean-core and cloud-oriented design guidance.
Common pitfalls and how to diagnose them
- Editing SU22 in a customer landscape when SU24 is the intended customer-maintenance layer. Validate the exact object, user, timestamp and release context before applying a fix.
- Marking every traced object as mandatory. Validate the exact object, user, timestamp and release context before applying a fix.
- Using wildcard proposals that weaken role design. Validate the exact object, user, timestamp and release context before applying a fix.
Whose problem this is
Primary ownership is usually with the SECURITY GRC team. Bring in Basis, Security, functional or development specialists only when the evidence crosses those boundaries. A high-quality escalation includes the exact transaction, selection or object, timestamp, expected result, actual result and checks already completed.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/su22ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.