SAP NetWeaver and S/4HANA Basis Hardening Guide

Most serious SAP compromises do not need a stolen password: they use an unpatched Java component, an open gateway or message server, or a technical user with stored credentials and broad rights. CISA's Known Exploited Vulnerabilities catalog lists 14 SAP entries, most of them in NetWeaver, including the 2025 Visual Composer Metadata Uploader flaw (CVE-2025-31324) that let unauthenticated attackers upload executable files. This guide covers the Basis layer of SAP NetWeaver AS ABAP and AS Java, which also underpins S/4HANA on premises: logon and password parameters, the gateway and its secinfo and reginfo ACLs, message server separation, RFC destinations and technical users, logging, and Security Patch Day handling. It is for SAP Basis administrators, SAP security teams and the infrastructure teams who run the hosts. Authorisation design, SAP_ALL, firefighter access and GRC are covered in the SAP Identity and Access Security Guide; this page does not repeat them.

Key takeaways

Patch Day is monthly, exploitation is fast. SAP releases security notes on the second Tuesday of each month; KEV-listed NetWeaver flaws such as CVE-2025-31324 were given a three-week federal remediation deadline.
The gateway must never run open. gw/acl_mode 0 allows any external program to start or register; keep the default 1 and maintain explicit secinfo and reginfo files in version 2 format.
Separate the message server ports. Without rdisp/msserv_internal, a client on the external port can pose as an application server.
Technical users are the main non-human identity risk. RFC destinations with stored passwords, communication users with broad rights and trusted RFC relationships turn one compromised system into many.
Check configuration continuously. Parameters drift through profile edits and upgrades; compare against a written baseline with EarlyWatch Alert security checks or configuration validation tooling.

How identity and access work in SAP NetWeaver

NetWeaver authenticates users per client in AS ABAP (user master records maintained in SU01) and through the User Management Engine (UME) in AS Java, which can use the ABAP system or an LDAP directory as its data source. Access arrives over several channels, each with its own controls.

Channel	Typical use	Authentication	Key Basis controls
SAP GUI (DIAG)	Dialog users, administrators	Password, SNC with Kerberos or X.509, SSO	SNC encryption, `login/*` parameters, `login/disable_password_logon` once SSO is in place
RFC	System to system, middleware, scripts	Communication or system users, trusted RFC, SNC	Gateway ACLs, SNC, UCON RFC allowlisting, S_RFC authorisations
HTTP(S) via ICM	Fiori, OData, web services, AS Java applications	Logon tickets, SAML, X.509, Basic	Deactivate unused ICF services (SICF), HTTPS only, `login/ticket_only_by_https`
Message server	Logon balancing, application server registration	Network ACLs	`rdisp/msserv_internal`, `ms/acl_info`, `ms/monitor` 0
Start service (sapstartsrv)	Instance start, stop and monitoring	OS user of the instance	Protect administrative web methods; restrict network access to the start service ports

Logon and password parameters

