Ask most people what "SAP security" means and they will describe roles, authorizations and segregation of duties. That is half the picture. Roles decide who can do what inside the application, but the application runs on a platform: a kernel, network services, RFC connections, a gateway, configuration files and custom ABAP code. That platform has its own attack surface, and it is the half that generic security programs routinely miss.

The assumption that "SAP sits behind the firewall, so it is safe" has not held for years. SAP systems talk to each other and to the outside world over RFC and HTTP; the gateway starts external programs; standard users ship with known default passwords; and critical vulnerabilities are patched every month. This article walks through the platform side of SAP cybersecurity, the controls that sit underneath your authorization concept.

The SAP attack surface

Before the controls, it helps to see what is actually exposed:

  • Unpatched vulnerabilities: SAP Security Notes fix real, often remotely exploitable, flaws. Every month you defer them, the exposure grows.
  • The gateway and message server: if left open, they allow unauthorized external programs to register and run operating-system commands on the SAP host.
  • RFC connections: trusted RFC relationships and destinations with stored credentials let an attacker move laterally from a low-value system into a productive one.
  • Standard users and default passwords: SAP*, DDIC, SAPCPIC, EARLYWATCH, TMSADM all ship with well-known defaults.
  • Exposed web services: ICF services in SICF that were never needed but are active.
  • Custom ABAP code: injection, directory traversal and missing authority checks written into your own developments.
  • Unencrypted traffic: SAP GUI (DIAG) and RFC traffic in clear text on the network.

Each of these is addressable. Here is how.

1. SAP Security Notes and patch management

SAP publishes Security Notes on SAP Security Patch Day, the second Tuesday of every month. Notes carry a priority: Hot News (the most critical, typically CVSS 9–10), High, Medium and Low.

A workable patch process:

  • Use System Recommendations (in SAP Solution Manager or Focused Run) to see which security notes are missing per system, rather than reading the monthly list manually.
  • Triage Hot News and High first, on internet-facing and productive systems.
  • Fold security notes into a regular maintenance cadence so they do not accumulate into a once-a-year mega-project.
  • Track applied notes as audit evidence, "we patch" is a claim; the note-by-note record is the proof.

Patching is unglamorous and it is the single highest-impact SAP cybersecurity control. Most public SAP compromises trace back to a vulnerability that had a patch available.

2. System hardening: profile parameters

