SAP penetration tests: Blind spots at the core of IT

The current threat landscape leaves no doubt: cyber attacks are an omnipresent danger for companies of all sizes. According to the BSI situation report on IT security in Germany 2025, the situation is tense and offers attackers the opportunity to attack small and medium-sized companies in particular due to attack surfaces that are still too poorly protected. This trend is also reflected in the SAP environment: an analysis of the monthly security advisories published in 2025 shows a significant increase in vulnerabilities, which underlines the growing attack surface of SAP applications. In response to this tense cyber situation, most organizations have strengthened their defenses: multi-factor authentication, endpoint detection systems and information security management as examples of modern security measures are well known and have become part of the standard repertoire. But in the midst of these efforts, there is a dangerous blind spot: the SAP system landscape. While the network and the classic IT infrastructure are meticulously checked, the system that manages financial and personnel data, production plans and customer information often remains a black box. 

Neglected SAP security

The reasons for this are mostly of an organizational nature. SAP security often falls into a responsibility gap: The IT security team lacks specialist knowledge of proprietary architecture, while the SAP team focuses on stability rather than attack simulations. In addition, there is a deceptive sense of security that views SAP systems as internal, sealed-off monoliths. This assumption ignores the reality of modern landscapes networked via web services and cloud connections. A classic network pentest is not enough: Standard scanners only check the host machine, but do not understand the complex SAP application layer with its proprietary protocols such as Remote Function Call (RFC) or Dynamic Information and Action Gateway (DIAG). Furthermore, if connected development, test or technical systems such as Solution Manager, Focused Run, Governance, Risk and Compliance etc. are excluded from the test scope, a decisive attack vector remains unconsidered.

Typical attack vectors

Attacks on SAP systems can be divided into server encryption with the aim of extorting ransom money on the one hand and insider attacks on the other. Both methods are particularly dangerous due to their speed: a report by Onapsis and SAP shows that attacks on critical SAP applications are on the rise and often occur within 72 hours of a security patch being released. Attackers repeatedly exploit typical vulnerabilities. Unpatched SAP systems are a particularly common attack vector. Although SAP publishes security-relevant information on every second Tuesday of the month as part of its Patch Day, many companies do not apply updates promptly. This leaves systems open to known exploits for weeks or months. Inadequately secured RFC interfaces are also critical. If a less protected development or test system is compromised first, attackers can laterally access productive systems via these connections and execute functions there. 

Added to this are inadequate authorization concepts: Standard users such as SAP* or DDIC with weak or unchanged passwords and over-privileged dialog or system users still exist. Such accounts are specifically used to gradually extend rights to full system control. Insecure custom code also represents a gateway, for example due to a lack of authorization checks or vulnerability to code injections. Passwords also remain a persistent problem, as long validity periods, weak hashing methods and reuse make it easier to take over user accounts.

A conventional penetration test is not enough to proactively address the risks. The SAP Secure Operations Map provides a clear model for understanding the various security levels. 

SAP penetration tests

Traditional pentests usually only cover the lowest IT infrastructure level. However, the crucial vulnerabilities and points of attack are usually found in the system and application-specific levels above, which often represent a black box for outsiders. An SAP penetration test therefore starts where traditional tests end and analyzes SAP-specific services and protocols such as gateway, message server or the Internet Communication Framework as well as the security of DIAG and RFC communication. In addition, application security is checked by examining standard transactions, Fiori apps and web services for manipulation possibilities and unauthorized access. Another focus is on the authorization concept, which is systematically analysed for critical authorizations and potential paths for extending rights. Customer-specific Abap code is also examined both manually and using specialized tools for vulnerabilities such as code injection or missing authority checks. In addition, the system configuration, in particular security-relevant profile parameters, is checked for compliance with SAP best practices and DSAG recommendations. Another advantage lies in the testers' deep understanding of the SAP world. They know where hidden configurations are, how business processes can be manipulated and which default settings pose a risk. This technical focus makes it possible to uncover vulnerabilities that remain invisible to general security scanners and experts. Regulatory requirements such as Nis2 or Kritis specifications demand a verifiable, holistic approach to security, which the isolated penetration test alone does not fulfill.

A holistic SAP security strategy goes beyond this and includes secure software development as part of a secure software development lifecycle. Securing the supply chain is also becoming increasingly important, especially in critical industries where dependencies on external partners pose considerable risks. This approach is complemented by continuous monitoring, which uses a central SIEM system to record and evaluate security-relevant events across all systems. Finally, the increasing use of cloud solutions requires special consideration, as their security requirements and threat scenarios differ in many respects from traditional on-premises systems.

Continue to the partner entry: