SAP & ERP Penetration Testing

We map the landscape: application servers, the message server, SAPRouter, exposed dispatcher and gateway ports, the SAP versions and support-package levels in play, and any web-facing components such as Fiori or the Web Dispatcher. Version and patch state matter because SAP publishes monthly security notes, and unapplied notes are a reliable way in.

ERP systems ship with standard accounts, and installations that never changed them are common even in large companies. We check SAP* , DDIC, EARLYWATCH and their equivalents for default or weak passwords, test the RFC and gateway interfaces for unauthenticated access, and probe SAPRouter for permissive route rules that let an outsider reach systems that should be internal only.

Where the technical stack is vulnerable, we verify it. The RECON vulnerability in the NetWeaver Java stack, for example, allowed unauthenticated attackers to create an administrative user, and similar critical flaws surface regularly. We confirm real exposure carefully, on non-production systems where possible, so we never risk your live financial data.

This is where ERP testing earns its value. We examine the authorization design for over-broad profiles, unchecked privilege escalation to SAP_ALL, and, most importantly, segregation-of-duties failures. A user who can both create a vendor and approve a payment to that vendor can commit fraud without any technical exploit at all. We trace those paths through the real business process.

Standard SAP accounts with known default passwords remain one of the most frequent and highest-impact findings. A single unchanged SAP* or DDIC password can grant sweeping access, and these accounts are documented publicly, so an attacker does not need to guess.

Interfaces built for system-to-system communication are often reachable by users who should never touch them. An open SAP Gateway or a permissive SAPRouter route can allow command execution or access to internal systems from outside the ERP boundary.

The classic ERP risk is a person holding two roles that should never be combined. Create-vendor plus approve-payment, or post-invoice plus release-payment, opens a direct route to fraudulent disbursement. We identify these SoD conflicts and show the concrete transaction sequence that would exploit them.

SAP releases patches through monthly security notes, and critical ones affecting NetWeaver, the Internet Communication Manager and other components appear regularly. Systems that lag behind on notes carry known, exploitable flaws. We identify which relevant notes are unapplied and rank them by real risk to your environment.

ERP systems rarely stand alone. They exchange data with banks, tax portals, warehouses and middleware, and those integration points are frequently authenticated with static credentials or trusted by IP alone. We test the interfaces and the trust between systems, since a weak link in an integration can hand an attacker the same reach as a compromised ERP account.

Each technical issue includes the impact, a CVSS score, the exact steps to reproduce it, and a specific remediation, whether that is applying a named SAP security note, resetting a standard account, or locking down a gateway ACL. Evidence accompanies every finding.

Segregation-of-duties conflicts are presented in business terms, with the transactions involved and the fraud scenario they enable, so your finance and audit teams understand not just that a gap exists but what it would cost. We recommend the role and authorization changes to close each one.

ERP changes cannot all happen overnight, so we rank fixes by risk and effort, giving you a defensible order of work. A free retest after remediation confirms the highest-risk issues are genuinely resolved.

ISO 27001:2022 control A.8.2 covers privileged access rights and A.8.3 information access restriction, both central to ERP authorization design. Segregation-of-duties findings also feed the financial-reporting controls that internal and external auditors examine, since ERP is where those controls are enforced or bypassed.

ERP platforms hold employee and customer personal data, bringing GDPR article 32 into play for the technical measures protecting them. Financial entities running SAP under DORA can fold the results into ICT risk-management reporting. Where the ERP touches cardholder data, PCI DSS 4.0 requirement 11.4 penetration-testing obligations apply. We map every finding to the framework you name and provide an attestation letter.

Whether you are on long-running ECC or have moved to S/4HANA, we test the NetWeaver foundation, the Fiori front end, and the HANA database layer beneath. A migration is a particularly good time to test, because roles are being rebuilt and authorization mistakes made during the project are easy to bake in permanently if nobody checks them.

The modules that move money and hold personal data draw the most attacker interest. We focus authorization and segregation-of-duties testing on the finance, procurement and payroll processes, tracing who can create a vendor, approve an invoice, change bank details, or run payroll, and which combinations of those rights create a fraud path.

For non-SAP estates we bring the same rigor to Oracle E-Business Suite and Microsoft Dynamics, covering their technical stacks, default and shared accounts, integration interfaces, and the authorization design that governs financial transactions. The platform changes, but the questions an attacker asks do not.