Ask ten product managers how long the CRA support period is and most will say five years. That number is in the regulation, but only as a minimum. The rule itself is different: the support period must reflect how long the product is expected to be in use (Article 13(8)).
For a smart plug that people replace after four years, five years is enough. For an industrial gateway that runs in a control cabinet for twelve years, it is not.
The rule in one paragraph
The manufacturer sets the support period so that it reflects the expected time in use. It must be at least five years. Only if the product is expected to be in use for less than five years may it be shorter, and then it must match that expected time. During the support period, the manufacturer handles vulnerabilities in line with Annex I Part II.
What the decision must be based on
Article 13(8) names three things you must take into account:
- Reasonable user expectations. What would a buyer of this kind of product expect?
- The nature of the product, including its intended purpose. A boiler controller and a phone accessory are not used for the same time.
- Union law that sets the lifetime of products, where such law exists for your product type.
You may also look at the support periods of similar products on the market, the availability of the operating environment, the support periods of integrated third-party components that provide core functions, and relevant guidance from ADCO (the cooperation group of market surveillance authorities) and the Commission.
Write the reasoning down. The information used to set the support period is part of the technical documentation (Annex VII point 4), and an authority can ask for it.
Three examples
| Product | Realistic time in use | Reasonable support period |
|---|---|---|
| Consumer smart plug | about 4 years | 5 years (the minimum applies) |
| Connected thermostat | 8 to 10 years | about 8 to 10 years |
| Industrial gateway in a plant | 10 to 15 years | about 10 to 15 years, often backed by service contracts |
Your field data is the best evidence: return rates, service records, how long earlier models stayed connected to your backend. "Our competitors say five years" is weak evidence if your devices stay online for ten.
What the support period commits you to
- Vulnerability handling in line with Annex I Part II for the whole period: identify components, fix without delay, test, publish advisories, run a disclosure policy.
- Free security updates, separate from feature updates where technically feasible, unless otherwise agreed with a business user for a tailor-made product (Annex I Part II points 2 and 8).
- Availability of each update: every security update stays available for at least ten years after it was issued, or for the rest of the support period if that is longer (Article 13(9)).
If you release substantially modified new software versions, you may limit fixes to the latest version, but only if users of older versions can move to it free of charge and without buying new hardware or software (Article 13(10)).
The buyer must see the date
The end of the support period, at least month and year, must be clearly stated at the time of purchase and, where applicable, on the product, its packaging or by digital means (Article 13(19)). The user information must state the type of support and its end date (Annex II point 7). Where technically feasible, the manufacturer must notify users that support has ended (Article 13(19)).
In practice this means three places: the product page or box, the user information, and the device or app itself near the end.
Where it usually breaks: your components stop first
The weak point is rarely your own code. It is the parts underneath it. A chip vendor's board support package, a kernel branch or a commercial RTOS release often stops receiving fixes years before your device leaves service. If your support period runs to 2036 and your operating system's support ends in 2030, you have a six-year gap that you have already promised to cover.
Map it before you commit:
| Core component | Supplier support ends | Gap | Plan |
|---|---|---|---|
| SoC board support package | 2030 | 6 years | Extended support contract or back-port fixes in-house |
| Wi-Fi module firmware | 2031 | 5 years | Contract clause with the module supplier |
| TLS library | maintained upstream | none expected | Track releases, update regularly |
Each line in that table is either a contract, an engineering budget or a redesign. All three are cheaper to decide now than after a vulnerability appears in year seven.
A short checklist
- Decide the support period per product family, with the evidence for the expected time in use.
- List core third-party components and their support end dates, and close every gap with a plan.
- Record the decision and reasoning in the technical documentation.
- Show the end date, month and year, wherever the product is sold, and in the user information.
- Plan the end-of-support notice in the device, the app or by email.
- Review the decision when the product changes or when field data shows longer use.
This article explains Regulation (EU) 2024/2847 in plain words. It is not legal advice.