DORA Names Legacy Systems Directly: What Financial Entities Must Do About End-of-Life ICT

Last updated: July 17, 2026  ·  For ICT risk owners, CISOs, and compliance leaders at financial entities in scope of DORA

Most regulatory articles are countdowns. This one is not. The Digital Operational Resilience Act — Regulation (EU) 2022/2554, universally shortened to DORA — entered into force on January 16, 2023 and has applied since January 17, 2025. There is no transition window left to plan around. For banks, insurers, investment firms, payment institutions, crypto-asset service providers, and the other financial entities in its scope, DORA is current law, and supervisors are reviewing ICT risk frameworks against it today.

What makes DORA different: it says "legacy" out loud

Because DORA is a regulation, not a directive, it applies directly and uniformly across the EU — there is no national transposition to wait for, and no variation to arbitrage. Under the regulation as adopted, in-scope financial entities must operate an ICT risk-management framework, run digital operational resilience testing, report major ICT incidents, and manage the risk in their ICT third-party arrangements — and DORA also brings critical ICT third-party providers themselves under oversight.

Buried in that framework requirement is something genuinely unusual. Most cybersecurity law speaks in abstractions — "appropriate technical measures," "state of the art." DORA, under the regulation as adopted, expects financial entities to identify and account for legacy ICT systems specifically within their risk framework. The word appears in the law. That matters, because "legacy" is usually a term of art that lives in engineering retrospectives and budget fights, deniable precisely because no regulator ever defined it as a category. DORA ends the deniability: legacy ICT is a named risk class, and the management body that owns the ICT risk framework owns it.

And no sector needed the naming more. Finance runs the oldest software estates in the private sector — core banking platforms measured in decades, settlement systems that predate the euro, batch jobs nobody dares touch. The industry that invented "if it ain't broke, don't upgrade" is now the industry whose regulator wrote "legacy" into binding law.

An EOL component is the purest form of legacy ICT

"Legacy" can be argued about at the edges. Is a five-year-old system legacy? A stable one with no roadmap? But there is one case with no edges at all: a component past its end-of-life date. Once the vendor or maintainer stops shipping security updates, three things become permanently true:

• No patches. Every CVE discovered from that day forward will never receive an official fix. The exposure does not plateau — it compounds monthly.
• No vendor recourse. When the system fails or is breached, there is no support contract to invoke and no escalation path. The entity carries the full weight alone — an uncomfortable fact to explain in an incident report.
• No ambiguity. Unlike "old," EOL is a dated, documented, third-party-verifiable status. A supervisor does not need to accept your definition of legacy to flag it; the lifecycle date does the work.

This is why EOL software is where any credible legacy-ICT exercise starts. It is the subset of legacy that can be established objectively, ranked by severity, and defended line by line in front of an auditor.

The first question is always the inventory

Put yourself in the reviewer's chair — internal audit, external audit, or the supervisor examining your ICT risk framework. The framework document says legacy ICT is identified and managed. The natural first question: "Show me the inventory." An entity that cannot produce a current list of its EOL and near-EOL systems fails at the first question, regardless of how polished the framework prose is. And what an honest first inventory finds in a financial estate is rarely exotic — it is this:

Note the spread: one entry went EOL this month, one goes EOL this year, and two have been dead for years while quietly running production workloads. A legacy inventory that only captures the ancient systems misses the ones about to turn — and the ones that turned last Tuesday.

A DORA-ready EOL process

DORA does not prescribe tooling. But an ICT risk framework that identifies and accounts for legacy systems implies four working parts, and each maps to something you can stand up this quarter:

1. A continuous inventory, not an annual audit

Upload dependency manifests to the scanner to sweep whole estates for lifecycle status at once, or check individual systems with the EOL checker. For the software you build in-house, gate CI on the API so a dependency that goes EOL fails the build loudly instead of shipping into a regulated environment quietly:

curl https://api.endoflife.ai/v1/status/oracle-jdk/8

2. Lifecycle dates tracked against a live source

Vendors extend, accelerate, and clarify EOL dates; a spreadsheet snapshot goes stale between board meetings. EOL Watch tracks the dates as they move, and every product page publishes an .ics calendar feed so lifecycle deadlines sit in the same calendar as your change-management and testing cycles.

3. A number the framework can actually ingest

An ICT risk framework runs on quantified inputs, and "this server is old" is not one. The EOL Risk Score reduces each component's EOL posture — recency, exposure, exploitation signals — to a 0–100 number that slots directly into a risk register, sets remediation order, and gives the management body a trend line it can be accountable for.

4. A documented bridge for what cannot migrate in time

Some systems will not be migrated this year — the core platform rewrite runs on its own decade. For those, commercial extended support can keep security patches flowing after the official EOL date. Be honest about what that is for a regulated entity: a documented compensating control while migration completes, not an exemption. The framework still needs the migration plan, the timeline, and the residual-risk assessment sitting next to the support contract — but a paid patch stream with paperwork is a defensible answer, and an unpatched system with none is not. This article is not legal advice; verify your entity's specific obligations against the regulation text and your supervisor's guidance.

Where DORA sits in the EU triangle

Three EU instruments now converge on end-of-life software from different angles. The Cyber Resilience Act covers the products you ship. The NIS2 directive covers the infrastructure you run, across essential and important sectors. DORA is the financial sector's stricter cut: directly applicable, already in force, and alone in naming legacy ICT as a category. Non-compliance runs through supervisory measures and enforcement by competent authorities — and for a financial entity, a supervisory finding carries its own gravity well before any formal sanction, because it surfaces in the next audit, the next license interaction, and the next cyber-insurance renewal.

The uncomfortable summary for the sector with the oldest estates: the law that governs you is the one already in effect, and it asks for the one document decades of technical debt made hardest to produce. Start with the EOL subset — it is the part of the legacy problem you can inventory this week, score this month, and defend at the first question.

Frequently Asked Questions

Related Resources

• The EU Cyber Resilience Act Has an EOL Problem — the products you ship
• NIS2 and EOL Software — the infrastructure you run
• Oracle Java Licensing and EOL — why JDK 8 estates carry double risk
• Cyber Insurance and EOL Software: What Underwriters Now Ask
• Dependency Scanner — inventory a whole estate at once
• EOL Watch — lifecycle date changes, tracked live
• EOL Risk Score — a 0–100 input for your ICT risk framework
• Extended Support Vendors — the documented bridge while migration completes