top of page
Search

S_TABU_DIS authorizations: Relic with Risk

  • Writer: Daniel Mattke (Gastautor)
    Daniel Mattke (Gastautor)
  • Aug 25
  • 3 min read

Guest column by Daniel Mattke from WTRKNT

ree

RKNT


What is S_TABU_DIS in SAP and how does it work?


S_TABU_DIS is one of the oldest SAP authorization objects. It controls access to table content via table authorization groups maintained in TDDAT. Both the activity (ACTVT) and the group assignment of the table are checked. In many transactions, the check runs via VIEW_AUTHORITY_CHECK.

Originally, S_TABU_DIS was checked first, while S_TABU_NAM was only used afterward for individual table checks. In newer releases, the order has partly changed, which is why companies should regularly review their authorization concepts.


Why S_TABU_DIS poses a risk to SAP security


In the 1990s, S_TABU_DIS was a practical tool—it simplified role maintenance and kept performance stable. Today, security and compliance requirements are significantly higher. The coarse granularity of the object leads to oversized authorizations. Granting access to one group often gives unintended access to many other tables within the same group.

This violates the principle of "Least Privilege" and makes control complex. A prime example is group MA, which includes over 600 tables in many systems—far more than a single user needs.


Critical examples: USR02, SPWD and &NC&


One particularly sensitive case is table USR02, which stores user master data and password hash values. In many systems, it is part of group SPWD, which also includes other security-relevant tables like USH02. If S_TABU_DIS is granted too broadly here, users may gain access to confidential data or manipulate user management.


In financial areas, inappropriate authorizations can have serious consequences. Changes to table T030, which controls account determination, directly affect postings and financial statements.


Special attention should also be given to group &NC&. It acts as a catch-all for all tables not explicitly assigned to a group. Granting access to &NC& via S_TABU_DIS suddenly opens access to thousands of unclassified tables. This setup has no place in a productive system.


Transparency issues and audit relevance


A central issue is the lack of traceability. It is often difficult for administrators to identify which tables belong to which group. Additionally, group assignments may change between releases. What appears harmless today could be highly sensitive tomorrow. This lack of transparency causes S_TABU_DIS to regularly appear in audit reports.


SAP provides built-in tools like TDDAT and STDDAT to help. While TDDAT shows group-to-table assignments, STDDAT enables consistency checks and comparisons with SAP references. The report SUSR_TABLES_WITH_AUTH can also be used to track which roles and users have access to specific tables via S_TABU_DIS or S_TABU_NAM.


S_TABU_NAM as an alternative to S_TABU_DIS


SAP has long responded by offering S_TABU_NAM as a more granular alternative. It allows authorizations for individual tables. While role maintenance becomes more complex, transparency and audit readiness improve significantly.


Additionally, S_TABU_CLI supports cross-client table maintenance, and S_TABU_LIN enables row-level restrictions based on organizational criteria.

Technological developments also point clearly in this direction. In S/4HANA, many scenarios previously handled via generic table maintenance are now managed via Fiori apps with their own authorization checks. As a result, generic table access is losing importance, and S_TABU_DIS is increasingly seen as a relic of the past.


Practical best practices for SAP table authorizations


In practice, it is crucial to consistently eliminate &NC& from productive systems and to explicitly assign unclassified tables. Sensitive tables should only appear in tightly defined roles. Changes should be reserved for administrators only.


Business-specific table requirements should be implemented using S_TABU_NAM, not broad group assignments. Even standard groups like SC or SS should only be used after careful review. Regular analysis using TDDAT and STDDAT, along with evaluations via SUSR_TABLES_WITH_AUTH, ensures transparency and provides strong preparation for audits.


Conclusion: Why modern SAP authorization concepts should move beyond S_TABU_DIS


S_TABU_DIS was useful once, but today it represents a risk. Organizations serious about SAP security and compliance rely on S_TABU_NAM, avoid &NC&, keep groups lean, and regularly review table assignments. The message for decision-makers is clear: S_TABU_DIS is not a technical detail—it is a compliance risk that will stand out in any audit.


Support with SAP authorizations and compliance


Analyzing and cleaning up authorization objects like S_TABU_DIS requires experience, deep knowledge, and a solid understanding of regulatory requirements. The presence of S_TABU_DIS in assigned authorizations is often a clear indicator of an outdated and overgrown authorization concept.


Do you need any help? Feel free to get in touch with us.




 
 
 

Comments


bottom of page