How long you must support a product under the Cyber Resilience Act
The Cyber Resilience Act makes you set a support period, print it, and fix vulnerabilities until it ends. How long it must be, and how to choose it.
· 3 min read · By DASKALOS APPS
- updates
- product life cycle
- what to do first
Under the Cyber Resilience Act, every product has a support period: the time during which you fix its vulnerabilities and ship the fixes to the people using it. The Act sets a floor, leaves the choice to you, and makes you say the date out loud. This is how long it has to be, what "support" means, and how to choose a period you can keep.
You set it, within a floor
The manufacturer determines the support period so that it reflects the expected time in use; it must be at least five years unless the product is expected to be used for a shorter time.[Art. 13(8), third subparagraph]The floor is not a target. The test is how long people actually use the product, so a device that sits in a building for a decade needs a longer period than the floor, and a product genuinely used for less may have a shorter one if you can show why.
You have to say it
The end date of the support period must be stated clearly to users at the time of purchase and in the information accompanying the product.[Art. 13(19); Annex II, point 7]That means the date is on the product page, in the box or the download, and in the information the buyer gets — before they pay, not after. A support period nobody can find does not meet the duty, however long it is.
What "support" means
Support is not a helpdesk. It is three things the Act spells out, and a fourth that runs alongside them.
Fixing, and shipping the fix. Manufacturers must address and remediate vulnerabilities without delay, including by providing security updates, and where technically feasible those updates must be provided separately from feature updates. Updates must reach users through a secure distribution mechanism and, where that applies to security updates, automatically. Once an update exists it must be sent out without delay, with a message telling users what it covers and what they may need to do, and free of charge — unless the manufacturer and a business customer have agreed otherwise for a product built specifically for that customer.[Annex I, Part II, points 2, 7, 8]
Telling people what you fixed. Once a security update has been made available, the manufacturer must share and publish information about the vulnerabilities it fixes: what they are, which products are affected, what the impact and the severity are, and clear instructions for users to remedy them. Publication may be held back, in a case the manufacturer can justify and where the security risk of publishing outweighs the benefit, until users have had the chance to apply the patch. The duty starts when the fix is available, not when the vulnerability is found.[Annex I, Part II, point 4]
Keeping the fixes available. Security updates issued during the support period must remain available for at least ten years after issue or for the remainder of the support period, whichever is longer.[Art. 13(9)]
And, alongside them, keeping the file. The manufacturer keeps the technical documentation and the EU declaration of conformity available to market surveillance authorities for at least ten years after the product is placed on the market or for the support period, whichever is longer.[Art. 13(13)]
Products you already sell
Products already on the market get relief from most of the Act, but not from reporting. Products placed on the market before 11 December 2027 fall under the essential requirements only if they are substantially modified from that date onwards, but the Article 14 reporting obligations are expressly carved out of that relief and apply to every product in scope that was placed on the market before then. From 11 September 2026 the reporting duty therefore covers a manufacturer's whole installed base, not only what it sells from now on.[Art. 69(2), 69(3)] So a product you sold years ago is inside the reporting duty today, whether or not you still sell it or still support it.
How to choose a period you can keep
Start from how long the product is really used, not how long you would like to support it: returns data, the age of the devices that still call home, and what your customers tell you about replacement cycles.
Then check it against what you depend on. Every component in the product has its own end of support upstream, and your period cannot outlast the parts you cannot patch without a plan for replacing them. The component list is where that shows up first.
Then cost it. A support period is a promise to keep a build pipeline, a test rig and someone who knows the code alive until the last day. Write down the reasoning, because it is the first thing an authority or a large customer will ask for.
The checklist
- Each product has a support period, based on its expected time in use.
- The end date is printed where the buyer sees it before buying.
- Security fixes can be shipped separately from feature releases, and free of charge.
- Every fix goes out with a note saying what it fixes and what users should do.
- Past security updates stay downloadable for as long as the Act requires.
- The component list shows which parts reach their own end of support before your period ends.
- The reasoning behind each period is written down.
If you want help
Our scope check tells you — free, in about two minutes — whether the Act applies to your product and which duties are yours, with the article behind each answer; the support period is one of them. It is our engineering reading of the law, not a legal ruling. Every price for the work after it is on the pricing page.
Not sure where you stand?
Eight short steps, and you find out whether the law reaches your product.