A large part of SAP hardening is configuration through profile parameters. The high-value ones include:

  • Password and logon policy: login/min_password_lng, the login/password_* family, login/fails_to_user_lock, and disabling weak downward-compatible password hashes.
  • login/no_automatic_user_sapstar = 1: prevents the hardcoded SAP* fallback logon (default password PASS) if the SAP* user record is ever deleted.
  • auth/no_check_in_some_cases and related switches, govern how authorization checks behave; they should be set deliberately, not left at legacy defaults.
  • rfc/reject_expired_passwd and snc/*: tighten RFC and communication security.

Do not hand-tune these one by one from memory. Use the SAP Security Baseline Template and Configuration Validation (in Solution Manager / Focused Run) to define a target configuration and continuously measure drift against it.

3. Gateway and message server security

The gateway starts and communicates with external programs. Left open, it is one of the most abused SAP attack paths. It is controlled by two access control lists:

  • reginfo (parameter gw/reg_info), which external programs may register with the gateway.
  • secinfo (parameter gw/sec_info), which programs may be started by the gateway.

Define both as allow-lists, enable gateway logging (gw/logging) to see what is actually connecting before you tighten, and apply the relevant hardening Security Notes.

The message server should separate its internal and external ports (rdisp/msserv_internal) and restrict access with a message server ACL (ms/acl_info), so application servers, and only application servers, can talk to it internally.

4. RFC security and UCON

RFC is how SAP systems talk to each other, and it is a classic lateral-movement path. Three things to get right:

  • Trusted RFC: trust relationships should be minimal and directional. A low-security sandbox should never be trusted by production.
  • Stored credentials: RFC destinations (SM59) that store a user and password are a standing risk; prefer trusted RFC or technical users with tightly scoped S_RFC authorizations.
  • UCON (Unified Connectivity): the RFC basic scenario lets you build an allow-list of the RFC-enabled function modules that are actually called from outside, then block the thousands that are not. This shrinks the remotely reachable surface dramatically.

5. Secure communication (SNC / TLS)

By default, SAP GUI (DIAG) and RFC traffic can travel the network unencrypted. Secure Network Communications (SNC) encrypts DIAG and RFC; TLS/HTTPS protects Fiori and web traffic. On any system carrying regulated or financial data (which is most SAP systems), encrypted communication should be the baseline, not an option. It is also a control auditors increasingly expect to see evidenced.

6. Security monitoring: the Security Audit Log and beyond

Prevention is never complete, so you need to see what is happening:

  • Security Audit Log (SAL): configured via RSAU_CONFIG (or the older SM19) and read via RSAU_READ_LOG / SM20. Log security-relevant events: failed logons, use of critical transactions, changes to sensitive configuration, and, importantly, Firefighter / emergency-access sessions.
  • Enterprise Threat Detection (ETD) or SIEM integration, for real-time correlation across systems, forward SAP security events into a monitoring platform rather than reviewing logs after the fact.
  • Custom code scanning: the Code Vulnerability Analyzer (CVA) finds injection and authority-check flaws in your ABAP before they ship.

Where this connects to access governance

Platform hardening and access governance are two halves of one control. A hardened system with a bloated, SAP_ALL-riddled role catalogue is still wide open from the inside; a clean SoD ruleset on an unpatched, open-gateway system is a false sense of security.

They also reinforce each other. Emergency access is the clearest example: a well-designed SAP Firefighter process is an access-governance control, but it only produces trustworthy evidence if the Security Audit Log is capturing sessions and the platform underneath is sound. And continuous access-risk monitoring, the kind our tool MTC Skopos provides, closes the loop between "who has access" and "what is actually happening" with it.

A pragmatic hardening roadmap

If you are starting from a typical, never-hardened landscape, sequence it like this:

  1. Get patching under control: System Recommendations, Hot News first.
  2. Close the gateway and message server: reginfo/secinfo allow-lists, ACLs, logging.
  3. Lock down standard users: passwords, SAP* fallback, unused accounts.
  4. Baseline the configuration: Security Baseline Template + Configuration Validation, then manage drift.
  5. Reduce the RFC surface: trusted RFC cleanup, UCON.
  6. Encrypt communications: SNC and TLS.
  7. Turn on real monitoring: Security Audit Log tuned to meaningful events, forwarded to a SIEM or ETD.

You do not need to do all seven at once. You do need a plan that treats them as one program rather than seven disconnected tickets.

How MTC helps

We assess and harden SAP platforms for Swiss and international organizations: patch-management setup, configuration baselining, gateway/RFC exposure reduction, secure communication, and security monitoring, joined up with the access-governance side (SoD, Firefighter, authorizations) so you get one coherent SAP security posture rather than two teams solving half the problem. On large programs we partner with leading global audit, risk and technology consulting firms while keeping the security outcome owned by a senior Swiss-based team.

Frequently Asked Questions

What is SAP cybersecurity?

SAP cybersecurity is the protection of the SAP platform itself (kernel, communications, configuration and code) against misuse and attack, as distinct from authorization management (who can do what inside the application). It covers SAP Security Notes and patching, system hardening through profile parameters, gateway and RFC security, secure communication (SNC/TLS), and security monitoring with the Security Audit Log.

How often does SAP release Security Notes?

SAP publishes Security Notes on SAP Security Patch Day, the second Tuesday of every month. Notes are rated by priority, Hot News (the most critical), High, Medium and Low. Hot News and High notes affecting your systems should be assessed and scheduled promptly; the System Recommendations tool (in SAP Solution Manager or Focused Run) identifies which notes are missing on each system.

What is the difference between SAP security and SAP authorizations?

SAP authorizations control who can do what inside the application through roles and authorization objects. SAP security (cybersecurity) is broader: it also protects the platform the authorizations run on, patching, gateway and RFC hardening, secure communication, standard-user lockdown and monitoring. Strong authorizations on an unpatched, open system are not enough; the two layers have to be secured together.

How do you secure the SAP gateway?

The SAP gateway is hardened primarily through its access control lists: the reginfo file (which external programs may register, controlled by the gw/reg_info parameter) and the secinfo file (which programs may be started, gw/sec_info). Leaving the gateway open lets unauthorized external programs register and execute commands. Combined with monitoring (gw/logging) and the relevant SAP Security Notes, these ACLs close one of the most common SAP attack paths.