The short version. Read-only reconnaissance and analysis across the SAP web surface, RFC and gateway configuration, and ABAP-level authorisation patterns. No transports, no writes, no attempt to execute anything on the system.
What this engine does
SAP estates accumulate exposure in predictable places: a web dispatcher reachable further than intended, a gateway accepting registrations it should not, an authorisation object granted broadly years ago and never revisited.
- Web surface — ICM and Fiori endpoints reachable externally, information disclosure, transport security.
- RFC and gateway posture — registration and access-control configuration read for over-permissive settings.
- Authorisation review — critical objects and profiles that grant more than the role implies.
- ABAP-level patterns — custom code constructs associated with injection and authorisation bypass.
- Network-facing service posture around the SAP hosts you authorise.
What it deliberately does not do
On an ERP system, restraint is not caution — it is a requirement:
- No transports, no writes. Nothing is created, changed or moved between systems.
- No code execution. No function module or report is executed to prove a finding.
- No exploitation. Configuration weaknesses are evidenced by reading configuration.
- No credential forwarding. Credentials you supply are used against the system you named, never forwarded elsewhere, and never stored in our database.
- No load generation. Nothing here should be visible as performance impact to your users.
How we prove you are allowed to run it
Authorisation is a hard gate, not a checkbox in our terms. A scan starts only if the asset is verified by Domain Control Verification — you place a DNS TXT record or a file we specify — or you supply an explicit legal-authority attestation stating you own the target or are authorised to test it. A request carrying neither is refused with HTTP 403, at every tier, with no override. SAP systems run on an attestation, like Active Directory: they are private infrastructure with no public verification path, so your signed statement of authority is the record we retain.
Where your data goes, and when it is deleted
Everything runs on EU infrastructure: edge functions in EU regions, scan compute in Frankfurt, object storage under EU jurisdiction, model inference through an EU endpoint. Nothing is used to train any model — ours or a third party's — and that is a contractual term in the DPA, which every plan gets.
- The report — kept two years, so you can hand it to an auditor next year.
- Raw uploaded material — third-party scanner files 30 days, application binaries 60 days, then deleted automatically.
- The anonymous homepage preview — content erased after 24 hours.
- The authorisation record — kept, because it is the evidence that the scan was permitted.
The full schedule is in our Privacy Policy, and the sub-processor list is on the Trust Center.
How a run actually works
The assessment reads: the externally reachable web surface, the gateway and RFC configuration you expose to it, and the authorisation and custom-code patterns visible to the account provided. Analysis is comparative — what the configuration allows versus what this system's role requires.
Because the target is production-critical, the engine has no write path at all. There is nothing to disable and no flag to get wrong.
What you get at the end
Findings expressed in SAP's own vocabulary — the parameter, the profile, the authorisation object, the template — so a Basis or security team can act without translation. Each carries the evidence that established it and the change that closes it.
What this engine cannot find
Read-only analysis of an ERP has clear edges:
- Segregation-of-duties conflicts that depend on your business process design.
- Anything requiring execution to observe — runtime behaviour of custom code stays out of reach.
- Systems and clients not included in the assessment scope.
- Whether a permissive setting is compensated by a control elsewhere in your landscape.
- Patch-level verification beyond what the reachable surface reveals.
We publish this list for the same reason we publish our own assessment report, limitations section included: a vendor that cannot tell you what its tool misses is asking you to take the rest on faith.
Frequently Asked Questions
Can this be run against production?
It is designed for it: there is no write path, no code execution and no load generation. That said, coordinate with your Basis team as you would for any assessment.
What access is required?
Network reachability to the surface you want assessed, and where deeper review is wanted, an account with read access. Credentials are never forwarded to any other system and are not stored in our database.
Do you execute ABAP code to prove findings?
No. Code-level findings come from reading patterns in custom code, not from running it.
Does this cover segregation of duties?
Only where it is visible in authorisation configuration. True SoD analysis depends on your process design and belongs with a GRC review.
Why is SAP priced higher than the other engines?
The surface is larger, the analysis is specialised, and the engine runs conservatively by design against a system the business cannot afford to have disturbed.