I’ve highlighted the top 10 critical authorization objects in the article - Top 10 Critical SAP Authorization Objects That Create Real Security Risks (Backdoors, Escalation & Data Exposure). If you haven’t read it yet, you can explore it here: https://sapsecurityexpert.com/sap-s4hana-security/sap-critical-authorization-objects-security-risks (Member Exclusive content).
Individually, these authorization objects are already classified as critical due to their ability to enable elevated access, data exposure, or control over system behaviour. However, the real risk in SAP environments does not lie in isolation, it emerges when these objects are combined and interact.
When certain authorization objects coexist within the same role or user, they create compound attack paths that significantly amplify risk. What appears as controlled access at an individual level can quickly turn into privilege escalation, backdoor access, or unrestricted data exposure when combined, making these scenarios far more dangerous and often harder to detect.
A user may not have SAP_ALL. Roles may appear well designed. GRC controls may be in place.
Yet, when certain authorization objects are combined, often unintentionally - they create powerful attack paths that enable privilege escalation, data exposure, and system control.
This article breaks down the top 5 dangerous combinations of SAP authorization objects, how they are exploited, and how to mitigate them effectively.
These combinations are frequently observed in SAP audits and are common root causes of privilege escalation and data exposure in real-world environments.
The Hidden Problem in SAP Security
Most access reviews and audits evaluate authorization objects in isolation.
- Which users have authorization S_RFC with * value?
- Which user has Development or Debug access with S_DEVELOP authorization object?
- Is S_TABU_DIS properly restricted?
Attackers and experienced auditors do not evaluate access in isolation. They analyze how permissions can be chained together to create execution paths.
This is where real risk lies:
- Execution + data access
- Background processing + privileged identity
- Trusted connections + remote execution
These combinations create backdoors that are not visible in standard role design reviews.
Top 5 Dangerous Combinations
The table below highlights the most dangerous combinations of SAP authorization objects that can create hidden backdoors, enable privilege escalation, and expose sensitive data:
Individually controlled, these objects may appear low risk, but in combination, they create high-impact security vulnerabilities.
| Combination | Risk Type | Why Dangerous | Key Impact |
|---|---|---|---|
| S_RFC + S_PROGRAM + S_DATASET | Remote Execution + Data Exfiltration | Enables execution of programs and access to application server files | Data extraction, persistence, unauthorized file access |
| S_DEVELOP + S_TABU_SQL | Code-Level Backdoor | Allows modification of code and direct table access bypassing controls | Undetected data access, logic manipulation |
| S_BTCH_JOB + S_BTCH_NAM + S_PROGRAM | Privilege Escalation | Jobs can be scheduled to run as privileged users executing sensitive programs | Silent execution, privilege escalation |
| S_RFC + S_RFCACL | Lateral Movement | Combines remote execution with trusted authentication (no password) | Cross-system compromise, identity impersonation |
| S_ADMI_FCD (PADM) + S_TABU_DIS / S_TABU_NAM | Control Bypass | Overrides table-level restrictions and enables access to sensitive tables | Full data exposure, unauthorized changes |
1. S_RFC + S_PROGRAM + S_DATASET
Remote Execution + Program Access + File Access
- S_RFC → Execute remote function modules
- S_PROGRAM → Execute ABAP programs
- S_DATASET → Read/write files at OS level
The combination of S_RFC, S_PROGRAM, and S_DATASET creates a powerful execution chain that extends beyond standard transaction controls. S_RFC enables remote function execution, S_PROGRAM allows direct execution of ABAP programs, and S_DATASET provides access to application server files at the OS level. Individually, these objects may appear justified for technical or integration purposes, but when combined, they form a complete execution and data exfiltration pathway.
In a real-world scenario, an attacker who gains access to a communication (RFC) user can invoke function modules, execute custom or existing programs, and read sensitive interface or application server files, all without relying on standard SAP transactions. This enables covert data extraction, unauthorized file access, and persistence mechanisms, often with minimal visibility.
To mitigate this risk, S_RFC should be restricted by function group (avoiding wildcard access), S_PROGRAM should be limited to approved programs only, and S_DATASET must be tightly controlled by file path and activity. Additionally, continuous monitoring of RFC users and file access is essential to detect and prevent misuse.
2. S_DEVELOP + S_TABU_SQL
Code Control + Direct Table Access
- S_DEVELOP → Modify or create programs
- S_TABU_SQL → Access tables via Open SQL
The combination of S_DEVELOP and S_TABU_SQL creates a high-risk scenario where users gain both control over application logic and direct access to database tables. S_DEVELOP allows modification or creation of ABAP programs, while S_TABU_SQL enables table access at the Open SQL level, bypassing traditional controls like S_TABU_DIS or S_TABU_NAM. Individually, these authorizations may be justified in development environments, but together they enable a code-level backdoor with unrestricted data access.
In a real-world scenario, a user with development access can modify a program to bypass AUTHORITY-CHECK, embed logic to read sensitive tables, and execute the program to extract data—all without triggering standard authorization restrictions. This results in undetectable data access, persistent backdoors embedded in code, and full control over business logic.
To mitigate this risk, S_DEVELOP should never be assigned in production, S_TABU_SQL must be strictly restricted, and all developments should go through controlled transports with mandatory code reviews. Regular audits of custom programs are also essential to ensure proper authorization checks are enforced.
3. S_BTCH_JOB + S_BTCH_NAM + S_PROGRAM
Background Execution + User Impersonation + Program Access
• S_BTCH_JOB → Schedule jobs
• S_BTCH_NAM → Run jobs under any user
• S_PROGRAM → Execute programs
The combination of S_BTCH_JOB, S_BTCH_NAM, and S_PROGRAM creates a high-risk execution pathway by combining background processing, user impersonation, and program execution. S_BTCH_JOB allows scheduling of background jobs, S_BTCH_NAM enables jobs to run under different user IDs, and S_PROGRAM permits execution of ABAP programs. Individually, these authorizations support legitimate operational needs, but together they form a silent privilege escalation mechanism that operates outside direct user interaction.
In a real-world scenario, a user can schedule a background job, assign it to run under a privileged user (such as one with SAP_ALL), and execute sensitive programs - all in the background. Since these actions are processed asynchronously, they often lack clear traceability to the initiating user, creating a low-visibility attack path. This can result in unauthorized execution and privilege escalation without immediate detection.
To mitigate this risk, S_BTCH_NAM should be tightly restricted to approved users, job scheduling and execution privileges should be segregated, and background jobs must be continuously monitored (e.g., via SM37). Additionally, execution of sensitive programs through background jobs should be controlled and audited.
4. S_RFC + S_RFCACL
Remote Execution + Trusted Authentication
- S_RFC → Execute backend logic
- S_RFCACL → Enable trusted RFC (no password)
The combination of S_RFC and S_RFCACL introduces a high-risk scenario by combining remote execution capabilities with trusted authentication. S_RFC enables execution of backend logic through Remote Function Modules, while S_RFCACL allows systems to trust each other for user authentication without requiring credentials. Individually, these are used for system integration, but together they enable password-less remote access across systems, significantly expanding the attack surface.
In a real-world scenario, if one SAP system is compromised and a trusted RFC relationship exists, an attacker can log into another connected system without credentials and execute functions remotely. This effectively enables lateral movement across the SAP landscape, allowing attackers to impersonate users and bypass authentication controls. The result is cross-system compromise with minimal resistance.
To mitigate this risk, trusted RFC configurations should be strictly limited, broad trust relationships must be avoided, and RFC activity should be continuously monitored. Regular reviews of S_RFCACL entries are essential to ensure that only necessary and secure trust relationships exist.
5. S_ADMI_FCD (PADM) + S_TABU_DIS / S_TABU_NAM
Admin Override + Table Access
- S_ADMI_FCD (PADM) → Overrides table restrictions
- S_TABU_DIS / S_TABU_NAM → Table access
The combination of S_ADMI_FCD (PADM) and S_TABU_DIS / S_TABU_NAM creates a critical control bypass scenario by overriding standard table-level restrictions. S_ADMI_FCD with the PADM value enables administrative override capabilities, while S_TABU_DIS and S_TABU_NAM provide access to table data based on authorization groups or specific table names. Individually, these objects serve administrative and functional purposes, but together they enable unrestricted control over table-level access, effectively bypassing established security controls.
In a real-world scenario, a user can leverage PADM to override restrictions and access sensitive tables such as USR* or HR data, allowing them to extract or modify critical information without being constrained by standard authorization checks. This results in complete data exposure, unauthorized data manipulation, and significant audit and compliance risks.
To mitigate this, PADM should never be broadly assigned, table access must be tightly restricted, and sensitive table activity should be continuously monitored. Regular reviews of administrative authorizations are essential to ensure that such override capabilities are limited to strictly controlled scenarios.
Why These Risks Are Often Missed
Security teams often focus on individual authorization objects rather than how they interact in combination. Standard GRC rules may not detect all risky combinations, especially when access spans multiple layers such as execution, data access, and administrative control. In addition, there is often a lack of cross-object analysis and limited monitoring of technical or communication users, where many of these risks originate.
As a result, organizations operate under a false sense of security, where controls appear effective on the surface, but critical risk paths remain hidden within authorization combinations.
How to Detect These Risks
Detecting these risks requires a shift from traditional access reviews to a combination-based analysis approach. Instead of evaluating authorization objects in isolation, organizations should assess how multiple high-risk objects coexist within the same user or role and whether they create potential attack paths. This includes identifying users who hold combinations of execution, data access, and administrative privileges.
In addition, organizations should analyze usage logs across key areas such as RFC activity, background jobs, and program execution to detect abnormal patterns. Continuous monitoring of critical activities, especially for technical and communication users, is essential to identify misuse early. By combining access analysis with behavioural monitoring, organizations can effectively uncover and mitigate hidden risks within authorization combinations.
Conclusion
SAP Security risks are rarely caused by a single authorization object. They emerge when multiple objects interact in unintended ways.
Attackers don’t exploit roles - they exploit combinations.
If these combinations are not identified and controlled:
In many cases, these risks remain undetected until security incidents or detailed forensic audits are performed.
- Backdoors remain hidden
- Privilege escalation becomes possible
- Sensitive data remains exposed
Strong SAP Security requires:
- Understanding how objects interact
- Restricting access at multiple layers
- Continuously monitoring critical activities
In SAP Security, risk is not created by what users have - it is created by how their access can be combined.
If these combinations are not proactively identified, even mature SAP environments remain vulnerable.
Related Articles:
• Common SAP Security Audit Findings and How to Fix Them