SAP documents defaults for the login/* profile parameters. Several defaults are weaker than most policies require.

Parameter	SAP default	Typical hardened value	Why
`login/min_password_lng`	6	At least 12 for dialog users (longer for technical users)	Default is short by current guidance
`login/fails_to_user_lock`	5	5 or lower, with `login/failed_user_auto_unlock` 0	Locks persist until an administrator unlocks
`login/no_automatic_user_sapstar`	1	1	Stops the hard-coded SAP* fallback when the user record is deleted
`login/password_downwards_compatibility`	1	0 once all kernels support current hashes	Removes storage of legacy, weaker hash formats
`login/password_max_idle_initial`	0 (off)	A small number of days	Initial passwords that are never used should expire
`login/password_max_idle_productive`	0 (off)	Aligned to your inactivity policy	Unused passwords stop working
`login/disable_password_logon` or `login/password_logon_usergroup`	0 / empty	Enable for groups that use SSO	Removes password logon where SNC or SAML is in place
`login/ticket_only_by_https`	0	1	Logon tickets are only sent over HTTPS

Pair parameters with the standard users: SAP*, DDIC, EARLYWATCH, TMSADM and SAPCPIC exist in multiple clients including 000 and 066 where present. Change their passwords, lock those not needed and check them in every client after a copy or upgrade; attackers try them first (T1078.001 Default Accounts).

Admin roles and privileged access

Basis administration rights: profile maintenance (RZ10, RZ11), gateway and message server monitors (SMGW, SMMS), RFC destination maintenance (SM59), transport management and kernel replacement change the security of the whole system. Grant them through specific roles, not SAP_ALL, and log their use.
Operating system accounts: the <sid>adm user and the database owner can read profiles, secure storage and data files and can start or stop instances. Protect them like domain administrators: no interactive shared use, key-based or vaulted access, and session recording. See the Linux Service Accounts and Keytab Management Guide.
Emergency access: use firefighter IDs or temporary role assignment with review for production changes, and keep Basis superuser rights out of standing assignments. See the Privileged Access Management Guide.
Transports: transports can carry code and authorisation changes into production. Restrict who can release and import, and require approval for imports into production.
Debugging and table maintenance in production: debug with replace and direct table maintenance bypass application controls. Keep them out of production roles except through emergency access.

Integrations, API tokens and service accounts

RFC destinations and technical users

Object	Risk	Control
SM59 destinations with stored logon data	Anyone who can use the destination acts as the stored user in the target system, often with broad rights	Store credentials only where needed, prefer current-user logon or trusted RFC with tight scope, review destinations quarterly
Communication and system users	Passwords rarely rotated; rights accumulated over years	Use user type System or Communication (no dialog logon), least privilege roles built from authorisation traces, rotation schedule, owner recorded
Trusted RFC relationships (SMT1)	A compromise of the calling system grants logon to the trusting system as the same user	Only from systems of equal or higher security (never development to production), restrict with authorisation object S_RFCACL
Inbound RFC function modules	Remote-enabled function modules callable by any user with S_RFC	Unified Connectivity (UCON) allowlisting of remote-enabled function modules per communication assembly
Web service and OData technical users	Basic authentication with long-lived passwords embedded in middleware	X.509 client certificates or OAuth where supported, HTTPS only, rotation

Treat every technical user as a non-human identity with an owner, a purpose, a credential type and a rotation date. See the Service Account Security Guide and the Secrets Management Guide.

Gateway: secinfo and reginfo

The gateway lets external programs be started (controlled by secinfo, parameter gw/sec_info) or register themselves (controlled by reginfo, parameter gw/reg_info). These programs then act on behalf of RFC clients, so an open gateway is remote code execution on the SAP host.

gw/acl_mode: applies when a security file is missing. Value 1 (the default) only allows servers belonging to the same system; value 0 allows anything and SAP says it should not be used in production.
File format: use version 2 (first line #VERSION=2) with explicit P (permit) and D (deny) lines. Version 1 cannot deny explicitly, and the two versions cannot be mixed.
secinfo: entries define TP, USER, HOST and USER-HOST. Avoid wildcards in USER-HOST; an SAP blog on securing against the Onapsis 10KBLAZE findings recommends keeping only the local and internal permit entries plus specific named programs.
reginfo: restrict each registered program with HOST, and use ACCESS (which hosts may use it) and CANCEL (which hosts may cancel it). Without ACCESS, any client may use the program.
Safe change process: SAP recommends maintaining the files in SMGW. If either file is empty or has invalid syntax the gateway shuts down, so validate before activating. Use gw/sim_mode 1 temporarily to log what would be denied, review, then switch off. Re-register programs after changing reginfo, because they keep the attributes they registered with.
Related settings: set gw/reg_no_conn_info as recommended in SAP's guidance (the SAP blog cites 255), and enable gw/logging so permitted and rejected starts and registrations are recorded. Check the dev_rd trace for skipped lines.

Message server

Separate ports: set rdisp/msserv_internal to a port different from the external rdisp/msserv. Application servers trying to log on through the external port are then refused, and external clients keep read-only access for logon balancing.
Restrict the internal port: block it at the firewall for everything except the system's own application servers, and list allowed hosts in ms/acl_info or the per-port ms/acl_file_* files.
Monitoring and admin: keep ms/monitor at 0 and ms/admin_port at 0 (closed) except during planned administration.

Logging and detection

Security Audit Log (AS ABAP): enable it with the rsau/enable parameter and configure filters (RSAU_CONFIG in current releases, SM19 in older ones) for all clients and at least logon failures, RFC and transaction starts by privileged users, user master changes, and use of debug and table maintenance. Read with RSAU_READ_LOG (SM20 on older releases) and forward to the SIEM.
Gateway and message server logs: gw/logging records secinfo and reginfo decisions; review rejected registrations and unexpected external program starts.
AS Java: forward HTTP access logs and security logs; alert on requests to Visual Composer and other development paths in production, and on new files in application directories, which may indicate a web shell (T1505.003).
Change logs: profile parameter changes (RZ10 history), SM59 changes, user master change documents and transport imports.

Metric	Healthy signal
Days from Patch Day to implementation of High and Hot News notes on internet-facing systems	Within your SLA; KEV-listed notes within CISA due dates
Systems with `gw/acl_mode` 1 and version 2 secinfo and reginfo without broad wildcards	100 percent
Systems with separate internal message server port and firewall restriction	100 percent
RFC destinations with stored credentials, and those reviewed in the last quarter	Falling count; all reviewed
Technical users with an owner, least-privilege role and rotation date	100 percent
Security Audit Log active in all production clients and forwarded	100 percent

Hardening baseline

Patching and vulnerable components

Security Patch Day: SAP's security notes appear on the second Tuesday of each month. SAP distinguishes Patch Day notes, which need action, from Support Package notes, which arrive with support package upgrades. For new High and Very High notes SAP provides fixes for support packages shipped within the last 24 months, so systems older than that may need an upgrade to receive a fix.
Kernel and Java stack: many critical notes need a kernel or AS Java patch, not just ABAP corrections. Keep a schedule for both.
Exposed Java components: CVE-2025-31324 affected the Visual Composer development server (VCFRAMEWORK 7.50), with an SAP CVSS score of 10.0, and was followed by a related Metadata Uploader deserialisation flaw, CVE-2025-42999, also in KEV. Earlier KEV entries include CVE-2020-6287, a missing authentication flaw in AS Java that allowed creation of administrative users, and CVE-2022-22536, HTTP request smuggling across ABAP, Java and Web Dispatcher. Disable development and configuration components that are not used in production and remove them from internet exposure.

Phased rollout

Inventory: list every SAP system and client, its kernel, AS Java components, exposed ports and network zones. Note internet-facing ICM and Web Dispatcher endpoints.
Patch exposure first: apply outstanding KEV-listed and Hot News notes on internet-facing and AS Java systems before parameter work.
Write the parameter baseline: logon, gateway, message server, SNC and ICM parameters with target values per system type, based on SAP's notes (for example 1408081 for reginfo and secinfo, 1421005 and 821875 for the message server, 1504652 for AS ABAP).
Simulate: run the gateway in simulation mode, enable logging and collect the real external programs and registrations before tightening ACLs. Test logon parameters in a sandbox copy of production clients.
Apply by landscape tier: sandbox, development, quality, then production, with rollback by reverting the profile and reloading security files.
Clean up technical users and destinations: remove unused destinations, replace stored passwords, restrict trusted RFC and enable UCON for inbound RFC.
Monitor continuously: check parameters against the baseline with EarlyWatch Alert security checks or configuration validation tooling and track drift.

Small landscapes can run the baseline from EarlyWatch Alert findings and SAP's notes. Large or RISE and hosted landscapes need agreement on which parameters the provider owns and which the customer owns, and evidence from both.

Framework mapping

Framework	Reference	SAP Basis control
NIST SP 800-53 Rev. 5	CM-6 Configuration Settings; SI-2 Flaw Remediation	Profile parameter baseline; Patch Day process
NIST SP 800-53 Rev. 5	AC-2 Account Management; AC-6 Least Privilege; IA-5 Authenticator Management	Standard and technical users, Basis roles, password parameters and rotation
NIST SP 800-53 Rev. 5	SC-7 Boundary Protection; SC-8 Transmission Confidentiality and Integrity	Gateway and message server ACLs, port separation; SNC and HTTPS
NIST SP 800-53 Rev. 5	AU-6 Audit Record Review, Analysis, and Reporting	Security Audit Log forwarding and review
CIS Controls v8.1	Control 4 Secure Configuration; Control 5 Account Management; Control 7 Continuous Vulnerability Management	Baseline, technical users, Patch Day
MITRE ATT&CK v20	T1190 Exploit Public-Facing Application; T1078.001 Default Accounts; T1505.003 Web Shell	Patching exposed Java components; standard user hardening; file integrity on AS Java

Common misconfigurations

Gateway left open: gw/acl_mode 0, missing security files or TP=* entries with wildcard hosts let any network client register or start programs. SAP's own guidance after 10KBLAZE was built around closing exactly these settings.
One message server port: internal and external traffic share a port, so a client on the user network can register as an application server.
Development components in production: Visual Composer and similar AS Java tools remain deployed and reachable from the internet long after they are needed.
Stored passwords everywhere: SM59 destinations from development or quality systems store production communication users with broad rights, and nobody owns them.
Standard users forgotten in secondary clients: SAP* and DDIC are hardened in the main client but keep known passwords in client 000 or 066.
Patching only ABAP: ABAP notes are applied, but kernel and AS Java patches wait for the next upgrade window.

Practitioner checklist

Review SAP security notes every Patch Day and implement KEV-listed and Hot News notes on exposed systems first.
Remove or disable unused AS Java development and configuration components, starting with Visual Composer where not required.
Keep gw/acl_mode 1 and maintain version 2 secinfo and reginfo files in SMGW, using simulation mode before tightening.
Configure a separate internal message server port, restrict it at the firewall, and keep ms/monitor and ms/admin_port at 0.
Set login/* parameters to your policy, keep login/no_automatic_user_sapstar 1 and harden standard users in every client.
Enable SNC for GUI and RFC traffic and HTTPS for ICM, and disable unused ICF services.
Inventory RFC destinations and technical users, assign owners, remove stored credentials where possible and rotate the rest.
Restrict trusted RFC to systems of equal or higher security and enable UCON for inbound RFC.
Enable the Security Audit Log in all production clients and forward it, gateway logs and AS Java logs to the SIEM.
Check parameters against the written baseline at least monthly and after every upgrade or system copy.

SAP NetWeaver and S/4HANA Basis Hardening Guide: Gateway, Message Server, RFC and Patch Controls