SAP Patches Get Exploited in Days Now. Regression Testing Still Takes Weeks.

What the report found

On 29 October, Onapsis Research Labs published a summary of its 2026 SAP threat report, written with Recorded Future and titled Days to Zero. The headline finding: for SAP vulnerabilities patched in 2025 and 2026, the median time between a Security Note being released and verified public exploitation or a published proof of concept was one to three days. For vulnerabilities patched in 2021, the same median was 489 days.

The analysis draws on more than 1.2 million threat intelligence events from 2023 to mid-2026. Onapsis also reports SAP-relevant threat documents rising from 791 in 2023 to 2,458 in 2025, and distinct ransomware and extortion groups appearing in that content rising from eight to 26.

For scale, Onapsis counted 21 new and updated Security Notes on the October 2026 patch day, three of them HotNews.

What the median does not say

"One to three days" combines two different events: verified public exploitation, and publication of a proof of concept. A public proof of concept is not an attack on a production system. Both are reasons to move; they are not the same reason, and the summary does not split them.

The same page gives a range alongside the median: for every SAP CVE with verified first-exploitation observations since April 2025, exploitation was seen 0.3 to 24 days after disclosure. That is considerably wider, and no sample size is published behind either figure.

The 489-day comparison carries its own caveat. Observation of SAP exploitation has improved enormously since 2021, so some of that collapse is attackers moving faster and some is the industry finally watching; without per-year sample sizes you cannot say how it divides. Onapsis also sells SAP security products, so read its data as data and its recommendations as positioning. None of which makes the direction wrong: a quarterly patch cycle is indefensible against any reading of these numbers.

Why this lands on the test team

Here is the part the security coverage leaves out. If the exploit window is days, an organisation that wants to patch inside it must answer a question with nothing to do with security: can we prove, in days, that the patch did not break order-to-cash?

For most ERP estates the honest answer is no, and not through laziness. The regression evidence from the last go-live is usually a spreadsheet: a record that someone tested something once, months ago, with initials and a green cell. That is an event, not a runnable asset, which is the structural problem with spreadsheet-based UAT. Nobody can pick it up on a Tuesday and re-execute the subset touching the patched component, because that subset was never identified and the steps were never written for somebody else to repeat.

So the decision degrades into two bad options: apply the note untested and find out at month-end close, or defer it for a proper test window — which on a busy estate means next quarter, a 489-day posture against a one-to-three-day clock.

It is the same shape as the capacity gap that forced PostgreSQL to revert features before its 19 release: detection got fast, disposition did not. Which is presumably why Onapsis's first recommendation is to move from patch management to exposure management, with compensating controls where patching must wait — a sensible answer to the window, and a quiet admission that patch-and-test cycles cannot keep pace.

Business Central teams already live here

SAP estates are arriving here through security; Business Central estates came by another road. A Business Central tenant updates on Microsoft's schedule, not the client's, and deprecations arrive attached to version numbers rather than negotiated dates. Exposing a Microsoft page as a SOAP endpoint stopped being possible in version 29, a retirement with real regression scope attached, and Microsoft documents the equivalent OData page endpoints for removal in version 30. Retiring the twice-yearly release plan documents changed how teams find out what is coming without changing how fast it arrives.

The common factor is not the vendor. It is that somebody outside the project changes the system on a clock nobody on the project controls.

What a days-not-weeks pack looks like

A named regression subset per component. Not "the regression pack", but scripts tied to what a given component actually touches, so an emergency note produces a defined scope rather than a scoping meeting. Regression scope decided in advance is the difference between hours and weeks.

Scripts written for a stranger. A test is re-runnable when somebody who did not write it can execute it and reach the same expected result. That is the entire bar.

A measured runtime for the critical path. If nobody can say how many hours those scripts take, no emergency patch can be planned around them. Measure it once, on a real cycle, and write it down.

A record that separates tested from accepted. Patching inside a days-long window means knowingly going live with coverage gaps. That is legitimate provided a named person accepted the gap in writing on the date, which is what a sign-off process is for. Unrecorded, it becomes a surprise with no owner.