SAP systems are, in many large organisations, the single most sensitive application environment in the estate. They contain payroll records, general ledger data, accounts payable, procurement, HR personnel files, and production bill of materials. In regulated industries, they are the system of record for financial reporting and manufacturing compliance. In any organisation that has gone through an M&A transaction, an SAP integration is often where the most sensitive combined data lives.
They are also, in security programme terms, the most consistently under-managed risk.
This is not because organisations do not care about SAP security. It is because SAP environments operate with a specialisation gap that most security functions cannot bridge. SAP requires its own patching model (SAP Notes, not CVE-driven), its own access control framework (SAP GRC, role authorisation), and its own technical knowledge base (ABAP, RFC protocol, transport management). Security teams that do not have ABAP expertise cannot assess ABAP-based attack surface. Most do not.
The result is a pattern that recurs across large enterprises: IT security has good visibility of the network perimeter and endpoint estate, but the SAP landscape is governed primarily by the SAP Basis team, with security posture determined by the SAP team’s own practices rather than a unified security programme.
The Real Attack Surface
Remote Function Calls (RFC)
RFC is SAP’s inter-system communication protocol. It allows function modules to be called between SAP systems, between SAP and non-SAP systems via middleware, and from the internet via SAP Web Dispatcher and ICM. An RFC-enabled function module with inadequate authorisation checks is callable by any user or system with RFC connectivity — including one that should only have read access.
The attack pattern most commonly seen in SAP penetration testing is RFC lateral movement: an attacker who gains any foothold in the SAP estate (a low-privileged dialogue user, a compromised service account, an RFC gateway left open to the network) calls RFC function modules that lack authorisation checks to escalate privileges, read financial data, or create/modify user accounts.
The RFC Gateway — the SAP component that mediates RFC connections — has historically had insufficient default controls. Unauthenticated access to the RFC Gateway can allow an external attacker to register external programs that execute on the SAP host OS. This is a well-documented attack class dating back to research by Onapsis and ERPScan, and it remains relevant in organisations that have not applied mitigating controls.
ABAP Code Quality
ABAP (Advanced Business Application Programming Language) is the SAP proprietary language in which most SAP business logic is written. Custom ABAP development — built by the organisation or third-party consultants over years of SAP implementation — is typically not reviewed against a modern application security standard. Security testing disciplines applied to Java, Python, or Node.js codebases (SAST, code review, dependency management) are rarely applied to ABAP.
The vulnerability classes that appear in ABAP custom development are familiar: SQL injection via dynamic SELECT statements built with string concatenation, OS command injection via CALL SYSTEM, directory traversal in file handling, and authorisation check omissions that bypass SAP’s role-based access model. The difference is that most organisations have neither the tooling nor the staff expertise to find them.
Onapsis Research Labs publishes periodic research on ABAP vulnerability patterns. The consistent finding is that custom ABAP development in enterprise environments contains a higher density of injection vulnerabilities than equivalent custom development in mainstream languages, precisely because ABAP security is not covered in standard secure coding training.
SAP Note Patching Lag
SAP patches vulnerabilities through SAP Notes — support documents that contain the fix instructions or code corrections. Unlike CVE-based patching, SAP Notes require manual assessment and application by the SAP Basis team. They are not pushed automatically and cannot be applied via standard patch management tooling.
SAP publishes patches on the second Tuesday of each month (SAP Security Patch Day), but organisations consistently lag behind the patch cadence. The reasons are structural: applying SAP Notes requires SAP expertise, testing in non-production before production application, and change management coordination across the business. A complex SAP environment may have hundreds of Notes queued.
The consequence is that many enterprise SAP environments are running with known vulnerabilities that have been patched by SAP but not applied by the organisation. CISA has added SAP vulnerabilities to the KEV catalogue multiple times — including CVE-2025-42999 (critical SAP S/4HANA vulnerability) in early 2026, and the Oracle EBS KEV added July 15 serves as a parallel reminder of ERP platform risk.
Internet-Facing SAP Components
SAP Fiori, SAP S/4HANA public APIs, and the SAP Web Dispatcher increasingly sit in DMZ or cloud-hosted configurations that expose SAP functionality to the internet. The attack surface on internet-facing SAP components includes authentication bypass, session management vulnerabilities, and exploitation of the SAP ICM (Internet Communication Manager).
The critical SAP NetWeaver AS Java vulnerability patched in 2020 (CVE-2020-6287, CVSS 10.0) — which allowed unauthenticated creation of admin users — was still being exploited in production environments three years later. Organisations that lack SAP security visibility may not know whether their internet-facing SAP infrastructure is patched against known critical issues.
Board-Level Questions
1. Who owns SAP security?
In many organisations, the honest answer is “nobody in the security team.” SAP Basis owns SAP operations; the CISO owns the security programme; the gap between them is where SAP security risk lives. The board should expect a clear answer about which function is responsible for SAP vulnerability management and what their cadence is.
2. What is the patch lag on SAP Security Notes?
Ask for a count of outstanding SAP Security Notes rated critical or high that have not been applied, and the average age of outstanding Notes. This is the most direct measure of SAP security debt.
3. Is our SAP estate visible to the vulnerability management programme?
Mainstream vulnerability scanners do not scan SAP. Ask whether the organisation has SAP-specific scanning (Onapsis, SecurityBridge, or equivalent) or whether SAP systems are assessed in penetration testing scope. A yes on generic scanning and a no on SAP-specific tools means SAP vulnerability posture is unknown.
4. What RFC Gateway controls are in place?
RFC Gateway hardening is a specific, well-documented SAP security control with clear guidance from SAP (SAP Note 1408081). Ask whether the Basis team has applied these controls across production systems.
5. Has custom ABAP been reviewed?
Most organisations cannot answer this question affirmatively. If the answer is no — or unknown — the implication is that the highest-value application in the estate contains an unknown quantity of application-layer vulnerabilities that have never been assessed.
The Governance Gap
SAP security occupies an uncomfortable position in enterprise governance. It is too specialised for general security teams to address and too consequential to leave entirely to the Basis team. The practical resolution is either to build SAP security expertise within the security function (expensive, rare) or to use specialist third-party assessment on a cadence (more common, still underutilised).
The risk that materialises when neither approach is taken is not theoretical. Nation-state actors and ransomware operators have targeted SAP environments specifically, often through vulnerabilities that had patches available but not applied. For an organisation whose SAP instance holds payroll, financial reporting, and supply chain data, that is a board-level risk.
The governance answer is to put SAP explicitly within the security programme’s remit, with defined accountabilities for patching cadence, internet-facing component review, and custom code assessment. The alternative is to rely on the Basis team’s security judgement without oversight — which is the current position of most enterprises.