In most SAP security discussions, the focus remains on transactions - who can post invoices, create users, or execute programs. However, in every major audit and breach investigation I’ve been involved in, the root cause has rarely been transactions. It has almost always been uncontrolled access at the table level.

The S_TABU_* authorization objects govern this layer. They sit beneath the application, often unnoticed during role design, yet they determine whether your controls actually work, or can be bypassed entirely.

This article is based on real-world SAP security assessments and audit observations, where table-level access repeatedly emerged as a critical risk area across industries.

The Real Problem: A Control Layer Most Organizations Don’t See

Table-level access exists outside the comfort zone of most business controls. It does not follow approval workflows, it does not always generate meaningful audit logs, and it can be exercised using standard SAP tools that look completely legitimate.

This is why regulators and security researchers repeatedly highlight it as a systemic weakness. Enforcement observations from the U.S. Securities and Exchange Commission (SEC) have shown cases where financial data was altered directly at the database level, bypassing all configured controls. In such scenarios, organizations were left with incomplete audit trails and weakened compliance positions.

At the same time, research from Onapsis and insights published on SAPinsider consistently point to a pattern: attackers rarely need sophisticated exploits when misconfigured authorizations already provide a direct path to sensitive data.

From a privacy standpoint, this risk becomes even more severe under regulations like the General Data Protection Regulation (GDPR), where uncontrolled access to HR or personal data tables can lead to significant penalties.

Across multiple SAP audits, including SOX-driven control reviews and GDPR impact assessments, a consistent pattern emerges:

60–80% of high-risk findings relate to authorization design issues, with table-level access being a major contributor.

Understanding the S_TABU_* Objects in Practice

To understand the risk, it’s important to look beyond definitions and focus on how these objects behave in real systems.

SAP Table Authorization Risk Matrix (Audit Perspective)

The following matrix is based on real audit observations and exploitation patterns, not just theoretical authorization design. It highlights how different S_TABU_* objects behave in practice, especially when combined with tools like SE16N, SM30, and RFC integrations.

In multiple assessments, this exact pattern has been observed regardless of industry, system size, or SAP version. This consistency across environments highlights that the risk is structural, not incidental.

Image: S_TABU_* Authorization Object Risk Matrix

Table-level risk in SAP is driven not just by access, but by how that access bypasses application controls, audit visibility, and governance layers.

Let’s understand each of these objects and the risks associated with them.

S_TABU_DIS is the most commonly used table authorization control in SAP. In well-governed environments, it provides structured access through authorization groups. However, in real-world systems, it frequently becomes a source of risk due to poor group design and lack of periodic review.

To identify the tables vs authorization groups, you can utilize the table TDDAT. Below are the fields available in S_TABU_DIS

S_TABU_NAM takes this a step further by allowing restriction at the table level. It works along with S_TABU_DIS and further restricts authorization at table level. When this object appears in a role, it deserves immediate maintenance (update) rather than adding with * value. In audits, it has frequently been the reason users could access tables like PA*, USR*, AGR* etc., without any apparent justification.

S_TABU_CLI introduces a different dimension of risk. It governs access to cross-client tables, data that is not restricted to a single client but affects the entire system. Misuse here is not a localized issue; it can have system-wide consequences, impacting configurations across environments.

S_TABU_LIN is often misunderstood. It is intended to enforce row-level security, which sounds ideal from a compliance perspective. However, in reality, it is rarely implemented effectively. Most organizations either ignore it or configure it in ways that do not meaningfully restrict access.

S_TABU_SQL, which from an auditor’s perspective is one of the most concerning authorizations. It allows direct SQL-level interaction with the database, bypassing SAP’s application layer entirely. At that point, you are no longer dealing with controlled access, you are effectively granting unrestricted data manipulation capability.

S_TABU_RFC is an often-overlooked authorization object that governs table access via Remote Function Calls (RFCs), effectively extending SAP data access beyond the system boundary. While most security controls focus on what users can do within SAP, this object enables external systems, middleware, or scripts to interact with SAP tables remotely. When combined with RFC-enabled function modules such as RFC_READ_TABLE, it allows data extraction without any direct SAP GUI interaction, making it fundamentally different from traditional table access controls like S_TABU_DIS or S_TABU_NAM.

The real risk emerges in integrated landscapes where technical users are assigned broad authorizations to support interfaces. In such cases, S_TABU_RFC can enable large-scale, automated access to sensitive tables, including HR, financial, or user data - without triggering typical user-based monitoring. Because this access happens through system-to-system communication, it is often less visible, harder to trace, and not adequately covered in standard audit reviews or SoD analysis.

From an audit and security standpoint, S_TABU_RFC represents a shift from user-driven risk to integration-driven risk. If not tightly controlled, it can expose SAP data through external channels with minimal oversight. This is why organizations must not only review dialog user access, but also rigorously assess technical users, RFC destinations, and the scope of remote-enabled function modules, ensuring that table access via RFC is strictly limited, monitored, and justified.

Where Things Go Wrong: The Hidden Access Paths

The real issue is not just the presence of these objects, but how easily they can be exploited through standard tools.

