EOL Open Source Is Now a CRA Compliance Problem. Most Teams Don't Know Which Components They're Exposed On.

Most compliance conversations about the EU Cyber Resilience Act focus on what the regulation says. This one focuses on what it means for the specific category of software risk that enterprise teams are worst at managing: end-of-life open source components that are still running in production.

The CRA entered into force on December 10, 2024. Manufacturer reporting obligations — the requirement to notify ENISA and member state CSIRTs of actively exploited vulnerabilities within 24 hours — begin September 11, 2026. Full enforcement of the product security, SBOM, and vulnerability management requirements applies from December 11, 2027. Both deadlines create specific, documentable compliance friction for organizations running EOL open source. The nature of that friction is different at each date.

‍

The September 2026 obligation and why EOL software makes it harder

The September 11, 2026 deadline is Article 14 of the CRA: if you become aware of an actively exploited vulnerability in a product you have placed on the EU market, you have 24 hours to file an early warning notification, 72 hours for a main notification, and 14 days for a final report once a corrective or mitigating measure is available.

This is a process requirement. You need to know what is in your product, know when a vulnerability is being actively exploited, and have a remediation path ready to document.

EOL open source components break this process at the third step. When a component is past end of life, there is no upstream patch coming. If a high-severity CVE is discovered and actively exploited in an EOL framework, your organization is responsible for remediation — through migration, through extended support coverage, or through documented risk treatment. "We are waiting for an upstream fix" is not a compliant response when the upstream project has been inactive for years.

‍

The December 2027 obligations and the SBOM problem

The full CRA obligations applying from December 2027 include manufacturer requirements to maintain a current, machine-readable SBOM identifying all open source and third-party components, to handle vulnerabilities in those components throughout the product support period, and to have a continuous vulnerability disclosure process covering all components in the product.

For maintained open source, this process largely runs through the upstream project. For EOL components, it does not exist at the upstream level. The organization must provide an alternative mechanism for detection, advisory, and remediation — or document the gap.

A complete SBOM is not the compliance problem for most teams. It is the document that makes the compliance problem visible. When a current SBOM identifies an EOL component with a list of known, unaddressed CVEs and no active maintainer, that entry is a documented gap against the December 2027 requirements.

‍

The scale of the problem in the average enterprise codebase

The 2026 Black Duck Open Source Security and Risk Analysis report, based on analysis of 947 commercial codebases across 17 industries, provides the clearest picture of what these requirements mean in practice:

Open source appears in 98% of codebases. The CRA applies to any product incorporating open source — which is nearly all commercial and enterprise software. 78% of codebases contain high-risk vulnerabilities, the majority in components that have not received a patch in the previous assessment period. 93% of codebases contain components with no development activity in the previous two years — components with no releases, no advisories, and no active maintenance. Vulnerabilities per codebase increased 107% year over year, driven in part by AI-assisted development introducing dependencies faster than governance processes can track them.

These numbers describe the default state of enterprise software, not edge cases.

‍

EOL dates clustering around the CRA reporting deadline

Several widely-used open source components reach EOL in the months surrounding the September 2026 reporting deadline:

Node.js v20 reached EOL on April 30, 2026. Organizations running v20 without coverage enter the September window with a component that will have been unpatched for over four months.

Angular v19 reaches EOL on May 19, 2026 — four months before the reporting obligation begins.

Spring Boot 3.5 and Spring Framework 6.2 reach EOL on June 30, 2026 — ten weeks before September 11. Organizations entering July without Spring coverage are managing CRA-covered products with components that just became unpatched.

Note: Spring Boot 3.3 and Spring Framework 6.1 reached EOL in June 2025. If your codebase includes those versions, the gap is not upcoming. It is current.

‍

What a defensible compliance position looks like

Completing all migrations before September 2026 or December 2027 is not realistic for most enterprise software portfolios. That is not what the regulation requires. What it requires is a documented, demonstrable process for managing the security risks of the components you are shipping.

For EOL components specifically, a defensible position requires three things: a current SBOM that identifies EOL components, their versions, and their known CVE exposure; a documented coverage mechanism for vulnerability monitoring and remediation that does not rely on the upstream project; and a continuous vulnerability disclosure process that covers EOL components.

NES provides all three for covered open source components — CVE monitoring, security patch backporting, and security advisory issuance for EOL versions. HeroDevs EOLDS is a free dependency scanner that identifies EOL components across your full dependency graph, including transitive dependencies not visible to standard manifest-based SCA tools. For most teams, a complete dependency scan is the right starting point — you cannot document coverage for components you have not inventoried.

‍

FAQ

What CRA deadlines apply to software manufacturers? September 11, 2026 is when reporting obligations for actively exploited vulnerabilities begin. December 11, 2027 is when full product security, SBOM, and vulnerability management requirements apply.

Does the CRA apply to open source software? The CRA applies to organizations placing software products on the EU market. Products incorporating open source components are subject to CRA requirements for those components. Organizations must demonstrate how they manage security risks in their open source dependencies, including EOL ones.

How does EOL open source create a specific CRA compliance gap? EOL components no longer receive security patches from upstream maintainers. The CRA requires a process for identifying and addressing vulnerabilities and a continuous vulnerability disclosure mechanism. For EOL components, neither function exists upstream. The organization must provide an alternative or document the gap.

Does NES satisfy CRA requirements? NES provides continued CVE monitoring, security advisory issuance, and security patch backporting for covered EOL open source versions — the functions the CRA requires and that EOL upstream projects no longer provide.

Do US-based companies need to comply with CRA? CRA applies to products placed on the EU market regardless of manufacturer location. US companies selling software into the EU, including SaaS products accessed by EU customers, are subject to CRA requirements.

What are the consequences of CRA non-compliance? Consequences include market withdrawal orders, financial penalties, and reputational damage. Specific enforcement approaches vary by member state. The regulatory intent is that non-compliance should be more costly than compliance.