CRA support period, EOL & update duty

A costly CRA question arises in the years after market launch: how long must a product receive free security updates - and what happens when that time ends? The Cyber Resilience Act (Regulation (EU) 2024/2847) thereby shifts a substantial share of cost out of development and into the lifecycle. Anyone who only runs the numbers shortly before full application on 11 Dec 2027 has already missed the choice with the biggest influence on effort: choosing components and update architecture at the start of the project.

What the support period is - and what it is not

The CRA requires the manufacturer to handle vulnerabilities effectively and provide security updates over a defined support period. The concept behind it is decisive: this period is meant to reflect the expected use time of the product (Article 13(8)).

Article 13(8) requires at least five years; the period may only be shorter where the product is expected to be in use for less than five years. For products that stay in the field longer - industrial controls, building technology, energy and grid infrastructure - a considerably longer period may be appropriate. A shorter expected use time must be justified: the information taken into account belongs in the technical documentation (Article 13(8), Annex VII, point 4). This article frames the regulatory position schematically and is not legal advice.

What applies during the support period

Within the promised period, the manufacturer's duty (Annex I of the regulation) condenses into a few concrete points:

• Security updates without delay and free of charge. Security updates must be disseminated without delay and free of charge, unless otherwise agreed with a business user for a tailor-made product, and, where technically feasible, separately from functionality updates (Annex I, Part II, points 2 and 8). A customer can then obtain a security fix without buying a functional step.
• Effective vulnerability handling with a CVD policy. Throughout the period you need a documented coordinated vulnerability disclosure process, including a reporting channel and a handling path.
• Update capability "by design". Even field-distributed devices without permanent connectivity must be updatable - this concerns OTA mechanisms, signed packages, and how an update reaches a device that is only occasionally online.
• Reporting duties under Art. 14. Actively exploited vulnerabilities and severe incidents having an impact on the security of the product must be reported in stages.

The deadlines at a glance:

Reporting goes via the single reporting platform (Article 16) simultaneously to the CSIRT designated as coordinator and to ENISA. The reporting duties have applied since 11 Sep 2026, the CRA's first hard manufacturer obligation, well before full application in 2027. Without a working vulnerability handling process these deadlines are hard to meet reliably.

Determining and communicating the support period

The support period is a reasoned decision by the manufacturer. In practice it is derived from several factors: the typical service life in the target sector, usage patterns of comparable products, contract terms, and how long the built-in components themselves are maintained. This derivation belongs in the technical documentation (Annex VII, point 4), which must be kept for at least ten years after placing on the market or for the support period, whichever is longer.

Outward-facing: the end date of the support period must be indicated clearly and accessibly at the time of purchase, at least by month and year, where applicable on the product, its packaging or by digital means (Article 13(19)). A mere duration does not meet this. The promise binds: whoever prints "security updates until 12/2031" on the box is committed until then, even if the product is commercially superseded long before.

EOL management: planning the end date

At end of life (EOL) the duty to handle vulnerabilities and provide new security updates ends. Other duties continue: security updates already made available remain available for at least ten years after issue (Article 13(9)), the technical documentation must still be retained (paragraph 13), and where technically feasible users must be notified that the end of the support period has been reached (paragraph 19). The reporting obligations under Article 14 do not end with the support period either. Clean EOL management includes:

• Early announcement to customers and distributors, with a concrete date and a recommended action (migration, successor product).
• A final defined update window, so no device enters the update-free phase carrying a known but unpatched vulnerability.
• Documented residual risks for the post-EOL period, so operators can make their own risk decision.
• A working update infrastructure until the last day - OTA backend, signing keys and build environment must stay operational until the end of the support period, even if the team has long since moved on to other products.

Why this is strategically expensive: the SBOM coupling

The update duty turns every third-party component into a planning risk. The Software Bill of Materials (SBOM - in a commonly used machine-readable format, covering at least the top-level dependencies, part of the technical documentation; BSI TR-03183-2 specifies CycloneDX ≥ 1.6 or SPDX ≥ 3.0.1) lists every library whose own upstream support eventually ends. If that upstream support runs out before the end of the promised period, a gap opens: the manufacturer must replace the component in advance or maintain it in-house. Support period, SBOM and EOL monitoring are inseparable - plan one and you must plan the others.

A worked example

A manufacturer launches a networked control unit for building automation in 2027. Typical field life: around ten years. It therefore sets the support period schematically to ten years, to 12/2037, and states this on the datasheet.

Now the chain of consequences: the device uses an embedded Linux whose LTS kernel maintenance ends in 2032, and a TLS library maintained to 2030. Both end before 2037. In planning terms: for the TLS library, from 2030 you need either a version jump or in-house backporting of fixes; for the operating system, the same from 2032. These transitions belong in the roadmap and budget today. In parallel, the OTA backend must be designed to still deliver signed updates in 2036 to devices that only come online weekly. And for an actively exploited field vulnerability, the Art. 14 path applies: early warning without undue delay and at the latest after 24 hours, notification at the latest after 72 hours, final report no later than 14 days after the fix is available. Anyone who only thinks this through in 2037 has accumulated ten years of obligation without provision.

Contract and product planning

The support period belongs in several documents at once: in the product roadmap (as a component-refresh plan), in supplier contracts (assurance of security fixes from upstream vendors over a matching duration), and in your own customer terms (a clearly bounded support commitment). The stakes on the penalty side are not small: breaching the Annex I requirements or the reporting duties can be sanctioned with up to EUR 15 million or 2.5 % of worldwide annual turnover (whichever is higher), other breaches with up to EUR 10 million / 2 %, and false statements to authorities with up to EUR 5 million / 1 %. Article 64 is not among the provisions that apply early and applies from 11 December 2027 (Article 71(2)); the German implementing act (Bundestag printed paper 21/6134), which is to set the authority and fining procedure, had been neither adopted nor promulgated as of 9 October 2026.

What Blackfort does

Blackfort Technology UG (haftungsbeschränkt) helps manufacturers derive the support period and justify it in the technical documentation. To do so, we build the SBOM chain from your build with you, recording the third-party components per release and continuously matching them against vulnerability databases. This shows early which components will need to be replaced or maintained in-house for the promised period.

A good starting point is the applicability check: it indicates which CRA duties are likely relevant for your product. For depth, the Cyber Resilience Act overview explains the deadlines and roles; smaller manufacturers should look at the SME page and the relevant sectors. For a concrete conversation on the support period: get in touch.