Please restrict access to SE16N in your production systems.  If you’re sufficiently paranoid, you may want to remove the transaction it completely

I’ve known for a while that, in some releases of SAP, transaction SE16N can be used to change SAP tables, regardless of authorisations or security settings.  It’s not something I’ve been keen to see widely disseminated, as there are major systemic risks in making changes this way.  More dangerously, it provides a way to override authorisations by giving your userid (or your accomplice’s userid) the SAP_ALL  role. 

SE16N, before entering &SAP_EDIT in the command field


Essentially, you run transaction SE16N, then type &SAP_EDIT into the command field and press enter.

SE16N, AFTER entering &SAP_EDIT in the command field


In the example below, I’ve changed the User Group to SUPER.

SE16N, changing User Group to SUPER


Personally, I’d recommend making the transaction unavailable (perhaps even removing it from TSTC ?) in your production system – Your firefighter userid can be given authorisation to allow the appropriate people to add it back in, if necessary.

The reason for mentioning it at all is that SAP Mental Notes and IT-Toolbox SAP on DB2 for z/OS have stated that changes using this method are permanently logged in the tables listed below:
SE16N_CD_KEY : Change Documents – Header
SE16N_CD_DATA : Change Documents – Data

This means, in theory, that you can can query these tables to audit the usage of SE16N to change data. My attitude is that it’s all well and good knowing Joe Bloggs has broken your system, but I would rather not have to deal with the broken system in the first place.  However, there’s a bigger issue…..

When I tested this out on an ECC6 IDES system (DB2 on Windows 2003), the SE16N_CD* tables were not updated.

SE16N, ECC6 IDES, does not appear to update the SE16N_CD* tables


1 – The knowledge of this method of changing data, which is available on production systems to anyone with access to the SE16N transaction is being more widely disseminated.

2 – There appears to be at least one major platform / release that does not support audit of the method of changing data.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Gretchen Lindquist
    While this is mostly accurate, I’m getting a sense of deja vu. This topic was the subject of a blog by Kevin Wilson less than 2 weeks ago, at which time it was discussed extensively.;jsessionid=(J2EE3414800)ID0504792150DB00916941081198791346End?blog=/pub/wlg/16008

    My observation is unchanged: as long as DEBUG access is very tightly controlled, your system should be protected from the risk of this transaction that you cite. So I would disagree with your assertion that “anybody” can modify tables. If any user can truly modify tables anywhere in your landscape, you desperately need either a security role rebuild or a major user role remapping effort.


  2. Martin English Post author
    I was unaware of Kevin’s blog entry (I got into the conversation via the links in my blog above), so I guess I need to pay more attention to sdn 🙂  

    Something I’ve learnt by following Gretchen’s link (that lead me to How to control authorization on &sap_edit?) is that it seems the &SAP_EDIT functionality is only available to users who have access to SE16N and to DEBUG

    This is controlled via auth object S_DEVELOP object type DEBUG activity 03 and 02 and 01.

  3. Julius von dem Bussche
    Yes, this function feature is checked by the 3 most powerfull authorizations which the system has to offer. Even S_DEVELOP actvt ’03’ for object type ‘DEBUG’ can be misused to change tables is certain conditions are give.

    The same debug feature is available in SE16, but with less logging information.

    SE16N is a fantastic transaction for development work. It is also a report transaction and several function modules are available for it.

    If you do not restrict correct access to use the system protected by conceptually sound authority-checks, then little tcodes are the least of your worries.

    With almost certainty, your blog would have been more thrilling if you had scanned customer coding for concatenations of SQL statements into objects which are inserted as reports via the ABAP system and provided some statistics on that.


  4. Sandra Rossi
    My tables SE16N_CD_* are well updated on my development ECC6 SP 11 system (I’m pretty sure that the kind of database is not of interest)

    Maybe there was a bug at some time…

  5. Julius von dem Bussche
    Please see SAP Note 1420281 –> “CO-OM tools: SE16N: Deactivating &SAP_EDIT”.

    The show is over folks. You can all go back to fixing root cause program errors and missing functionality now… 🙂


  6. Arun Kumar

    Martin,In other way i used the same for testing purpose….It is really hard to find Proper testing data for all the cases ,instead of finding specific data for each case by using &sap_edit we can use the same data to our convenience to all the cases.

    An Advantage afterall…


Leave a Reply