EU Cyber Resilience Act and End-of-Life Open Source

The short answer

The EU Cyber Resilience Act, Regulation (EU) 2024/2847, does not prohibit a product from containing an end-of-life open source component. What it does is make the manufacturer of a product with digital elements responsible for handling the vulnerabilities of that product, "including its components", for a support period of at least five years. If the upstream project has stopped issuing fixes for the version you ship, those fixes still have to come from somewhere: your own engineers, a support provider, or an upgrade.

The obligation to report actively exploited vulnerabilities and severe incidents under Article 14 has applied since 11 September 2026, and Article 69(3) extends it to products placed on the market before the Act fully applies. The rest of the regulation applies from 11 December 2027. This article is general information about the regulation text, not legal advice.

The CRA timeline

Article 69(2) adds a transitional rule. A product placed on the market before 11 December 2027 is subject to the regulation only if it is substantially modified from that date. Article 69(3) then makes an exception for reporting: the Article 14 obligations apply to every in-scope product, whenever it was placed on the market. A device or software product you shipped in 2025 with an old ZooKeeper, Spring or OpenSSL inside is already covered by the reporting duty.

What the reporting duty asks for today

Under Article 14(1) and (2), a manufacturer that becomes aware of an actively exploited vulnerability in its product notifies the CSIRT designated as coordinator and ENISA through the single reporting platform. There are three stages:

1. An early warning within 24 hours of becoming aware.
2. A vulnerability notification within 72 hours, with general information about the product, the nature of the exploit, and the corrective or mitigating measures taken and available to users.
3. A final report no later than 14 days after a corrective or mitigating measure is available, describing the vulnerability, its severity and impact, and the security update or other corrective measure.

Article 14(8) also requires the manufacturer to inform impacted users of the vulnerability and of the mitigations they can apply, "where appropriate in a structured, machine-readable format". The vulnerability does not have to be in your own code. If it is in a component you embed, it is in your product.

The end-of-life problem shows up in the third stage. The final report is due 14 days after a fix or mitigation is available, and the user notice is expected to say what users can do. When upstream has stopped publishing releases for the line you embed, nobody produces that fix for you unless you have arranged it in advance.

Five articles that apply to an end-of-life component

Article 13(5): due diligence on third-party components

Manufacturers "shall exercise due diligence when integrating components sourced from third parties so that those components do not compromise the cybersecurity of the product", and the text says this includes free and open source components that were not made available in the course of a commercial activity. Choosing a component whose upstream support has ended, or keeping one after it ends, is a decision you will be asked to justify.

Article 13(6): report and remediate component vulnerabilities

When a manufacturer identifies a vulnerability in a component, including an open source one, it reports it to the person or entity maintaining that component and remediates it under the vulnerability handling requirements of Annex I Part II. If the manufacturer has written a fix, it shares the code or documentation with the maintainer where appropriate. For an end-of-life line the remediation is still yours, even if the upstream project will not cut a release.

Article 13(8): the support period

The manufacturer must handle vulnerabilities in the product, including its components, effectively for the support period. The support period reflects how long the product is expected to be in use and "shall be at least five years", unless the product is expected to be in use for less time. When setting it, the manufacturer may take into account "the support periods of integrated components that provide core functions and are sourced from third parties". That is an input to the decision, not an exemption. If you ship a product with a five-year support period and an embedded component whose upstream support ends in year two, you carry the component for the remaining three.

Annex I: no known exploitable vulnerabilities, and fixes without delay

Annex I Part I point (2)(a) requires products to be made available on the market "without known exploitable vulnerabilities", and point (2)(c) requires that vulnerabilities can be addressed through security updates. Part II point (2) requires manufacturers to "address and remediate vulnerabilities without delay, including by providing security updates", separately from functionality updates where technically feasible. Article 13(9) keeps each security update available for at least 10 years or the rest of the support period, whichever is longer.

Annex I Part II point (1): the SBOM

Manufacturers must identify and document the components in their products, "including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies". You do not have to publish it. Annex VII point 8 lists the SBOM in the technical documentation, to be handed to a market surveillance authority on a reasoned request, and Annex II point 9 covers telling users where to find it if you choose to share it. That request is where an end-of-life component becomes visible to a regulator. Our article on SBOMs and end-of-life components explains why the inventory finds the problem but cannot close it.

Where open-source software stewards fit

Article 3(14) defines an open-source software steward as a legal person, other than a manufacturer, that systematically supports on a sustained basis the development of specific free and open source products intended for commercial activities. Recital 19 says stewards include certain foundations, as well as entities that develop and publish free and open source software in a business context, including not-for-profit entities. Under Article 24, a steward must put in place and document a cybersecurity policy, cooperate with market surveillance authorities when they ask, and report actively exploited vulnerabilities to the extent it is involved in development. Article 64(10)(b) exempts stewards from administrative fines.

Two points follow for anyone shipping an end-of-life component. First, nothing in Article 24 requires a steward to keep supporting an old release line. A project can end a version under the CRA exactly as it did before. Second, the steward's obligations do not transfer the manufacturer's. The product, the support period and the duty to remediate stay with whoever places the product on the market. Free and open source software that is not supplied in the course of a commercial activity is outside the regulation entirely, so the community maintainers of the component you embed have no CRA duty to you.

What manufacturers with EOL components are doing

1. Find them. Generate the SBOM and compare every component against its upstream end-of-life date. Our end-of-life tracker lists dates for common runtimes and frameworks such as ZooKeeper, Spring Framework and Kafka.
2. Compare dates. Any component whose upstream support ends before your product's support period does needs a named source of security fixes for the gap.
3. Choose the source. Upgrade the component, backport fixes in-house, or contract a provider that ships patched builds for the line you use. Record the choice and the reasoning in the technical documentation, since Article 13(8) asks you to keep the information used to set the support period.
4. Prepare the reporting path. Know who will triage an actively exploited CVE in an embedded component within 24 hours, and where the fix will come from within the timelines in Article 14.
5. Answer scanner findings in a machine-readable way. A VEX statement records whether a product is affected by a given CVE in a format users' tools can process, which suits the user information duty in Article 14(8).

The penalties are set in Article 64(2): non-compliance with Annex I or with Articles 13 and 14 can bring administrative fines of up to EUR 15 000 000 or 2.5% of total worldwide annual turnover, whichever is higher.

Where OSSeva fits

OSSeva Patch ships signed, drop-in builds with security fixes backported to community end-of-life open source runtimes, so an embedded component keeps receiving fixes after upstream stops. OSSeva Assure adds architectural review, attestation letters and compliance documentation you can reference in your technical file and audits. The compliance library collects our framework guides, including DORA for EU financial entities.

Frequently asked questions

Does the CRA apply to products already on the market?

Only the Article 14 reporting obligations, which have applied since 11 September 2026. The other requirements apply to products placed on the market from 11 December 2027, and to older products only if they are substantially modified from that date.

Is shipping an end-of-life open source component a CRA violation?

Not in itself. The obligations are about outcomes: due diligence on components, no known exploitable vulnerabilities at placement, and effective vulnerability handling for the support period. An unsupported component makes those outcomes harder to show unless you have another source of fixes.

Can the support period be shorter than five years because a component goes end of life?

The component's support period is one factor a manufacturer may consider, but the minimum of five years still applies unless the product itself is expected to be in use for less than five years.

Do open source projects have to support old versions under the CRA?

No. Non-commercial free and open source software is out of scope, and the steward obligations in Article 24 concern policy, cooperation and reporting, not support for any particular release line.