Lesson 3 of 5
Critical access monitoring
10 min
Listen to this lesson
Some authorizations are powerful enough to bypass every other control: maintaining users and roles, changing tables directly, changing values in the debugger, changing client settings, or holding catch-all profiles. Business SoD analysis catches some of these as critical access risks, but Basis and security teams need their own routine to know, at any time, exactly who holds them and why.
What counts as critical
| Access | Why it is critical | Typical holders |
|---|---|---|
| SAP_ALL and SAP_NEW profiles | SAP_ALL grants practically everything; SAP_NEW bridges new checks with very broad values | Nobody in production; emergency IDs only, if at all |
| User and role administration (S_USER_* objects) | Can grant any access, including to oneself | Security administrators, separated from business roles |
| Table maintenance (S_TABU_DIS, S_TABU_NAM with change) | Direct changes bypass application checks and change documents | Very few, by table group |
| Development and debugging with change (S_DEVELOP) | Can alter program flow and data at runtime | Developers in CMD only; firefighter IDs in production |
| Client and system settings | Can open a production client for changes | Basis administrators under change control |
| Background processing for other users | Can run jobs under another user's authorizations | Job administrators |
A starting list of critical access for an S/4HANA ABAP system. Your baseline should name the objects and values precisely.
Tools to find who holds it
The User Information System (SUIM) can list users by authorization values, by profile and by role, and includes reports for users with critical authorizations. SAP's training also describes report S_BCE_68002111, where you define critical authorizations and variants and then list the users who hold them. Report RSUSR200 shows users by last logon date and password status, which finds unused accounts. The SAP EarlyWatch Alert's security section checks for users with critical authorizations, default passwords of standard users and other settings, every week, and is included in SAP maintenance. Where SAP Solution Manager is used, Configuration Validation can compare systems against a target state and report critical authorizations across the landscape. In SAP Cloud ALM, which Contoso uses for the S/4HANA landscape, the Configuration & Security Analysis use case tracks configuration changes over time and checks systems against SAP security recommendations; SAP describes the area as still evolving, so confirm which checks your tenant offers before relying on it as audit evidence.
Privileged users: fewer, named, watched
The target for production is simple to state: no dialog user holds critical access permanently unless a named exception is approved; administrators work with normal roles and use emergency access for privileged tasks; and every use of privileged access is logged. Contoso's go-live check found eight users in CMP with SAP_ALL, all copied from cutover preparation. Seven were removed and one, a firefighter ID, was kept with the emergency access process around it.
- Keep a list of privileged users per system, with the owner and justification for each.
- Reconcile the list against reports monthly; any difference is a finding to explain.
- Lock or remove inactive accounts on a schedule, using RSUSR_LOCK_USERS or your identity process.
- Remove SAP_NEW from users once new checks are built into roles after an upgrade.
- Separate security administration from business roles: those who build roles should not use them for business work.
- Run the reportsFirst working day: critical authorization reports and SAP_ALL / SAP_NEW holders for CMP, with date and client shown.
- Compare with the listEvery holder must appear on the approved privileged user list with an owner and reason.
- Investigate differencesNew or unexplained holders: how was it granted, by whom, and was it used?
- Decide and actRemove, approve with an owner, or move to emergency access.
- RecordReconciliation record with findings and closure dates, kept as audit evidence.
The reconciliation only works if the approved list is itself controlled. Additions to Contoso's privileged user list go through an access request approved by Nadia and the system owner, so the list cannot quietly grow to match whatever the reports show. Removals happen when people change jobs, which the leaver and mover processes trigger.
What would you do?
The monthly critical access report for CMP shows a new user, a consultant from the cutover team, with table maintenance for all authorization groups. The privileged user list does not include them. What should Nadia do first?
- Critical access includes SAP_ALL and SAP_NEW, user and role admin, table changes, debugging with change, client settings.
- Use SUIM reports, S_BCE_68002111, RSUSR200, EarlyWatch Alert and risk analysis to find holders.
- Keep a named privileged user list and reconcile it against reports regularly.
- In production, use emergency access for privileged tasks; log and review every use.
Check your understanding · not graded
Lesson check
1. Which report lets you define critical authorizations and list the users who hold them?
2. Why is direct table maintenance in production considered critical access?
3. Which SAP service checks for users with critical authorizations and default standard-user passwords every week?
4. What is the target model for privileged work in production?