SAP Basis Security Checklist: 20 Controls Every Basis Admin Should Verify
Most SAP Basis hardening guides exist at the conceptual level. This one gives you the exact parameter names, the recommended values, the risk of getting them wrong, and how SyntaAI checks all 20 automatically.
SAP Basis administrators carry more security responsibility than their job title suggests. The profile parameters, client settings, gateway configurations, and default account statuses that Basis teams manage determine whether an SAP system is exploitable in minutes or resilient to attack. Most of these settings are configured once at go-live and never reviewed again — which is exactly why auditors and attackers look at them first.
This checklist covers 20 security controls across six categories. Each item includes the exact parameter or setting, the secure value, the risky value, and what the consequence of misconfiguration actually is. SyntaAI checks all 20 automatically via RFC on a scheduled basis.
How to use this checklist: Check each item in your Production system. RSPFPAR (transaction) or the PAHI table shows current parameter values. For client settings, use SCC4. For gateway, check the gw/sec_info and gw/reg_info file contents via AL11.
Category 1: Authentication and Password Policy
01
Failed login lockout threshold CRITICAL
login/fails_to_user_lock
❌ Risky: 0 (no lockout) or >10✅ Secure: 5
Setting to 0 disables brute-force lockout entirely. Attackers can attempt unlimited passwords. Setting too high gives attackers many attempts before lockout. SAP recommends 5.
02
SAP* backdoor disabled CRITICAL
login/no_automatic_user_sapstar
❌ Risky: 0 (backdoor enabled)✅ Secure: 1
If this is 0 and the SAP* record is deleted from USR02, the hardcoded SAP* user activates with full access and a default password. This is not theoretical — it's a known attack technique.
03
Minimum password length HIGH
login/min_password_lng
❌ Risky: <8✅ Secure: 12 or higher
Short passwords are trivially cracked. SAP default is 6 — well below the current security standard of 12+ characters. Check this on every system including development.
04
Password history enforcement HIGH
login/password_history_size
❌ Risky: 0 or 1✅ Secure: 5 or higher
Without password history, users can cycle back to their previous password immediately. This negates forced password change requirements entirely.
05
Session idle timeout HIGH
rdisp/gui_auto_logout
❌ Risky: 0 (no timeout)✅ Secure: 900 (15 minutes)
With no session timeout, an unattended workstation with an active SAP session is an open door. Value is in seconds — 900 = 15 minutes, the HIPAA-required minimum.
06
RFC password rejection for expired accounts HIGH
rfc/reject_expired_passwd
❌ Risky: 0✅ Secure: 1
Without this, RFC connections can authenticate even with expired passwords — bypassing password policy for all system-to-system connections. This silently undermines your entire password rotation program.
Category 2: Authorization Controls
07
Authorization check bypass disabled CRITICAL
auth/no_check_in_some_cases
❌ Risky: Y✅ Secure: N
Setting this to Y disables authorization checks in certain code paths. It was historically used for performance tuning and is almost never necessary in modern systems. If set to Y, users may have access far beyond what their roles define.
08
Debug/replace authorization absent in production CRITICAL
S_DEVELOP with ACTVT=02 in production roles
❌ Risky: Any production user holds this✅ Secure: No dialog users in production
Debug/replace mode allows a user to modify variable values during program execution — bypassing authorization checks in real time. This is the most dangerous authorization in SAP and should never be present in production for any dialog user.
09
Multiple concurrent sessions limited HIGH
login/multi_login_users
❌ Risky: 0 (unlimited)✅ Secure: 1 or 2
Unlimited concurrent sessions enable shared account usage and credential sharing. Restricting to 1-2 sessions makes shared accounts detectable via SM04/SM66.
Category 3: Audit Logging
10
Security audit log enabled CRITICAL
rsau/enable
❌ Risky: 0 (disabled)✅ Secure: 1
With audit logging disabled, there is no record of logins, failed authentication attempts, authorization failures, or sensitive transaction execution. Every compliance framework requires audit logging to be enabled. Disabling it is also a detection evasion technique.
11
Audit log max size sufficient HIGH
rsau/max_diskspace/local
❌ Risky: <100MB (log overwrites too quickly)✅ Secure: 1000MB+
If the audit log fills up and overwrites, historical evidence is lost. For SOX, audit logs need to be retained for minimum 7 years — ensure adequate space and archiving is in place.
12
Table change logging enabled HIGH
rec/client (in SCC4, table logging ON)
❌ Risky: Table logging off in production client✅ Secure: Logging activated in production
Without table change logging, modifications to configuration tables, financial master data, and authorization data leave no trail. Auditors and forensic investigators rely on this log — CDHDR and CDPOS — for change reconstruction.
Category 4: Gateway and RFC Security
13
Gateway security file configured CRITICAL
gw/sec_info
❌ Risky: Not configured or permits *✅ Secure: Explicit allow-list of hosts/programs
Without a gateway security file, any external program can connect to SAP's message server and register as an RFC server — enabling remote execution of SAP functions. The file must explicitly list which hosts and programs are permitted.
14
Gateway registration security configured CRITICAL
gw/reg_info
❌ Risky: Not configured or TP=*✅ Secure: Explicit allow-list of registered programs
Similar to gw/sec_info — controls which external programs can register with the SAP gateway. A wildcard TP=* allows any program to register, enabling external code execution. This is one of the most commonly exploited SAP misconfigurations.
15
RFC destinations without stored credentials HIGH
SM59 → Check each RFC destination for stored credentials
❌ Risky: Password stored in RFC destination✅ Secure: Certificate-based or no stored credential
Stored credentials in RFC destinations are visible to anyone with display access to SM59 or SE37. They also never rotate. Any compromised RFC user credential enables lateral movement to connected systems.
Category 5: Default System Accounts
16
SAP* user locked with non-default password CRITICAL
USR02 — check BNAME=SAP*, UFLAG, password hash
❌ Risky: Active, default password✅ Secure: Locked, non-default password, in all clients
SAP* has full system access by design. Default passwords (06071992, PASS, 19920706) are publicly documented. Must be locked and have password changed in every client including 000, 001, and 066.
17
DDIC user locked in production CRITICAL
USR02 — check BNAME=DDIC, UFLAG
❌ Risky: Active in production✅ Secure: Locked in production, password changed
DDIC is the Data Dictionary superuser. Default password 19920706 is well known. Should be locked in all production clients — only unlocked with explicit authorization for specific maintenance activities.
18
EARLYWATCH user locked HIGH
USR02 — check BNAME=EARLYWATCH, UFLAG
❌ Risky: Active with default password✅ Secure: Locked in all clients
EARLYWATCH is an SAP support user with read access to system configuration data. Default password is SUPPORT. Should be locked unless actively used for SAP support sessions — and even then, only unlocked temporarily.
Category 6: Client Security Settings
19
Production client not modifiable CRITICAL
SCC4 — Client Change Option for production client
❌ Risky: "Changes to Repository and cross-client Customizing allowed"✅ Secure: "No changes allowed"
If the production client is modifiable, developers can make changes directly — bypassing the transport-based change management process entirely. All unauthorized direct ABAP coding and configuration changes are enabled by this setting.
20
Cross-client access disabled in production HIGH
SCC4 — Cross-Client Customizing for production client
❌ Risky: Cross-client changes allowed✅ Secure: Cross-client changes not allowed
Cross-client customizing allows changes that affect all clients simultaneously — including security settings stored in cross-client tables. Enabling this in production breaks the client separation that SAP's multi-client architecture is designed to provide.
How many of these does your system fail? In our experience running these checks against live SAP systems, the average mid-market S/4HANA or ECC system fails 6–9 of these 20 controls on first assessment. The most commonly failed are #10 (audit log not enabled), #13/#14 (gateway not configured), #02 (SAP* backdoor enabled), and #03 (password length below 12).
SyntaAI checks all 20 of these controls automatically by querying the PAHI table (profile parameters), USR02 (default user status), RFCDES (RFC destinations), and system client settings via RFC. The check runs on a scheduled cadence — weekly or monthly — and alerts when any control falls out of the secure state, even if it passed last month.
The checks are mapped to compliance frameworks in SyntaAI's control library: SOX ITGC, ISO 27001 Annex A, NIST 800-53, GDPR Article 32, and HIPAA Security Rule. When an auditor asks "how do you know your SAP security parameters are correctly configured?" — the answer is a timestamped scan report from SyntaAI showing green status across all 20 controls.
Check All 20 Controls Against Your Live SAP System
SyntaAI runs the complete Basis security checklist automatically and flags every deviation from secure baseline — with the exact parameter change needed to fix it.
A concrete list of the profile parameters, client settings, gateway configurations and default-account statuses that determine whether an SAP system is exploitable in minutes or resilient to attack. A good one specifies the exact parameter, the secure value, the risky value, and the consequence of getting it wrong.
Which Basis settings do auditors and attackers check first?
The ones configured once at go-live and never reviewed again: failed-login lockout thresholds, password policy, the SAP* and DDIC default accounts, gateway security files (gw/sec_info, gw/reg_info), audit logging, and client change settings. These are the highest-value, most-overlooked controls.
How do you see current SAP parameter values?
Use transaction RSPFPAR or read the PAHI table for profile parameters, SCC4 for client settings, and AL11 to inspect the gateway security files. These show the live configuration to compare against a secure baseline.
How often should Basis security settings be reviewed?
Continuously rather than once at go-live. Because most of these settings are set and forgotten, scheduled automated checks catch drift and misconfiguration long before an auditor or attacker does — SyntaAI checks the full control set via RFC on a schedule.
SyntaAI checks 1,400+ SAP security controls including all Basis profile parameters, default accounts, gateway settings, and client configuration. Built by Bhargavi Maddipati — Co-Founder & CEO (18 years SAP Security/GRC) and Jani K — Co-Founder & CTO (15+ years SAP). Available for pilot at syntaai.com.