Your EOL Open Source Is a DORA Compliance Problem. Here’s How to Fix It.

If you work at a European financial institution or a software vendor that serves one, there’s a good chance something in your software stack became a regulatory liability on January 17, 2025. That’s the date the Digital Operational Resilience Act (DORA) entered mandatory enforcement across the EU. Most of the conversation around DORA focuses on incident reporting, third-party risk contracts, and resilience testing. Those are important. But there are elements that should be top of mind for engineering and security teams, and it has everything to do with the end-of-life (EOL) open source software you’ve been meaning to migrate off of.

What DORA Actually Says About End-of-Life Software

DORA introduces a specific concept that should be on every compliance officer’s radar: the Legacy ICT System. Article 8, Section 7 specifically requires financial entities to conduct ICT risk assessments on all Legacy ICT Systems, and specifically before and after connecting any technologies, applications, or systems to them.

The regulation defines a Legacy ICT System as an ICT system that has reached the end of its lifecycle, is not suitable for upgrades or fixes, is no longer supported by its supplier or by an ICT third-party service provider, but is still in use and supports the functions of the financial entity.

This means that companies using EOL versions of open source software are operating what DORA considers a “Legacy ICT System”.

With this designation comes compliance obligations: annual risk assessments at a minimum, mandatory reviews before and after integrating anything with that system, documented justification for keeping it running, and heightened scrutiny during regulatory inspections. For most organizations, that translates directly into more audit prep, more change-management overhead, and more friction for the engineering teams that touch those systems.

Two Current Real World Examples

CVE-2026-22732: This critical security header omission vulnerability in Spring Security carries a CVSS 3.1 base score of 9.1 out of 10. You can find the full details in the National Vulnerability Database. 

This vulnerability affects Spring Security versions stretching back as far as 5.7.x. And for all EOL versions, there is no upstream patch. Financial institutions, or an ICT provider serving one, running EOL Spring reliant on legacy Spring Security have a system that qualifies as a Legacy ICT System under DORA, contains a critical unpatched access control bypass with a 9.1 CVSS score, triggers mandatory annual and integration-point assessments, and creates a documented compliance gap under DORA.

CVE-2020-17531: This CVE is a critical remote code execution vulnerability found within the java web framework Tapestry 4.x. Tapestry is commonly used by large enterprise financial applications. You can find the full details in the National Vulnerability Database.

Apache Tapestry 4.x is already end-of-life. There will no longer be any upstream patches. There never will be anymore from the original maintainers because they have already moved on to Tapestry 5.x years ago. If you’re a financial institution or an ICT provider serving one, running Tapestry 4.x, you now have a system that simultaneously qualifies as a Legacy ICT System under DORA, contains a critical unpatched RCE, triggers mandatory annual and integration-point assessments, and creates a documented compliance gap under DORA.

To see if your organization could also be impacted, the HeroDevs Vulnerability Directory tracks hundreds of CVEs across EOL frameworks that are still widely deployed in enterprise environments, including critical issues in end-of-life versions of Spring Boot, NodeJS, .NET, AngularJS, Next.js, Angular, and many more.

So What Do You Actually Do About It?

The obvious answer is "migrate to a supported version." While that’s the right long-term play, anyone who’s led a major framework migration knows the reality: these projects take time, require extensive regression testing, compete with product roadmap priorities, and require significant resources. 

This is where HeroDevs Never-Ending Support (NES) comes in, and why it’s particularly relevant under DORA.

NES provides commercial long-term support for open source software that has reached end-of-life. HeroDevs engineers maintain the EOL codebases, backport security fixes, and publish patched releases as drop-in compatible packages through standard registries (npm, Maven, PyPI). No architectural changes required. 

How NES Changes the DORA Impact

Here’s the key insight: DORA’s definition of a Legacy ICT System hinges on the system being "no longer supported by its supplier or by an ICT third-party service provider." When HeroDevs provides NES for an EOL component, that condition is no longer applicable. An enterprise will now have an active third-party service provider maintaining the software. Under DORA’s own definition, the system is no longer a “Legacy ICT System”.

This reclassification eliminates the additional compliance overhead: no more mandatory annual assessments of that system, no pre/post integration reviews, no documented justification for continued use of unsupported software. The audit surface shrinks. The engineering friction drops. The compliance and security teams receive a contractual commitment to patch critical vulnerabilities, with the release history and audit trail to prove it.

Common Questions

Does DORA only apply to banks?

No. DORA applies to a broad range of EU financial entities: banks, investment firms, insurance companies, crypto-asset service providers, payment institutions, and more. It also applies to the Critical ICT Third-Party Providers that serve them, cloud providers, software vendors, and data analytics platforms. If a service could cause systemic risk to a financial institution, it is most likely in scope.

My EOL dependency is deep in the stack. Does it still count?

Yes. DORA’s Legacy ICT System definition doesn’t distinguish between front-end frameworks and deep infrastructure libraries. If it’s reached end-of-life, is no longer supported, and is still in use, it qualifies. 

We’re planning a migration. Are we exempt? 

Until the migration is complete, the system is still subject to the full assessment requirements under Article 8, Section 7. NES is useful precisely in this scenario: it bridges the gap between "we know we need to migrate" and "the migration is done," keeping you out of the Legacy ICT category while your engineering team does the work properly and on its own timeline.

The Bottom Line

DORA is in force, and has been for well over a year. DORA’s definition of a ‘Legacy ICT System’ maps directly to include end-of-life open source software. The compliance requirement for that designation is real, recurring, and visible to regulators.

If an organization is in scope and the technical stack includes EOL dependencies, and nearly all stacks do, the question isn’t whether this is a risk. It is. The question is what to do about it. HeroDevs Never-Ending Support is one of the most cost-effective, industry-recognized, and assured ways to close the gap: remove the Legacy ICT designation, get critical vulnerabilities patched, and give your compliance team peace of mind and something defensible to show regulators.

Start by checking what’s in your stack. The HeroDevs End of Life Dataset is a free resource that tracks 12 million+ package versions and enables enterprises to see which EOL frameworks have known, unpatched CVEs, and what NES support is available for them.

‍