Would you know if someone
was already inside SAP?

Ask a security operations team what they would see if an attacker were active inside SAP right now. The answer is usually a description of what they would see on the way in — a VPN login, a jump host, a privileged account used at an odd hour. All useful. None of it tells you what was done after the session reached the application.

That gap is not negligence. It is architectural.

Why the SIEM does not see SAP

A SIEM is fed by sources that understand themselves: firewalls, endpoint agents, directory services, cloud control planes. SAP produces logs too, but the meaningful ones live inside the application layer and are written in SAP's own vocabulary — transaction codes, authorisation objects, table names, RFC destinations.

Forwarding the syslog from the host gives you the operating system's view: a process ran, a port was opened. It does not tell you that someone opened the debugger in production and changed a field value in memory to bypass a validation, because from the operating system's perspective nothing unusual happened at all. One process did what it always does.

Even where SAP audit logs are forwarded, they arrive as high-volume, low-context events that no generic correlation rule knows how to interpret. Most SOCs that receive them end up filtering them out, because a table maintenance event looks identical whether it was routine configuration or someone editing payment data directly.

What an SAP-aware detection layer actually watches

The activity worth alerting on is specific, and almost none of it is visible outside the application:

• Debug and replace in production. A developer-grade capability that allows a user to alter values at runtime and step past authorisation checks. There are few legitimate reasons for it in a production client, and it leaves no trace at the OS layer.
• Direct table maintenance. Editing financial or configuration tables through generic maintenance transactions rather than the business process that owns them.
• RFC gateway and message server abuse. Unregistered programs, unrestricted access control lists, and stored credentials in destinations that allow lateral movement from a sandbox into production.
• Transport activity outside a change window. Code moved into production at 2am on a Sunday is either an emergency everybody knows about, or it is not.
• Standard user accounts. SAP*, DDIC and their equivalents authenticating at all — particularly from an unexpected source.
• Privilege escalation through role assignment. A user granted SAP_ALL or an equivalent composite, used briefly, then removed.
• Reads at scale. Bulk download of customer, HR or payment data through a query tool, which looks like normal reporting unless volume and context are considered together.

Vulnerability management and threat detection answer different questions

These are routinely conflated in vendor conversations, and the distinction matters when you are deciding what to buy first.

Vulnerability management asks what is exposed. Which security notes are unapplied, which profile parameters are weak, which custom code contains an injection path, which RFC destinations store credentials. It produces a finite list of things to fix, and it is the right starting point because it removes the routes rather than watching them.

Threat detection asks what is being used. It assumes some exposure will always remain — because patching an ERP landscape takes months and there is always a business reason to defer — and watches for the exploitation itself.

An estate with neither should start with vulnerability management: there is no sense monitoring for the abuse of a hole you could simply close. An estate that has been patching diligently for two years and still cannot answer the question in the title of this article has the opposite problem.

The patch window is the real argument

SAP publishes security notes monthly. In most organisations the interval between a note being published and being applied in production is measured in months, not days — because regression testing an ERP landscape is genuinely expensive and the business will not accept unplanned downtime.

That interval is not a failure of process. It is a structural feature of running an ERP system. But it means there is always a known, published, publicly documented window during which your estate is exploitable in a way that is described in detail in a note anyone can read.

Detection is what covers that window. It is the compensating control for a patch cycle you cannot compress.

What to do first

• Establish whether SAP security audit logging is switched on and retained in production. In a surprising number of estates it is not, or it is retained for a fortnight.
• Find out who would receive an SAP alert today, and whether they would know what it meant. A detection feeding a SOC that cannot interpret it is a false comfort.
• Agree a small number of events you would treat as an incident — production debugging, standard account use, out-of-window transport — before buying anything.
• Write the response playbook alongside the detection. An alert with no agreed response is an alert that will eventually be muted.

The uncomfortable part

The first weeks of SAP threat detection are noisy, and much of the noise turns out to be legitimate. Production debugging is often routine somewhere in the organisation. Direct table edits are sometimes how a team has always fixed a recurring data problem. Standard accounts are occasionally still in use by an interface nobody wants to touch.

Each of those is a finding in its own right, and none is what people expect to spend the first month on. The temptation is to tune the alerts down until the console is quiet. The value is in the opposite: treating each as a practice to be changed, so that when the console is finally quiet the silence means something.