Legacy is no longer just debt
The ECB letter, the Polish regulator and SAP ECC

In 2018 and 2019 attackers needed an average of 63 days from disclosure of a vulnerability to exploiting it. That was Mandiant’s measurement; the incident response firm is now part of Google. In M-Trends 2026, Mandiant estimates the mean time to exploit at minus seven days: on average, exploitation starts a week before the vendor releases a patch. VulnCheck, which tracks exploited vulnerabilities, reports that in the first half of 2026 almost one in four known exploited vulnerabilities was attacked on or before the day its CVE record was published.

The European Central Bank (ECB) has drawn its own conclusion for the banks it supervises directly. Each must submit an action plan by 31 October, and legacy and unsupported systems belong in it. For anyone running SAP ECC, the previous generation of SAP’s ERP system, that question already has a calendar attached: mainstream maintenance ends in 2027.

We are not neutral observers. SNOK earns its living from SAP security, monthly SAP Security Patch Day support and SAP S/4HANA conversions. The argument we want to make does not sell any of those directly, though. A conversion date is not a protection plan. A plan says what protects the system until the day it is switched off.

Cover image generated by AI.

What the ECB letter says about legacy technology

Letter SSM-2026-0301, dated 7 July 2026 and signed by Claudia Buch, Chair of the ECB Supervisory Board, went to the chief executive of every significant institution, meaning the largest euro-area banks under direct ECB supervision. The diagnosis takes a single paragraph: the most capable AI models, often called frontier AI, find vulnerabilities and generate working exploits at unprecedented speed, and the ECB treats this as a long-term shift in the threat landscape rather than a passing phenomenon tied to one tool. Responsibility sits with management bodies.

The plan goes to each bank’s Joint Supervisory Team (JST), the ECB team that supervises it, and has to set out concrete measures, resources, roles and timelines. The short-term focus is patching at scale, monitoring and detection, the risk posed by information and communication technology (ICT) providers, and anything exposed to the internet. Legacy systems appear among the structural, longer-term measures, and the annex is precise about them: replace or update such systems or, where replacement is not feasible, provide comprehensive protection through additional controls.

That last clause is, in our view, the most important line in the letter. The ECB does not pretend a bank can replace everything within a quarter. It asks what will protect a system until it is replaced.

The second passage we read with SAP in mind concerns patching itself. The ECB expects more frequent, higher-volume fixes from vendors, from open-source communities and from banks’ own software. It wants change management that allows urgent fixes to go in quickly without destabilising operations, the same expectation written into contracts and service level agreements (SLAs) with ICT providers, and teams staffed for the new pace. To free up time for the plan, it moved the annual IT Risk Questionnaire from September 2026 to February 2027.

Poland: the same expectations, applied to the whole market

Poland is outside the euro area, so Polish banks are not addressees of the ECB letter. Several of them do belong to banking groups that are, and we expect questions about legacy estates to reach Polish subsidiaries from group headquarters.

What the Polish regulator did matters more. Over the summer, the Office of the Polish Financial Supervision Authority (UKNF) published recommendations on the impact of frontier AI models on cybersecurity, addressed to every financial-market entity, not just banks. Much of the document mirrors the ECB letter: an action plan with measures, resources, responsibilities and a timetable, the same short-term areas, and modernisation through replacing or updating outdated, unsupported or end-of-life technology.

UKNF set no deadline. Instead, it said that the adequacy and effectiveness of what firms put in place will be examined in ongoing supervision and during inspections. Two sentences stand out for boards. First, DORA, the EU regulation on digital operational resilience in the financial sector, requires not only strategies, policies and procedures but also evidence that they work. Second, vulnerability priorities should follow actual risk, not scores on the Common Vulnerability Scoring System (CVSS) alone, which rates technical severity.

Legacy in SAP goes beyond the release number

In the SAP world, the legacy conversation usually starts with dates. Mainstream maintenance for SAP ECC ends in 2027, with extended maintenance available at extra cost until 2030. The years 2031 to 2033 are only available to systems moved to SAP ERP, private edition before the end of 2030, which in practice means RISE with SAP, SAP’s bundle of licence and cloud operations. We covered this in more detail in our piece on vendor lock-in. For systems run in the customer’s own infrastructure, 2030 remains the limit.

