SAP needs specialist testing because it runs your most critical processes on its own protocols, application layer and authorisation model that generic testers don't know. A thorough SAP security assessment covers several layers: the network and exposed services (Gateway, Message Server, ICM, HANA), configuration and security parameters, RFC and interface security, the ABAP custom-code layer, and roles, profiles and Segregation of Duties (SoD) — plus SAP Security Notes patch hygiene and default accounts. The most common findings are default passwords (SAP*, DDIC, TMSADM), an open Gateway/Message Server, and insecure RFC destinations enabling system-to-system pivoting. Much of it is read-only; active exploitation is scoped to avoid disrupting production. Details below.
// 01 Why SAP is different
Most penetration testing assumes web and network targets. SAP breaks that assumption. It's an ERP platform with its own world: the DIAG and RFC protocols, the NetWeaver application server, ABAP as a programming language, and an authorisation model built from roles, profiles and objects rather than simple user permissions. A generic tester pointing standard tools at an SAP landscape will miss almost everything that matters, because the real risks — an unauthenticated Gateway command, a stored high-privilege RFC credential, a toxic SoD combination that lets one person both create and pay a vendor — live in SAP-specific constructs. And the stakes are the highest in the business: SAP is the finance and supply-chain system, so a compromise isn't a data leak, it's operational and financial control.
// 02 The layers of an assessment
Network & exposure
Which SAP services (Gateway, Message Server, ICM, HANA) are reachable, and from where.
Configuration
Security parameters, secure communication (SNC/TLS), and hardening of the instance profile.
RFC & interfaces
Trust relationships and stored credentials that let one system pivot into another.
ABAP custom code
Injection, directory traversal and backdoors in your organisation's bespoke developments.
Roles & SoD
Excessive authorisations and Segregation-of-Duties conflicts in the security model.
Notes & patching
Missing SAP Security Notes leaving known, published vulnerabilities live.
Not every engagement needs all six. External-exposure concern leans on layers 1–3; an insider-abuse or audit concern leans on 5–6. Scoping to the actual worry keeps the test focused.
// 03 The misconfigurations we find again and again
SAP findings are strikingly consistent across organisations, because they're patch-and-configuration hygiene problems that persist quietly for years. The usual suspects: default or unchanged passwords on standard users like SAP*, DDIC and TMSADM; an open SAP Gateway or Message Server permitting unauthenticated command execution or registration of a malicious application server; insecure RFC destinations holding stored high-privilege credentials that turn one foothold into estate-wide access; missing SAP Security Notes leaving published vulnerabilities exploitable; excessive authorisations and SoD conflicts; and unencrypted DIAG/RFC traffic exposing credentials on the wire. None are exotic — all are serious, and all are invisible without SAP-aware testing.
// 04 NetWeaver, S/4HANA & Fiori
Two shifts change the modern SAP attack surface. First, S/4HANA and the HANA database bring their own exposed services and privilege model, and the migration from ECC often leaves legacy configuration and accounts behind. Second, SAP Fiori and the Gateway/OData layer push SAP toward the web — which means classic web application and API risks now apply on top of the SAP-specific ones. A current assessment therefore blends both: SAP-native testing of NetWeaver, RFC and HANA, plus web/API testing of the Fiori and OData surface where business logic and authorisation are increasingly enforced. Cloud-hosted SAP adds the cloud configuration layer as well.
// 05 How the engagement runs (without breaking production)
The first question every SAP owner asks is “will this take down production?” A competent assessment is built so the answer is no. A large share of the work — configuration review, authorisation and SoD analysis, Security Note and patch assessment — is read-only. Active exploitation is agreed in the rules of engagement, run against a representative non-production system where possible, and where production is in scope it's carefully rate-limited, scheduled into a change window, and backed by a rollback plan. Throughout, the tester works hand-in-hand with your Basis team. The output maps findings to business impact and to any compliance frameworks you answer to — the same reporting standard as our core methodology.
// 06 Frequently asked questions
Why does SAP need a specialist assessment?
SAP runs critical business processes and has its own protocols, application layer and authorisation model that generic testers don't know. Risks like insecure RFC, an exposed Gateway/Message Server, default standard accounts, missing Security Notes, and dangerous ABAP or authorisation combinations are invisible to a standard pentest. A specialist understands NetWeaver, S/4HANA and the SAP attack surface.
What layers does it cover?
Network and exposed SAP services (Gateway, Message Server, ICM, HANA); configuration and security parameters; RFC and interface security; the ABAP custom-code layer; and roles, profiles and Segregation of Duties. It also checks patching against SAP Security Notes, default accounts, and secure communication. The mix depends on whether the concern is external exposure, insider abuse, or compliance.
What are the most common SAP misconfigurations?
Default passwords on SAP*, DDIC and TMSADM; an open Gateway or Message Server allowing unauthenticated command execution; insecure RFC destinations with stored high-privilege credentials enabling pivoting; missing Security Notes; excessive authorisations and SoD conflicts; and unencrypted DIAG/RFC traffic. Many are configuration and patch-hygiene problems that persist for years.
Will testing SAP disrupt production?
A competent assessment is scoped to avoid it. Much of the work is read-only. Active exploitation is agreed in advance and, where possible, run against a non-production system, with any production testing rate-limited and scheduled. Rules of engagement, change windows and rollback plans are agreed up front, and the tester works closely with your Basis team.
// 07 Related reading
- Cloud penetration testing — for SAP hosted on AWS, Azure or GCP.
- Web app and API testing — for the Fiori / OData surface.
- Our methodology and requirements by framework.