Why SAP security needs its own RASP moment (Real-Time-Application-Self-Protection)

Network security learned long ago that detection alone is not enough. SAP application security has yet to catch up.

Network security has spent twenty years relearning one lesson: an alert on its own doesn’t stop anything. Every generation of perimeter tooling eventually added a way to block, not just flag, because waiting for a human to read an alert and react was too slow against attackers who move in seconds. SAP security hasn’t gotten there yet.

A pattern that already played out once

Intrusion detection systems (IDS) were the first generation of this kind of monitoring: they watched network traffic, compared it against known attack signatures, and raised an alarm when something matched. That worked, to a point but timing was the flaw. By the time an analyst had read the alert, the malicious packet was already at its target. Intrusion prevention systems (IPS) fixed that by using the same detection logic inline, so the packet could be dropped before it ever arrived.

The same evolution repeated one layer up the stack. Web application firewalls (WAF) filter HTTP traffic at the perimeter using rules and signatures, much the way an IDS does. Runtime application self-protection (RASP) took that further by moving the control inside the application itself: rather than watching traffic pass by, it can stop a dangerous operation the moment the application tries to execute it, with full visibility into the application’s own context.

Both shifts moved in the same direction: from watching to acting, and from the network edge closer to where the action actually happens. Hardly anyone in network security today would defend a detection-only setup. SAP security, for the most part, is still there.

SAP security is still mostly at the “IDS stage”

Most SAP-focused security tools on the market today work largely the same way: they flag a suspicious RFC call, a risky configuration, or a known exploit pattern, then hand it off to a SOC analyst or a Basis administrator to act on. That’s useful work, and a big step up from no visibility at all, but it leaves the same gap network security spent two decades closing. Attackers only need the time between detection and human response.

That gap matters more in SAP than almost anywhere else in the enterprise, because a single SAP system is often the single point of failure for finance, logistics, HR, and manufacturing all at once. An unauthorized export from a financial table, or a malicious RFC-triggered command, can do damage in seconds, long before anyone opens a ticket. Patching, meanwhile, is slow by design: SAP changes go through regression testing and change-control cycles that can take weeks, while attackers are exploiting new vulnerabilities within hours of disclosure. That window stays wide open.

If anything, SAP has less room for a detection-only approach than a typical web application does. It’s the environment where the case for inline blocking is strongest and, right now, where that capability is hardest to find.

Why the RASP layer matters

RASP is the piece that changes the equation. Without it, the other layers (Monitoring, Threat Intelligence, Vulnerability Management) still add up to a competent detection-and-cleanup operation well run, but reactive. With it, SAP security gains something network security spent two decades fighting for: the ability to stop a harmful action automatically, as it happens, instead of afterward.

Concrete RASP use cases in SAP

Some of the most common RASP use cases in SAP:

• Automatically deprovision Superusers (SAP_ALL) when newly granted and not agreed upon
• Automatically record all activities executed by SAP support (HyperLogging)
• Lock users for x minutes or hours when they execute critical data extractions
• Lock users when user IDs are shared
• Terminate sessions in case of lateral system movement
• Generate email alerts for newly introduced code vulnerabilities
• Alert for missing high severity patches
• Spur a dynamic MFA Challenge when a user executes transactions over X million Euros
• Spur a dynamic MFA Challenge when a user launches critical risky transactions
• Spur a dynamic MFA Challenge when a user downloads critical tables

The underlying techniques that make RASP work in SAP

A number of SAP-native techniques make this possible:

• Lock accounts
• Temporary lock accounts
• Deprovision accounts
• Activate HyperLogging
• Spur contextual or policy-based MFA
• Block transactions
• User Risk Rating
• MFA at critical transaction, program execution
• MFA at Fiori app start

The point isn’t to abandon detection

None of this argues against monitoring, threat intelligence, or vulnerability management all four layers matter, and none replaces the others. The point is simpler than that and already proven outside SAP: detection tells you what happened; only blocking stops it from happening.

Network security didn’t retire IDS when IPS showed up, or WAF when RASP did it added a layer that could act. SAP security is overdue for the same step.

Detection tells you what happened. SecurityBridge’s SAP-native platform can also stop it with controls that lock, block, and challenge in real time → Request a demo