The CRA support period: how long you must ship security updates

"How long do we actually have to support this?" is the question that, under the Cyber Resilience Act, sets your costs for years ahead. The answer is in Article 13 of Regulation (EU) 2024/2847, and it is surprisingly concrete. Let's break it down so you can both set the period and defend it.

What Article 13(8) says

The support period is set by the manufacturer — but not arbitrarily. Under Article 13(8) it must reflect the length of time during which the product is expected to be in use, taking into account in particular reasonable user expectations, the nature of the product and its intended purpose. And there is a hard floor: the support period shall be at least five years. If the product is genuinely expected to be in use for less than five years, the period corresponds to that shorter expected time.

In practice: for most software and devices, plan on five years as the baseline. A shorter period is possible only where it is genuinely justified by a shorter product lifetime — and you must be able to evidence that justification.

During the period: free security updates

The support period is not just a number on paper — it's a commitment. During it you must handle vulnerabilities and ship security updates, and the regulation is unambiguous on one point: security updates are provided free of charge. So you cannot charge extra for a security fix or tie it to a paid "support package". (You can charge for new features — this is about security fixes.) Exception: for a tailor-made product it can be agreed otherwise — Annex I, Part II, point 8 allows a different arrangement ("unless otherwise agreed … in relation to a tailor-made product"). This is relevant precisely for custom-development work.

After release: 10-year availability of updates (Article 13(9))

Here many people confuse two different numbers. On top of the support period itself, Article 13(9) applies: every security update you made available during the support period must remain available for at least 10 years after it was issued — or until the end of the support period, whichever is longer. In other words: it is not enough to ship an update and pull it a year later. Users (and the surveillance authority) must still be able to access it long afterwards.

Two numbers, two meanings:

1. Support period (min. 5 years) = how long you actively fix and ship new security updates.
2. Update availability (min. 10 years after release) = how long an already-issued fix must remain downloadable.

The reasoning belongs in the documentation

Because you set the period yourself, you must be able to say why it is that long. The information on which you determined the support period is part of the technical documentation — that is, what you provide to a market surveillance authority on request. In practice a few sentences suffice: what type of product it is, how long customers actually use it, which comparable products you rely on. It's not an essay, it's a defensible decision on paper. What the technical documentation contains is covered in the self-assessment and Annex VII article.

How to justify the period — examples

Since you set the length, it's worth knowing how to back it up. A few indicative cases:

1. An ordinary desktop or server application: five years as the baseline. A shorter period would need justifying by the product genuinely reaching end of life sooner — which for software is usually hard.
2. A long-lived device (an industrial sensor, a gateway): users expect years of operation, so the period should match that longer time, comfortably above five years.
3. A short-lifecycle product tied to a specific season or hardware that genuinely falls out of use sooner: the period can be shorter if you can evidence it with the expected use time.

In the documentation a few sentences suffice: what type of product it is, how long customers actually use it, and what you rely on (comparable products, the history of your own versions). What matters is that it's a reasoned decision, not a number pulled from the air.

Which versions this pulls in

A common mistake is to think only of the "latest version". The support period applies to the product that is in use — so while support runs, you must be able to respond to vulnerabilities in all versions still supported and in the field. If you ship versions 2.3, 2.4 and 2.5, a new vulnerability in a shared component may affect several of them. Without a component list per version you can't quickly say which is hit — which is exactly why an SBOM is versioned with every release.

What it means for a small company

The practical consequence is simple but far-reaching: a commitment that runs for a good while. The support period means that for a full five (or more) years you must be able to track and respond to vulnerabilities in your components — for every version still in support. Without a component list (SBOM) and ongoing monitoring, this can't be done by hand; that's why it pays to have those processes in place from the start. How to build an SBOM is shown in the 10-minute guide.

Key point

The support period is a decision with a long shadow under the CRA — it sets costs for years ahead. Remember two numbers and don't mix them up. Art. 13(8): you set the support period based on the expected use time, but at least five years (shorter only for a genuinely shorter lifespan you can substantiate). Art. 13(9): every security update you issue must remain available for at least 10 years afterwards (or until the end of the support period, whichever is longer). During the period you provide security updates free of charge (for a tailor-made product it can be agreed otherwise — Annex I, Part II, point 8). The reasoning for the length belongs in the technical documentation — a few sentences, not an essay. And note: support isn't only about the latest version, but all versions still in the field and supported — which is why the SBOM is versioned with each release, so you can quickly say which shipped version is vulnerable.

How CRAguard helps

CRAguard keeps each product's support period and versions, and daily checks their components against vulnerability databases — so throughout the support period you know what to fix, without digging by hand. When a new security problem appears, you get a clear verdict and the input for your response. Find out whether the CRA applies to you, or join the waitlist.

This article is informational and not legal advice. It is based on Regulation (EU) 2024/2847 (Article 13, in particular paragraphs 8 and 9) and the European Commission's guidance of 27 July 2026.