SAP Profile Parameters: Security Settings for On-Prem, Cloud & S/4HANA

SAP profile parameters are the backbone of system security. A single misconfigured parameter can open a door that no firewall rule set will close. Yet the relevance of parameters differs significantly depending on the deployment model: what is indispensable on-premise often does not even exist in the cloud – and S/4HANA brings its own requirements. This guide presents the most important security parameters compared across all three environments.

1. Login & Authentication

Login parameters are the first line of defence in every SAP environment. However, the environments differ significantly here:

On-Premise (ECC / S/4HANA On-Prem)

On the classic ABAP stack, you control every aspect yourself:

• login/min_password_lng = 12 – Minimum password length. The SAP default is 8; we recommend 12 for production systems.
• login/fails_to_session_end = 3 – After 3 failed attempts the session is terminated.
• login/fails_to_user_lock = 5 – After 5 failed attempts the user is locked. Prevents brute-force attacks.
• login/password_expiration_time = 90 – Password expires after 90 days. Combined with complexity rules, a good compromise.
• login/min_password_specials = 1 – At least one special character. Together with login/min_password_digits and login/min_password_uppercase, this produces solid complexity.
• login/no_automatic_user_sapstar = 1 – Prevents automatic creation of the SAP* user with the default password. One of the most frequently overlooked parameters.

S/4HANA (On-Prem & Private Cloud)

S/4HANA uses the same ABAP parameters but brings additional aspects:

• login/password_compliance_to_current_policy = 1 – Forces existing passwords to be checked against the current policy at the next logon. Important after a migration.
• icf/set_HTTPonly_flag_on_cookies = 3 – Sets the HttpOnly flag for all cookies. Particularly relevant in S/4HANA with the Fiori interface, as significantly more HTTP-based communication takes place.
• login/accept_sso2_ticket = 0 – Disables SSO2 tickets when you use SAML or X.509 instead. The recommended approach in S/4HANA with the Identity Authentication Service (IAS).

Cloud (BTP / RISE with SAP)

In the cloud world, responsibility shifts:

