SU24 is not just a configuration transaction code. It plays a direct role in shaping how authorization checks behave when a user actually executes a transaction or launches a Fiori app.
If authorization objects define what SAP checks, SU24 defines what SAP expects to check.
What Really Happens at Runtime
When a user executes a transaction, SAP does not evaluate roles assigned to the user. It evaluates authorization objects and the field values maintained within them. This is executed internally through the AUTHORITY-CHECK mechanism.
Wait! There is a deeper layer to this.
The system needs to know which authorization objects are relevant for that transaction in the first place. That mapping does not come from roles. It comes from the application logic and is reflected through SU24 check proposals.
For those who are new to check proposals, here is what SU24 provides:
- Check / No - Authorization object is checked while tcode execution, but No authorization object field value is proposed when tcode is added to Role Menu.
- Check / Yes - Authorization object is checked while tcode execution and the authorization object automatically gets pulled in the role when the tcode is added to Role Menu. The authorization which is pulled may or may not have some field values depending on what is maintained in SU24 in that object for that tcode.
- Do Not Check - The object is not checked even though it may be in the ABAP Code.
For a detailed explanation on check proposals, check SAP’s documentation which explains that authorization checks are performed against objects and field values during execution, reinforcing that runtime control is object-driven rather than role-driven:
Other references:
An interesting article on SU24 check proposals by Alessandro Banzer:
https://www.linkedin.com/pulse/authorization-proposals-transaction-su24-alessandro-banzer/
An interesting article on SU24_AUTO_REPAIR:
https://togglenow.com/learnings/learningharsitha/how-to-use-transaction-code-su24_auto_repair/
More about authorization variants:
https://community.sap.com/t5/technology-blog-posts-by-sap/getting-back-to-standard-proposals-with-su24-authorisation-variants/ba-p/13543285
https://togglenow.com/learnings/learningstuti/authorization-variants-in-pfcg/
The Real Role of SU24
SU24 maintains check proposals for each transaction. These proposals define which authorization objects are relevant and how they should be treated during role maintenance.
More importantly, SU24 acts as a bridge.
It connects what the application checks, what gets designed into roles, and what ultimately gets enforced at runtime. When SU24 is aligned correctly, these layers remain consistent. When it is not, the access model starts to drift.
Where Things Start to Break
In many environments, SU24 is either left in its default state or modified without a structured approach. Over time, this creates a subtle but serious problem.
Roles begin to diverge from what the application actually checks.
You start seeing access issues that do not make sense on the surface. A user has the role, but the transaction fails. Another user has limited roles, but access appears broader than expected.
These are not random issues. They are symptoms of SU24 misalignment.
How it impacts SoD and Risk Analysis
Most SoD analysis is performed at the transaction level. That is how risk is modelled in many GRC implementations.
But risk does not materialize at the transaction level. It materializes at the authorization level.
If SU24 is not aligned, the authorization objects required at runtime may not be accurately reflected in roles. This creates a disconnect between what is analyzed and what is actually possible in the system.
The result is familiar. False positives increase. Real risks get diluted. Business teams lose confidence in the output.
The S/4HANA and Fiori Reality
In S/4HANA landscapes, SU24 becomes even more important.
Fiori apps operate through multiple layers, including OData services and underlying authorization checks. SU24 helps bring structure to these checks by mapping them to role design.
When SU24 is not maintained properly, access becomes inconsistent. Roles appear correct, but runtime behavior tells a different story.
This is where organizations shift from structured design to reactive fixes.
SAP Fiori for SAP S/4HANA –Finding authorization objects for SAP Fiori apps with SU24
What Needs to Change
SU24 should not be treated as a one-time configuration. It needs to be part of ongoing security governance.
Organizations that mature in this area start aligning SU24 with custom developments, validating it during role redesign, and revisiting it when business processes evolve.
The shift is subtle but important.
Instead of designing roles in isolation, design them with a clear understanding of what the system actually checks.
Closing Perspective
SU24 does not get much attention in most SAP security discussions. It is rarely part of audit conversations and almost never part of executive reporting.
But it sits at a critical junction between application logic and access control.
When it is aligned, access behaves predictably. When it is not, organizations spend time fixing symptoms instead of addressing the root cause.
The difference is not complexity. It is awareness!