What the CRA support period means: choosing it, declaring it, and what it commits you to

Every product with digital elements under the Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) has a support period: a date until which the manufacturer handles the product's vulnerabilities. You choose it, you declare it, and you are held to it. This guide explains how to choose it and what it commits you to. It is a documentation aid, not legal advice.

What it is

The CRA defines the support period as "the period during which a manufacturer is required to ensure that vulnerabilities of a product with digital elements are handled effectively" (Article 3(20)).

Article 13(8) sets the duty: when placing the product on the market, and for the support period, the manufacturer ensures that vulnerabilities of the product, including its components, are handled effectively and in line with the essential requirements in Annex I, Part II. In practice that is the whole vulnerability-handling list: keeping an SBOM, fixing without delay, testing, publishing advisories for fixed vulnerabilities, running a coordinated disclosure policy and a contact point, distributing updates securely, and shipping security updates free of charge with advisory messages.

How long it must be

Article 13(8) answers in two parts.

The length reflects how long the product is expected to be in use. The manufacturer determines it taking into account, in particular, reasonable user expectations and the nature of the product, including its intended purpose, as well as relevant Union law that sets the lifetime of products. It may also take into account the support periods of products offering similar functionality placed on the market by other manufacturers, the availability of the operating environment, the support periods of integrated components that provide core functions and are sourced from third parties, and relevant guidance.

There is a 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."

So five years is the minimum for anything expected to last five years or more, and a product expected to last ten should not stop at five.

Above five years, the period need not match the whole use time. Article 13(8) asks that the factors be weighed "in a manner that ensures proportionality". The Commission services read that in their FAQ (version 1.4, entry 4.5.1; not binding, and not the Commission's official position): "manufacturers are not expected to simply set support periods that correspond to the expected use time", unless that time is less than five years. Our reading (argument): the expected use time is where you start, and the other factors, such as what comparable products offer and how long your core components are supported, can set the period below it, but not below five years. A device expected to last fifteen years does not automatically owe fifteen years of updates; it owes a period you can justify from the factors, and for a long-lived product that is usually more than five. Below five years there is no weighing: the period is the expected use time.

Whichever way the factors point, the reasoning goes in the technical documentation (Annex VII point 4, and FAQ 4.5.1 says the same).

Choosing yours

A defensible support period is one you can explain from those factors. For a connected device, the questions are:

1. How long will customers use it? Look at your own field data: how long do units stay online? A building sensor with a ten-year battery and a phone accessory have different answers.
2. What would a buyer reasonably expect? A smart thermostat bought for a house is expected to last much longer than a promotional gadget.
3. What do comparable products offer? If competitors state seven years, five needs a reason.
4. How long will your foundations be supported? The RTOS or Linux release, the chip vendor's SDK and radio stack, the TLS library. If the vendor's security fixes for your SoC end in 2030, a support period to 2033 means you carry those fixes yourself for three years.
5. Can you deliver it? A support period is a promise with a cost: an engineer who triages reports, a build that still compiles, a signing key that is still safe. Cost is not one of the factors Article 13(8) lists, so budget for the period the other factors point to rather than shortening it to fit (argument).

Write the reasoning down, including why the period is shorter than the expected use time if it is. Annex VII point 4 asks the technical documentation to contain the information taken into account to determine the support period.

Where you must show it

At the time of purchase. Article 13(19): the end date of the support period, "including at least the month and the year", must be "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". Practical places: the product page of your shop, the packaging, the datasheet, and the device's settings screen or companion app.

In the user information. Annex II asks for the type of technical security support offered and the end date of the support period during which users can expect vulnerabilities to be handled and to receive security updates.

In the technical documentation, with the reasoning, as above.

Write it as a date, not a duration. "Security updates until March 2032" is unambiguous; "five years from purchase" is not, because purchases happen on different days.

What it commits you to

During the period: effective vulnerability handling under Annex I, Part II, for the product and its components (Article 13(8)). That includes security updates provided without delay and free of charge, accompanied by advisory messages (Part II(8)), unless you and a business customer agreed otherwise for a tailor-made product, and, where technically feasible, provided separately from functionality updates (Part II(2)).

Reporting runs regardless of the support period. Article 14 reporting has applied since 11 September 2026 (Article 71(2), EUR-Lex text checked 8 October 2026) and its duties attach to the manufacturer when it becomes aware of an actively exploited vulnerability or a severe incident. Our reading (argument): the reporting text does not stop at the end of the support period. Plan for the possibility of a report about an out-of-support product.

After an update ships: Article 13(9) says each security update made available during the support period "remains available after it has been issued for a minimum of 10 years or for the remainder of the support period, whichever is longer". Your update server and its archive outlive the support period.

When the support period ends

Article 13(19) has a second rule: where technically feasible, manufacturers "shall display a notification to users informing them that their product with digital elements has reached the end of its support period". A notice ahead of the date as well, and a final advisory listing known unfixed issues, helps users plan (argument: good practice beyond that rule). Our guide "Choosing and changing your support period" covers the notice in detail. Annex II also asks the user information to explain how the product can be securely decommissioned, including how user data can be securely removed.

A worked example (argument)

A battery-powered environmental sensor, Zephyr on an nRF52840, expected service life six to seven years. Comparable sensors advertise five years. The chip vendor's SDK has a published support policy to at least 2032. A defensible choice: support period to October 2032 for units first placed on the market in October 2026, about six years, with the vendor commitment noted and a plan to carry RTOS fixes if the vendor stops earlier. Shown as "Security updates until October 2032" on the box, the product page and the app's About screen.

What is settled and what is not

Settled (evidence): the definition, the five-year floor, the factors, the month-and-year display rule, and the ten-year availability rule for updates, all in the articles cited.

Not settled: how far below the expected use time a period above five years may be set. The FAQ says it need not match the use time but gives no measure, and it is the Commission services' reading, not binding.

Also not settled: the Commission published guidance on applying the CRA, including a section on support periods, on 27 July 2026 (C(2026) 5252), and says it applies only once formally adopted, which had not happened by 8 October 2026. Commission guidance is one of the factors Article 13(8) names; we update this guide when it is adopted.