Anyone who has had contact with SAP is most likely aware of the existence of a permission called “SAP_ALL”: a kind of sleketon key to all closed doors at the application.
Technically speaking, SAP_ALL is not a simple permission, but a standard profile that contains all authorizations in the system, thus allowing access to all transactions and activities in an SAP system, without restrictions.
It is well known that this profile should not be granted to any user or any circumstance. SAP best practices dictate that only a single user with this profile should exist in the whole system and should be disabled on a regularly basis and enabled when a particular task requires it.
Standard User SAP * is the only one who has the profile SAP_ALL assigned by default.
This profile is less known but very important in the perspective of an SAP version upgrade. It is a composite profile that contains other profiles, one for each SAP release.
After a SAP version upgrade, new authorization checks are created in the system. Based on these new checks, the profile SAP_NEW authorizations grants that users can perform the functions they used to before the upgrade.
So, what to use and when?
As anticipated above, the SAP_ALL profile should only be assigned upon specific administrative needs. The correct approach is to design appropriate roles for each task, including only the required authorizations.
For SAP_NEW, it must not be left active for a long period of time because it contains extensive authorizations, as organizational levels with full authorization (*). A long list of SAP_NEW profiles (example, after multiple upgrades) indicate that it is time to redefine the design of authorization in the systems.
As a summary, for a productive environment SAP_NEW should be used while the upgrade occurs, while SAP_ALL should not be used in any circumstance beyond those required by SAP Support or customer specific need.