What should teams do when exposed SAP instances cannot be patched immediately?

Why containment matters before patching

When an exposed SAP instance cannot be patched right away, the immediate goal is to shrink the reachable attack surface, not to accept the exposure and wait. The practical question is whether the vulnerable service can still be contacted from places it never needs to trust. If the answer is yes, teams should treat that as a temporary control failure and reduce access until maintenance is possible.

The key idea is that most emergency exposure is about reachability. If the dispatcher or related remote functions remain open to broad networks, a parser flaw or similar pre-authentication issue can often be exercised before any credential check ever helps. Containment is therefore the fastest way to change the attacker’s options while preserving business access through narrower, better-controlled paths.

How to reduce exposure without breaking legitimate access

Containment should be built around the smallest set of allowed paths that still supports operations. For SAP, that usually means narrowing reachability to trusted subnets, moving administrative or remote access through SAProuter, and removing any unnecessary external path to the dispatcher. Those steps preserve a controlled route while cutting off ambient internet exposure that rarely needs to exist during a patch delay.

This is also where teams should be deliberate about exceptions. If a business process depends on the service being reachable, the exception should be explicit, time-bound, and tightly scoped. The point is not to make the system invisible, but to make the remaining exposure understandable, reviewable, and much harder to abuse.

What good looks like during a delayed remediation window

Good handling of an unpatched exposed SAP system is visible in the network path, not just in the ticket queue. A well-contained instance has only the minimal ingress it needs, remote administration is forced through the approved intermediary, and all other routes are blocked or disabled until the patch window opens. Teams should be able to explain exactly who can reach the system, from where, and for what purpose.

That operating state matters because delayed patching is often unavoidable. What separates disciplined response from drift is whether the exposure is actively bounded while the patch is pending. If the system still looks “open but monitored,” the organisation has not really reduced risk; it has only postponed the decision.

Practitioner Guidance

What to prioritise: Reduce the reachable surface first, then schedule the fix. If the vulnerable SAP component is externally reachable, containment should take precedence over convenience, because pre-authentication flaws are often exploitable without any internal foothold.

What to verify: Confirm that only trusted subnets can reach the service, that SAProuter is the approved path for remote access, and that any direct external dispatcher exposure has actually been removed rather than merely documented. Verification should be network-based, not only procedural.

Decision rule: If you cannot patch immediately, do not leave the service in its normal exposure state. Accept a narrower, controlled access pattern temporarily, and treat any exception that preserves open internet reachability as a higher-risk condition requiring explicit approval.

Practitioner takeaway: When patching is delayed, the control objective shifts from “fix now” to “make exploitation harder now”; if reachability is not reduced, the organisation is still operating on borrowed time.

Related resources from NHI Mgmt Group

• How should security teams reduce exposure when PAN-OS management interfaces cannot be patched immediately?
• How should teams reduce risk from RFC-exposed SAP vulnerabilities?
• What breaks when healthcare teams cannot see exposed credentials early?
• How do security teams decide whether a vulnerable platform is exposed enough to patch immediately?