CRA support period, EOL & update duty

The costliest CRA question does not arise at market launch but in the years that follow: 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 that would have halved the 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 product lifetime — not a blanket expiry date.

As guidance, the CRA context typically names at least five years. The reading matters: this is guidance, not a rigid deadline. For products that typically stay in the field longer — industrial controls, building technology, energy and grid infrastructure — a considerably longer period may be appropriate. Conversely, a genuinely shorter expected lifetime is no free pass: the five years are the reference point that is hard to argue below. 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:

• Timely, free security updates. Security updates must generally be provided promptly and must not be tied to paid feature upgrades. Security and feature updates should remain separable so a customer can 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 security incidents must be reported — in a clear cascade.

The reporting cascade is frequently confused, so here it is at a glance:

Reporting goes via the ENISA Single Reporting Platform (SRP) to the competent CSIRT and ENISA. The reporting duties apply from 11 Sep 2026 — the CRA's first hard manufacturer obligation, well before full application in 2027. Anyone without a working vulnerability process by then cannot meet the 14-day or 1-month deadline.

Determining and communicating the support period

The support period is not a gut feeling but a reasoned decision. 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), which must be kept for ten years after placing on the market.

Outward-facing: the support period must be clearly communicated to the user — as an end date or a duration, recognisable before purchase. A product with no communicated support horizon cannot be lawfully placed on the market. 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: the end date is a project, not an event

At end of life (EOL) the update duty ceases — but the end must be planned and communicated, not occur silently. 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 as long as the support period lasts, not just as long as the team works on the product.

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 — machine-readable, CycloneDX ≥ 1.6 or SPDX ≥ 3.0.1, at least top-level, part of the technical documentation) 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, not in the year they occur. 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: 24-h early warning, 72-h notification, 14-day final report after the fix is available. Anyone who only thinks this through in 2037 has accumulated nine 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 %.

What Blackfort does

Blackfort Technology UG (haftungsbeschränkt) helps manufacturers derive the support period defensibly, justify it in the technical documentation, and underpin it with a viable EOL and update process — from SBOM-based component analysis and the design of the OTA update infrastructure to end-of-life communication. The focus is on making later compliance gaps visible today instead of discovering them on the EOL date.

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 and update architecture: get in touch.