The calendar is only part of the picture. The UK National Cyber Security Centre (NCSC) put it most plainly: technology that is out of support cannot receive updates. Around an ageing ERP release, years of accumulated estate can be just as outdated: custom ABAP code nobody has reviewed for security, RFC (remote function call) interfaces set up for projects long since closed, older kernels and third-party add-ons no longer maintained by anyone.

Then there is pace. SAP releases security fixes every month on the second Tuesday, as SAP Security Patch Day - we went through every item in the October release. If the volume rises, as both the ECB and the NCSC expect, the bottleneck shifts from knowing what to patch to being able to change a production system: maintenance windows, regression testing, sign-off from process owners and the terms of the support contract.

A conversion date is not a protection plan

A plan that gives SAP ECC nothing more than a conversion date to SAP S/4HANA answers half of the ECB’s question. The other half is what protects the system in the years before that date. In our view the answer needs at least four parts.

• An inventory with owners. Releases, kernels, interfaces, custom code and third-party add-ons, each with a named owner. Both the ECB and UKNF start with asset identification, because without it every priority list is guesswork.
• A patching rhythm you can prove. Time from publication of an SAP Security Note to deployment in production, measured every month, and a clause in the support contract that guarantees it. That is precisely the evidence of effectiveness UKNF is asking for.
• Compensating controls where no patch will come. Network segmentation, interfaces cut down to what is needed, monitoring of SAP security logs and regular authorisation reviews.
• A code review before conversion. Moving to SAP S/4HANA carries custom ABAP code across together with its vulnerabilities. Security checks can run in the same pass as readiness checks, as we described for the central ATC on SAP BTP; the limits of readiness checks themselves are covered in our SAP S/4HANA readiness analysis.

The conversion date should not move simply because a letter arrived. It should, however, be costed honestly, including the cost of running compensating controls until cutover. An earlier conversion may turn out cheaper than the original business case suggested. If it does not, the protection plan becomes the main body of the document rather than an appendix.

Banks in ECB-supervised groups file their plans by 31 October. The rest of the Polish financial market has UKNF recommendations with no deadline but with inspections to follow. At SNOK we build this kind of plan for SAP landscapes through our NIS2 and DORA audit, monthly SAP Security Patch Day support and SAP S/4HANA conversion.

Sources

• European Central Bank, Claudia Buch, “Addressing AI-enabled cybersecurity threats”, SSM-2026-0301, 7 July 2026 - ECB letter, PDF (accessed 21 October 2026)
• Office of the Polish Financial Supervision Authority (UKNF), recommendations for financial-market entities on the impact of frontier AI models on cybersecurity, in Polish, page updated 22 July 2026 - UKNF document, PDF (accessed 21 October 2026)
• Google Cloud, Mandiant, M-Trends 2026, 23 March 2026 - report announcement (accessed 21 October 2026)
• Google Cloud, Mandiant, Casey Charrier, Jared Semrau, “Analysis of Time-to-Exploit Trends: 2021-2022”, 28 September 2023 - Mandiant analysis (accessed 21 October 2026)
• VulnCheck, Patrick Garrity, “State of Exploitation 1H 2026”, 28 July 2026 - VulnCheck report (accessed 21 October 2026)
• NCSC, Ollie Whitehouse, “Preparing for a ‘vulnerability patch wave’”, 1 May 2026 - NCSC blog (accessed 21 October 2026)
• CERT-EU, “AI is changing the economics of vulnerability discovery. Defenders should adapt now”, 21 April 2026 - CERT-EU blog (accessed 21 October 2026)
• SAP News, SAP S/4HANA maintenance to 2040 and SAP Business Suite 7 to 2027, 4 February 2020 - SAP announcement (accessed 21 October 2026)
• SAP News, Stefan Steinle, SAP ERP, private edition, transition option, 4 August 2025 - SAP announcement (accessed 4 October 2026)