Transactions like SE16N and SM30 are commonly used for legitimate purposes, yet they also provide a direct interface to table data. In several real-world cases, users leveraged SE16N, sometimes even in debug mode, to modify data without triggering expected controls. From an audit perspective, this creates a situation where actions are technically possible but operationally invisible.

Another recurring issue is the misuse of authorization groups. The placeholder group “&NC&” appears far too often in production systems, effectively acting as an open door to multiple tables. What starts as a convenience during development becomes a long-term security gap.

Read a detailed breakdown of how the “&NC&” authorization group introduces hidden risks in SAP security:

https://grcwithraghu.substack.com/p/part-2-the-hidden-risk-and-nc-and

Why This Risk Is Increasing in Modern SAP Landscapes

The risk associated with S_TABU_* authorizations is increasing as SAP landscapes evolve. Modern environments rely heavily on integrations, middleware, and cloud connectors, which expand the role of technical users and RFC-based access. At the same time, increased custom development through Z/Y tables and hybrid architectures across ECC, S/4HANA, and BTP further broaden the attack surface.

As SAP ecosystems become more interconnected, table-level access is no longer just an internal risk, it becomes part of the broader enterprise attack surface.

The Most Overlooked Risk: Z and Y Table Maintenance

While standard tables receive at least some level of scrutiny, the most critical vulnerabilities often lie in custom Z and Y tables.

In almost every SAP landscape, developers create custom tables to support business requirements, approval logic, pricing rules, workflow configurations, or integration mappings. These tables are then exposed through custom transactions using the Table Maintenance Generator.

On paper, this is standard practice. In reality, it introduces a significant risk.

Unlike SAP standard tables, custom tables do not come with predefined governance. Authorization checks are often inconsistently implemented, and in many cases, completely missing. I’ve seen environments where accessing a Z transaction was all it took to modify sensitive business logic, with no additional validation.

What makes this particularly dangerous is that these tables often control how the system behaves. Changing a configuration entry in a Z table can disable approvals, reroute workflows, or alter financial thresholds without raising any immediate red flags.

Even more concerning is that these risks are typically invisible to GRC systems. Most rule sets focus on standard transactions and objects, leaving custom tables outside the scope of SoD analysis. This creates a blind spot where conflicting access can exist without detection.

When S_TABU_NAM is combined with knowledge of table names, the situation becomes even more severe. Users can bypass custom transactions entirely and interact directly with the underlying tables, effectively turning poorly secured Z tables into backdoors.

A Realistic Scenario: How Controls Get Bypassed

Consider a typical finance user with access to SE16N/SM30 and a broadly defined S_TABU_DIS authorization group.

From a role design perspective, everything may appear compliant. The user does not have direct access to sensitive transactions, and SoD conflicts are resolved.

However, with table access in place, the same user can navigate directly to underlying tables and modify entries. These changes bypass workflows, avoid standard validations, and may not generate meaningful logs.

The result is a system that appears secure on the surface but is fundamentally vulnerable underneath.

What Experienced Auditors Look For

In practice, reviewing S_TABU_* is less about checking whether the objects exist and more about understanding how they are used.

The presence of S_TABU_NAM, unrestricted S_TABU_DIS groups, or any assignment of S_TABU_SQL outside technical roles immediately raises concern. Similarly, the existence of Z table maintenance transactions without proper authorization checks is often a strong indicator of deeper control weaknesses.

More importantly, experienced auditors look for alignment between intended controls and actual capabilities. If users can achieve outcomes through tables that they cannot achieve through transactions, the control framework is not functioning as designed.

Strengthening Table Level Security

Securing S_TABU_* authorizations does not require new tools, it requires better control discipline and visibility.

Start by identifying which critical tables can be accessed and by whom, rather than focusing only on roles. Restrict high-risk objects such as S_TABU_NAM, S_TABU_SQL, and S_TABU_RFC to tightly controlled scenarios. Ensure that authorization groups are actively governed, not treated as placeholders.

Extend your control framework to include Z/Y tables and RFC users, areas that are often excluded from traditional GRC analysis but frequently exploited in real-world scenarios.

This perspective is based on hands-on experience across SAP security assessments, audit reviews, and remediation programs, where table-level access consistently emerged as a critical control gap.

Common Misconception: “We Have GRC, So We’re Covered”

One of the most common misconceptions in SAP security is that implementing GRC automatically secures the system. In reality, most GRC rule sets focus on transactions and business processes, not table-level access.

This creates a dangerous gap where users may appear compliant from a GRC perspective while still having the ability to access or manipulate sensitive tables directly.

In several audits, critical findings emerged not from transaction conflicts, but from unrestricted S_TABU_* access that existed completely outside GRC visibility*.

Conclusion

S_TABU_* authorization objects are not just technical controls, they define the true security boundary of your SAP system.

  • Organizations that focus only on transactions secure the surface. 
  • Organizations that control table access secure the foundation.

And in SAP security, it is always the foundation that determines whether your controls hold or collapse.

If you are reviewing SAP security today, start not with transactions, but with tables. That is where the real control story begins.

Additional References