For some, SE16 is an unfamiliar transaction code. For SAP administrators, it is part of daily life — and often, unfortunately, for others too. This article covers what SE16 does, how many variants exist, and why access to it needs to be carefully controlled.

What Does SE16 Do?

SE16 (Data Browser) is a transaction that provides direct access — primarily read-only, but in some configurations also write — to all tables in the SAP database. This applies to all ABAP-based SAP systems. Non-ABAP platforms such as SuccessFactors or SAP Cloud Platform are not in scope.

In practical terms: with SE16, any data stored in the system is accessible. This includes:

• Material lists, including costs and all related data
• Bills of materials in every detail
• Customer and vendor master data in full
• Payroll data and personal data (in SAP HR systems)
• Any other information stored in the system

Even in read-only mode, unrestricted SE16 access is a data confidentiality risk — particularly in the context of internal data policies and GDPR compliance for personal data processing. If it can be avoided, it should be.

How Many Versions of SE16 Exist?

The SE16 family has evolved considerably over time. Beyond the original SE16, SAP has released multiple enhanced versions with additional functionality — most notably SE16N. There are also related transactions such as SE11 and SE17, and dozens of table-specific variants.

A non-exhaustive list of SE16* transactions includes:

• SE16 — Data Browser
• SE16H — General Table Display
• SE16N — General Table Display
• SE16N_ROLE — General Table Display
• SE16S — General Table and Value Search
• SE16SL — Field-Based Table and Value Search
• SE16T — Access Search Functions (useful for searching tables or transactions by description)
• SE16S_CUST — Customizing: Tables and Value Search
• SE16_BKPF / SE16_BSEG — Data Browser for accounting documents
• SE16_KNA1 / SE16_LFA1 — Data Browser for customer and vendor master data
• SE16_MARA / SE16_MARC — Data Browser for material master
• SE16_SKA1 / SE16_SKB1 — Data Browser for GL account master
• …and many additional table-specific variants

Less well-known alternatives with different naming conventions also exist — for example RSSG_BROWSER — and also provide direct table access. Programs and function modules associated with SE16* transactions are equally critical: for example RK_SE16N and RSDU_CALL_SE16.

Two variants worth highlighting for their search capabilities:

• SE16T — allows searching for tables or transactions by description using "Find Transactions" and "Find Tables".
• SE16SL — allows searching by content across tables.

The SE16N Backdoor

A common argument for assigning SE16 is: "It's read-only — we can safely give it out." In most cases this is true. But not always, and the distinction matters.

Shortly after releasing SE16N, SAP included a hidden edit mode activated by the parameter &sap_edit. Once this backdoor became publicly known, SAP blocked it. However, the program RKSE16N_EDIT still allows administrators to explicitly enable or disable this edit functionality — meaning the capability remains present in the system.

Changes made through SE16N are logged in tables SE16N_CD_KEY and SE16N_CD_DATA. It is worth noting that these tables can themselves be modified.

Why SE16 Is a Security Risk

SAP is designed around transactional segregation: users are assigned specific transactions that correspond to their business responsibilities. SE16 bypasses this model entirely. Assigning SE16 is like opening a special door that gives access to data well beyond the boundaries of the transactions the user was formally authorized to use.

Two compounding factors make this especially critical:

• If the user also holds debug authorization (S_DEVELOP with change activity), direct data modification becomes possible.
• Even read-only access creates GDPR exposure wherever personal data is stored in the system — which in SAP HR environments means virtually every table.

SE16N_EMERGENCY: Controlled Access for Exceptional Cases

When emergency modifications via SE16N in production are unavoidable, SAP OSS note 2911103 — SE16N: Alternative edit mode SE16N_EMERGENCY — provides a controlled alternative.

The process works as follows:

1. Unlock — an administrator unlocks the transaction via SM01_CUS.
2. Use — the user executes the transaction, documenting what was changed and the reference ticket (e.g. Ticket XYZ).
3. Document — changes are recorded and reviewed using the report RKSE16N_CD_DISPLAY.

By default, the transaction is locked on first use and can only be re-enabled on explicit request, then re-locked via SM01_CUS. This creates a traceable, auditable process for emergency access.

How to Mitigate SE16 Access Risk

If SE16 access cannot be avoided, several mitigation approaches are available:

Parametric Transactions

Where users need access to a limited set of specific tables, parametric transactions can be created via SE93. These use SE16 as the underlying engine but lock the entry directly to a pre-defined table — bypassing the initial selection screen and preventing the user from navigating to other tables.

If the number of tables is very large, it is worth asking: why does this user need direct table access to so many tables? Are the standard SAP transactions not sufficient? Is access to the QA system an option for configuration review purposes? A custom transaction limiting selectable tables is another option, though not generally recommended.

Authorization Objects

SAP provides authorization objects specifically designed to restrict table-level access through SE16. Using these objects to define which tables a user can access is the most standard mitigation approach. A dedicated post on these authorization objects provides further detail.

Security Audit Log

At minimum, the following Security Audit Log events should be activated to trace SE16 usage:

• DU9 — Generic table access using transactions such as SE16, SE16N, SM30, SM31, SM34, or SQV (OSS note 2041892)
• CUZ — Generic table access by RFC

Activating logs is only meaningful if they are actively monitored and acted upon. For a more automated approach, Emergency Access Management can handle provisioning of sensitive authorizations and log management end-to-end.

Think carefully before assigning SE16 in response to AMS maintenance requests. The convenience is real — but so is the risk.

Frequently Asked Questions

What is the SAP SE16 transaction used for?

SE16 provides direct read access — and in some configurations write access — to all tables in the SAP database on any ABAP-based system. It can expose any data stored in SAP, including financial, HR, and master data.

How many SE16 variants exist in SAP?

Many. Beyond SE16 itself, the most common variants are SE16N and SE16H. Dozens of table-specific SE16_* transactions also exist, along with related transactions such as SE11, SE17, SE16T, SE16SL, and less well-known alternatives like RSSG_BROWSER.

What was the SE16N backdoor?

Shortly after SE16N was released, SAP included a hidden edit mode activated by the parameter &sap_edit. SAP blocked it after it became publicly known, but the program RKSE16N_EDIT still allows administrators to enable or disable this functionality.

Why is SE16 a security risk?

SE16 bypasses SAP's transactional segregation model, giving access to data beyond what the user's assigned transactions formally cover. Combined with debug authorization (S_DEVELOP with change activity), it also enables direct data modification.

How can SE16 access be safely managed?

Through a combination of parametric transactions (locking SE16 to specific tables via SE93), SAP authorization objects for table-level access control, Security Audit Log events DU9 and CUZ, and — for emergency production access — the SE16N_EMERGENCY procedure documented in OSS note 2911103.

Related topics: SE16N, SE16, SAP Security, SAP AMS support, SAP GDPR