Choosing your CRA support period

Almost every other date in the Cyber Resilience Act is given to you. The support period is the one you set, which makes it the only place in the regulation where a marketing decision silently becomes a legal one.

What Article 13(8) actually requires

The obligation comes in three layers. First, what the period is for:

Manufacturers shall ensure, when placing a product with digital elements on the market, and for the support period, that vulnerabilities of that product, including its components, are handled effectively and in accordance with the essential cybersecurity requirements set out in Part II of Annex I.

Second, the test for setting it: the manufacturer shall determine the support period “so that it reflects the length of time during which the product is expected to be in use”.

Third, the floor:

… the support period shall be at least five years. Where the product with digital elements is expected to be in use for less than five years, the support period shall correspond to the expected use time.

Two things follow that are easy to miss. The five years is a floor, not a default — if your product is expected to be in use for twelve years, five years is not compliant, because the period must reflect expected use. And the short-product exception is not an escape hatch: it requires the expected use time to genuinely be shorter, and it then sets the period to that time rather than to anything you choose.

The defined term itself, in Article 3, is narrow and worth noting: the support period is “the period during which a manufacturer is required to ensure that vulnerabilities of a product with digital elements are handled effectively and in accordance with the essential cybersecurity requirements set out in Part II of Annex I”. It is a vulnerability-handling period, not a general warranty, not a feature-update commitment, and not a customer-support commitment.

The factors, and which are mandatory

Article 13(8) gives two sets of considerations, and the grammar distinguishes them. The first set is introduced by “taking into account, in particular”. The second by “manufacturers may also take into account”.

Article 13(8) closes with a proportionality instruction: the matters to be taken into account “shall be considered in a manner that ensures proportionality”. And the Commission is empowered, taking ADCO recommendations into account, to adopt delegated acts specifying minimum support periods for specific product categories. No such delegated act has been adopted at the time of writing, so the floor is five years across the board for now — but this is the provision to watch if you sell into a category where a longer minimum would be plausible.

The six duties your number extends

This is the section to read before choosing. Each of these says “or the support period, whichever is longer”, or is expressly attached to the support period.

Work an example. A fifteen-year support period on a 2028 product means: vulnerability handling until 2043; your technical file and declaration retained until 2043; your user information available until 2043; and a security update shipped in the final month of support available until 2053. That last date is twenty-five years after launch, and it follows from one number typed into a form.

Our guide to the three ten-year retention clocks goes through the mechanics of those duties in detail. The point here is only that they are downstream of this choice.

The trade-off, stated plainly

A generous support period is good for customers, good for tenders and good for marketing. It also extends six obligations, one of them by ten years beyond its own end. A short support period is cheap to operate and has to survive the “reasonable user expectations” test in front of a market surveillance authority.

The honest position is this: the regulation does not let you choose the number you like. It lets you choose the number you can justify. The expected-use test is objective in form, and there is no version of it in which a product plainly used for a decade gets a five-year period because five years was convenient.

When your components decide for you

Article 13(8) lets you take into account “the support periods of integrated components that provide core functions and are sourced from third parties”. In modern software this is not a marginal consideration; it is frequently the binding one.

If your product is built on a platform, runtime or operating system with a published end-of-life, then after that date you can still be obliged to handle vulnerabilities in it — because Article 13(8) covers vulnerabilities “including its components”, without asking who wrote them. You would be maintaining a dependency its own authors have abandoned.

Two practical consequences:

• Check the end-of-life dates of your core dependencies before you set the number, not after. A support period that outlives your runtime's upstream support is a commitment to do that work yourself.
• Write the dependency dates into your justification. They are the strongest evidence you have, and they are the kind of concrete, checkable fact that makes a justification credible.

Where the end date has to appear

Article 13(19) is specific, and it catches people who have determined a period but never told anyone:

Manufacturers shall ensure that the end date of the support period referred to in paragraph 8, including at least the month and the year, is clearly and understandably specified at the time of purchase in an easily accessible manner and, where applicable, on the product with digital elements, its packaging or by digital means.

Three elements: month and year at minimum, at the time of purchase, and easily accessible. An end date buried in a datasheet linked from a support page is not specified at the time of purchase. On a web checkout, it belongs where the price is.

The same paragraph adds a second duty: where technically feasible in light of the nature of the product, the manufacturer shall display a notification to users informing them that their product has reached the end of its support period.

Separately, the support period is one of the items that must appear in the information and instructions for users under Annex II. And Article 30(6) empowers the Commission to adopt implementing acts on labels and pictograms relating to, among other things, support periods — so the presentation of this particular fact may become more prescribed than it is today.

Writing the justification

The regulation does not require a separate support-period justification document. It requires you to determine the period taking specified factors into account, which in practice means you should be able to show that you did. The efficient form is a short, dated note that becomes part of the technical documentation:

1. The period, and the end date as it will be published — month and year.
2. Expected use time, and why. Replacement cycles, contract lengths, what your own installed base actually shows.
3. Reasonable user expectations, with evidence: comparable products, and what you yourself have told customers.
4. Nature and intended purpose, and why it points where it does.
5. Relevant Union law, if any applies to your category's lifetime.
6. Dependency end-of-life dates for components providing core functions.
7. The conclusion, expressly stating that the period is at least five years, or that expected use is shorter and why.

A page is enough. What makes it work is dates and named sources rather than adjectives.

What happens when it ends

Three things, and only the first is an ending:

• Annex I Part II stops applying to that product. You are no longer obliged to handle its vulnerabilities.
• The end-of-support notification duty arrives — Article 13(19), where technically feasible.
• Two clocks keep running. Every security update you issued during the period stays available for at least ten years from its own issue date, and your technical documentation and declaration of conformity stay retained for at least ten years from placing on the market. Ending support does not end retention.