• Password policies are configured via SAP Cloud Identity Services (IAS), not via profile parameters. You define minimum length, complexity and expiry in the IAS administration console.
• Multi-factor authentication (MFA) is natively available in the cloud and should be mandatory for all administrative access.
• SAML 2.0 / OpenID Connect – Cloud systems use federated authentication by default. The classic login/* parameters do not exist here.

2. Communication & Encryption

Unencrypted communication is no longer an option in 2026 – regardless of the environment.

On-Premise

• snc/enable = 1 – Activates Secure Network Communication for RFC and dialog connections. Without SNC, passwords are transmitted in plain text.
• snc/data_protection/max = 3 – Maximum protection level (Privacy): encryption + integrity + authentication.
• ssl/ciphersuites – Defines the permitted TLS cipher suites. Consistently disable outdated suites (TLS 1.0/1.1).
• icm/HTTPS/verify_client = 1 – Enforces client certificate verification for HTTPS connections to the ICM.
• SAPDBHOST / rdisp/msserv_internal – Separate database and message server communication strictly from the user network.

S/4HANA

• All on-premise parameters continue to apply.
• icm/HTTP/redirect_0 = PREFIX=/, FROM=*, FROMPROT=HTTP, TOPROT=HTTPS – Enforces HTTPS redirect for all HTTP requests. Essential when using Fiori.
• is/HTTP/show_detailed_errors = FALSE – Prevents detailed error messages in the browser. Otherwise, attackers can derive system details from stack traces.

Cloud (BTP)

• TLS 1.2+ is enforced by default – you cannot disable it (which is a good thing).
• Mutual TLS (mTLS) can be configured for service-to-service communication via the BTP Service Binding.
• Destinations in BTP should always be configured with OAuth2 or client certificates – never with Basic Authentication and stored passwords.

3. Gateway & RFC Security

The SAP Gateway is a preferred attack target. How it is secured differs by environment:

On-Premise

• gw/sec_info = /usr/sap/<SID>/SYS/profile/secinfo – Defines which external programmes may call RFC functions. An empty or missing file = an open door.
• gw/reg_info = /usr/sap/<SID>/SYS/profile/reginfo – Controls the registration of external server programmes at the gateway.
• gw/reg_no_conn_info = 255 – Limits connection information. Reduces the attack surface during gateway enumeration.
• gw/acl_mode = 1 – Activates strict ACL mode. Without this parameter, secinfo/reginfo are only treated as “recommendations”.
• rfc/reject_expired_passwd = 1 – Rejects RFC connections with expired passwords. Prevents old service accounts with long-expired credentials from still functioning.

S/4HANA

• All on-premise parameters apply identically.
• Additionally: In S/4HANA with embedded Fiori, the gateway service (OData) is used more intensively. Check the ICF services under /sap/opu/odata/ – only required services should be active.

Cloud (BTP)

• The classic SAP Gateway does not exist in BTP. Instead, communication is handled via the Cloud Connector as a reverse-invoke proxy.
• In the Cloud Connector, you explicitly configure which on-premise resources (host + port + path) are accessible – a significantly more granular approach than the classic secinfo/reginfo files.
• Principle: Only release the minimum necessary resources. Each URL and each RFC function module must be individually enabled.

4. Audit & Logging

Without logging there is no traceability – and no passed audit.

On-Premise & S/4HANA

• rsau/enable = 1 – Activates the Security Audit Log (SAL). Incomprehensibly still deactivated in many systems.
• rsau/max_diskspace/local = 2000000 – 2 GB of storage for audit logs. The default value is often too small for production systems.
• rsau/integrity = 1 – Integrity protection for audit logs. Prevents retrospective manipulation of the log files.
• rec/client – Defines the clients for which table logging is active. Mandatory for production clients.
• rslg/collect_daemon/host – Central syslog host. Forward audit data to a SIEM system for centralised evaluation.

Cloud (BTP)

• Audit logging is available as the SAP Audit Log Service and must be activated per subaccount.
• Configuration is done via the BTP Cockpit API, not via profile parameters.
• Log Retention: 90 days by default. For compliance requirements, check whether archiving to SAP Data Custodian or an external SIEM is necessary.

5. System Integrity & Hardening

These parameters protect the core system integrity:

On-Premise & S/4HANA

• auth/rfc_authority_check = 6 – Strictest level of RFC authority check. Prevents RFC function modules from being called without an authorisation check.
• login/system_client – Defines the default client. Ensure that no production client is configured as the default client to avoid accidental logons.
• rdisp/gui_auto_logout = 900 – Automatic logout after 15 minutes of inactivity. Prevents unattended sessions.
• login/disable_cpic = 1 – Disables CPIC logons when not explicitly needed.
• system/secure_communication = ON – Enforces secure communication between SAP systems. Essential in S/4HANA landscapes with multiple connected systems.

S/4HANA-specific

• abap/heap_area_dia = 4000000000 – In S/4HANA with the HANA database, larger memory areas are needed. At the same time, limits protect against memory-based DoS attacks.
• icm/HTTP/logging_0 – HTTP access logging for the ICM. Critical for traceability of user access with Fiori front ends.
• is/HTTP/show_detailed_errors = FALSE – No stack trace in the browser. Particularly important for publicly accessible Fiori Launchpads.

Cloud (BTP)

• System integrity is primarily SAP’s responsibility (Shared Responsibility Model).
• Your responsibility: Secure configuration of custom applications, destinations, service keys and role collections.
• BTP Security Recommendations: SAP maintains a current list with over 80 concrete recommendations for BTP security – review them regularly.

6. Comparison Overview: Parameters by Environment

7. Checklist: Parameter Review in 5 Steps

Conclusion

Profile parameters are not “set and forget”. In a world where on-prem, S/4HANA and cloud coexist, each environment needs its own parameter strategy – but a uniform security level. The good news: most parameter changes do not require a budget, but knowledge and a structured review process.

If you need a systematic parameter review for your SAP landscape – whether on-prem, cloud or hybrid – get in touch.

Request parameter review →

Related Articles

Need support with this topic?

We help you with implementation – from analysis to go-live.

Get in touch

← All articles