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.
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:
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.
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:
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:
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.
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:
S_DEVELOP with change activity), direct data modification becomes possible.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:
SM01_CUS.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.
If SE16 access cannot be avoided, several mitigation approaches are available:
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.
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.
At minimum, the following Security Audit Log events should be activated to trace SE16 usage:
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.
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.
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.
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.
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.
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