Your EOL Open Source Is an EU Cyber Resilience Act Problem. Here’s How to Fix It

If your organisation builds software or provides software-based products into the European Union, or sells to companies that do, something in your software stack has, and very likely will, become a major legal liability. The EU Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, entered into force on 10 December 2024. Its reporting obligations begin on 11 September 2026, and full product conformity is required by 11 December 2027, should you not conform, you can fall foul to fines up to the higher of €15 million or 2.5% of your total worldwide annual turnover, or even be required to entirely remove your products from the EU market. 

Most of the conversation around the CRA focuses on secure-by-design requirements, CE marking, and conformity assessments. Those matter. But there is an obligation that should be top of mind for every organization's senior leadership, especially for the engineering and security team shipping products that contain open source dependencies: the CRA makes end-of-life (EOL) software in your product stack a legal liability, not just a technical one.

The CRA does not care that your upstream framework reached end-of-life. It cares whether you — as the manufacturer placing a product on the EU market — ensure that it is supported and receiving patches for vulnerabilities. If this is not the case, a compliance gap with real financial consequences may arise.

‍

What the EU CRA Actually Says About End-of-Life Software

The CRA applies to “products with digital elements” — meaning hardware and software that connect to a device or network, including on-premises software, hosted / SaaS products, and the open source components embedded within commercial products. The moment your company provides a product containing open source code to the EU market, all CRA obligations attach to you as the manufacturer.

Three interlocking obligations create the EOL problem:

The Support Period Requirement (Article 13.8); Manufacturers must determine and declare a support period during which they will handle vulnerabilities effectively. This period must be at minimum five years, and potentially longer for products expected to remain in use beyond that window. During the support period, manufacturers must actively patch vulnerabilities — including in embedded components. If one of those components is EOL and has no upstream maintainer, you still own the obligation.

The Vulnerability Reporting Requirement (Article 14 — applies from 11 September 2026)

From September 2026, manufacturers must report actively exploited vulnerabilities in their products via the ENISA Single Reporting Platform to their designated national CSIRT, with the notification simultaneously accessible to ENISA. The reporting timeline is staged: an early warning within 24 hours of becoming aware of active exploitation, a full vulnerability notification within 72 hours, and a final report within 14 days of a corrective measure being available. If your product is provided with an EOL framework and a CVE against it is actively exploited, this clock starts immediately — regardless of whether your upstream maintainer has issued a patch. If there is no patch because the project is EOL, your obligation to report and remediate still stands.

The SBOM Requirement (Annex I — fully enforceable December 2027)

Manufacturers must maintain a software bill of materials in a machine-readable format covering all components in their product. This creates explicit visibility into your dependency tree — and a direct audit path for regulators to check whether any component has reached end-of-life. You cannot report what you cannot see, and you cannot claim compliance for a component you have not tracked.

These three requirements operate together. An EOL dependency creates a cascading failure: you cannot patch it, you cannot meet your vulnerability handling obligations, and your SBOM will expose the gap. The result is a documented compliance breach visible to regulators.

‍

This Is Not Just a Technical Problem

Unlike many technical standards, the CRA carries significant financial penalties. Non-compliance can result in fines of up to €15 million or 2.5% of global annual turnover, whichever is higher. The regulation also has extraterritorial reach: non-EU companies are in scope if they sell or distribute applicable products into the EU market.

Critically, the CRA is product-centric and lifecycle-wide. Obligations run from the moment a product is placed on the EU market through the entire support period — which must be at least five years. Additionally, under Article 13.9, any security update issued during the support period must remain available to download for at least 10 years after it was issued, or for the remainder of the support period, whichever is longer. This creates a long tail of availability obligations even after active patching ends. If your product today contains AngularJS (EOL since December 2021), Angular 18 or earlier (EOL), Spring Security 5.x or 5.8.x (EOL), Node.js 18 (EOL), or Vue 2 (EOL), you already have a gap in the vulnerability handling chain. 

‍

Two Real-World Examples

CVE-2026-22732: Spring Security — CVSS 9.1 (Critical)

This critical vulnerability in Spring Security causes HTTP security response headers to silently not be written under certain conditions — specifically when responses are committed before Spring Security’s filter chain can write them (a “lazy” header writing issue that is the default behaviour). Headers such as Cache-Control, X-Frame-Options, Strict-Transport-Security, and Content-Security-Policy are simply absent from the response. It affects Spring Security versions stretching back to 5.7.x. For all EOL versions, there is no upstream patch. If your product shipped into the EU market relies on legacy Spring Security, you have a system that:

• Contains a critical unpatched vulnerability that silently drops HTTP security headers (CVSS 9.1), with no upstream fix available for EOL versions
• Cannot meet its Article 13.8 vulnerability handling obligation during the declared support period
• Triggers a staged Article 14 reporting obligation — 24-hour early warning, 72-hour full notification, 14-day final report — the moment active exploitation is confirmed, with no upstream patch to reference
• Will expose the unsupported component in your SBOM, creating a visible audit gap

‍

CVE-2026-27970: Angular — XSS via i18n ICU Messages (CVSS 7.6, High)

This high-severity cross-site scripting vulnerability affects Angular’s internationalisation (i18n) pipeline. When ICU messages (used for complex translations like pluralisation and gender-specific text) contain HTML that is not properly sanitised, an attacker who compromises an application’s translation files can inject arbitrary JavaScript that executes in the victim’s browser. Angular versions up to 18.2.14 and earlier are affected. Angular 18 reached end-of-life, and Angular versions 4 through 17 have been EOL for even longer — the Angular team does not backport security patches to EOL versions. If your product shipped into the EU market uses any EOL Angular version, you have:

• A known XSS vulnerability in a component with no upstream patch available for EOL versions
• A breach of your Article 13.8 obligations — you cannot patch what the upstream project no longer maintains
• A staged Article 14 reporting obligation — 24-hour early warning, 72-hour full notification, 14-day final report — once active exploitation is confirmed, with no upstream remediation to reference
• An SBOM entry showing an unsupported Angular version, directly visible to your national market surveillance authority

The HeroDevs Vulnerability Directory tracks hundreds of CVEs across EOL frameworks still widely deployed in enterprise products, including critical issues in end-of-life versions of Spring Boot, Node.js, .NET, AngularJS, Angular, and many more.

‍

So What Do You Actually Do About It?

The long-term answer is migration to a supported version. But anyone who has led a major framework migration knows the reality: these projects take months or years, require extensive regression testing, compete with product roadmap priorities, and consume significant engineering resources. In a CRA-regulated environment, the stakes are higher still — you cannot afford to rush a migration that will be scrutinised by regulators and market surveillance authorities - Not to mention the administrative burden in itself when completing a migration.

The September 2026 reporting deadline is not waiting for your migration to complete. If a CVE against your EOL dependency is actively exploited, your 24-hour reporting clock starts immediately. This is where HeroDevs Never-Ending Support (NES) comes in.

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 CRA Picture

The CRA’s vulnerability handling obligations attach to you as manufacturer because you are shipping the product. NES changes the practical reality of meeting those obligations.

When HeroDevs provides NES for an EOL component, that component has HeroDevs providing security patches, maintaining a CVE response process, and publishing fixes on a documented timeline. HeroDevs NES directly addresses the Article 13.8 requirement to handle vulnerabilities in embedded components effectively during the support period.

In concrete terms, NES changes the compliance picture as follows:

• Vulnerability handling: Patches are available for EOL components. Your Article 13.8 obligation to handle vulnerabilities in embedded components can be met, because NES engineers backport fixes to the EOL codebase and ship them through standard registries.
• Staged reporting: When active exploitation of a CVE is confirmed against an NES-covered component, HeroDevs triages, patches, and ships the fix. You have a corrective measure in progress to reference in your Article 14 reports — not an open gap.
• SBOM accuracy: Your software bill of materials shows a supported component with an active vendor and a patching track record, not an unsupported EOL dependency. This is what regulators and market surveillance authorities will see, and will satisfy your Annex I SBOM requirement. 
• Audit trail: NES provides a contractual commitment to patch critical vulnerabilities, with release history and documentation to demonstrate ongoing compliance through your declared support period.
• Migration runway: NES bridges the gap between “we know we need to migrate” and “the migration is done,” allowing your engineering team to execute the migration properly and on a defensible timeline, while your CRA obligations remain met in the interim.

‍

Common Questions

Does the CRA only apply to EU companies?

No. The CRA has explicit extraterritorial reach. Non-EU manufacturers are in scope if they sell or distribute products into the EU market. This mirrors the approach of GDPR. If your product — or a product you build for a customer — is placed on the EU market, the obligations apply to you regardless of where you are incorporated.

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

Yes. The CRA’s vulnerability handling obligations cover the product’s components, not just its surface layer. Article 13.8 requires manufacturers to handle vulnerabilities “of that product, including its components.” Regulators will look at your full SBOM, not just the components that are user-facing. A deep infrastructure library with an unpatched CVE is still your problem.

We are planning a migration. Are we exempt in the meantime?

No. The September 2026 reporting obligations and December 2027 conformity requirements apply regardless of your migration roadmap. A migration plan is not a remediation — it is an intention. Until the migration is complete and the EOL component is gone from your product, your vulnerability handling obligations apply to the component that is actually in your stack. NES is precisely suited to this scenario: it keeps your obligations met while your engineering team completes the migration properly.

What about products placed on the market before December 2027?

Products placed on the market before 11 December 2027 are only subject to full CRA conformity requirements if they undergo a “substantial modification” after that date. However — and this is important — the Article 14 reporting obligations apply to all products made available on the EU market, including those already on the market before December 2027. If you have a product in the field with an EOL component and a CVE is actively exploited after September 2026, you must report it.

What are the consequences of non-compliance?

Financial penalties can reach €15 million or 2.5% of global annual turnover, whichever is higher. Beyond fines, market surveillance authorities can require products to be withdrawn from the EU market entirely. For software vendors whose EU customer base represents a significant revenue stream, this is an existential risk. The reputational damage of a public non-compliance finding — particularly one involving an unpatched, known CVE — compounds the financial exposure.

‍

The Bottom Line

The EU Cyber Resilience Act has entered into force. Its reporting obligations begin in September 2026. Its full product conformity requirements apply from December 2027. The regulation makes EOL software in your product stack a legal liability: you own the vulnerability handling obligations for every component you ship, regardless of whether that component has an upstream maintainer.

If your products shipped into the EU contain EOL open source dependencies — and nearly all enterprise stacks do — the question is not whether this is a risk. It is. The question is what to do about it before the September 2026 reporting deadline arrives.

HeroDevs Never-Ending Support is one of the most cost-effective ways to close that gap: Through restoring active vendor support for EOL components, maintaining your EOL software against vulnerability, and ultimately ensuring you are in full compliance with the relevant Articles of the CRA. This gives compliance teams a defensible audit trail to show regulators.

Start by understanding what is in your stack. The HeroDevs End of Life Dataset is a free resource that tracks 12 million+ package versions and identifies which EOL frameworks have known, unpatched CVEs — and what NES support is available for them.