SAP SU24 Tutorial (Part 1)

SU24 maintains what SAP calls the transaction-to-authorization-object check relationship, sometimes referred to informally as the authorization default values or the USOBT/USOBX data. Every SAP transaction code, when executed, potentially triggers a series of AUTHORITY-CHECK statements embedded in the program logic. Each AUTHORITY-CHECK references a specific authorization object (for example a financial document object or a materials management object) and specific field values. SU24 does not create these AUTHORITY-CHECK statements in the code - those are hardcoded by SAP developers or custom ABAP developers. What SU24 controls is the check indicator and proposed values for each transaction-object pairing: whether the check is enforced (Check), enforced but not proposed into new roles (Check/No Maintain), skipped entirely for that transaction (No Check), or proposed with default field values when you drag the transaction into a PFCG role menu.

This matters immensely for role design. When a security consultant builds a role in PFCG and adds transactions to the role menu, PFCG reads SU24 data to automatically populate the authorization object tree with proposed objects and values. Without correct SU24 maintenance, roles either end up missing critical objects (causing users to hit authorization errors) or get flooded with irrelevant objects (violating least privilege and creating audit noise). SU24 is essentially the template layer that sits between raw ABAP authority checks and the human-friendly PFCG role building experience.

The underlying data is stored in tables that are commonly referenced by name in documentation - USOBT (SAP standard defaults) and USOBX (indicates whether a check is relevant and how it should be treated) - though the exact internal handling can vary by release and consultants should treat table names as descriptive knowledge rather than something to query directly for role building purposes; SU24 is the supported interface.

From a governance perspective, SU24 is where organizations often deviate from SAP defaults to enforce their own control philosophy. For example, a company might change a check indicator from No Check to Check for a sensitive object because their audit and compliance team requires that authorization to always be validated, even if SAP's default assumed it wasn't necessary for that transaction. Conversely, an organization might suppress a proposal (Check/No Maintain) for an object they intentionally control through a different mechanism, such as organizational level restrictions maintained centrally.

Beginners frequently confuse SU24 with PFCG. PFCG is where you actually build and generate roles with specific values (e.g., which company codes, which document types). SU24 is upstream of that - it defines what gets proposed and how strictly it is checked, but it does not itself assign values to a live role. Understanding this separation is the first step to understanding role design, SOD analysis, and why two different roles built from the same transaction list can end up with very different authorization footprints if SU24 was customized differently in the systems where they were built.

During a green-field S/4HANA implementation, the security team noticed that after building the first wave of finance roles in PFCG, users could execute several sensitive transactions without any authorization restriction on company code. Investigation traced this to SU24 entries where the check indicator for the relevant object was set to No Check for those transactions in the client used for role building. The team had to review and correct the check indicators before regenerating the affected roles, then re-test with representative users in the QA client.

• Assuming SU24 changes automatically update authorization values in already-generated PFCG roles without re-running the role menu update and regenerating the profile
• Treating SU24 as a place to assign actual field values for a specific business unit instead of using it only for defaults/proposals
• Not realizing that a transaction removed from a role menu does not remove authorization objects already added manually to the role
• Confusing the check indicator meaning, especially mixing up Check/No Maintain with No Check, which have very different security implications
• Editing SU24 directly in a productive client instead of following transport-based change management

• Review and align SU24 defaults with your organization's control philosophy before large-scale role building begins
• Document every deviation from SAP-delivered check indicators with a business or compliance justification
• Transport SU24 changes through a controlled landscape rather than editing directly in role-building or production clients
• Re-run the PFCG role menu update and regenerate profiles after relevant SU24 changes so roles reflect the corrected proposals
• Periodically compare SU24 settings across systems (ECC vs S/4HANA, or across landscape tiers) to catch drift

Interviewers commonly ask candidates to explain the difference between SU24 and PFCG, and to describe what happens technically when a transaction is added to a role menu. Strong candidates explain that SU24 supplies the proposal data (check indicator plus default field values) that PFCG reads to pre-populate the authorization object list, and that this proposal can be manually adjusted afterward inside PFCG without changing the underlying SU24 template. They should also be able to explain the practical difference between the check indicator options and give an example of when an organization would deviate from SAP's shipped default.