On this page
- Base support on expected use, with the five-year minimum and shorter-use exception in Article 13(8).
- Make the support end date accessible at purchase, including at least month and year.
- Keep issued updates available for ten years after issue or the remaining support period, whichever is longer.
- Record the rationale and how upstream end-of-life risks will be handled.
How long must CRA support last?
Article 13(8) requires the period to reflect how long the product is expected to be used, considering reasonable user expectations, product nature, intended purpose and relevant Union law. The minimum is five years unless expected use is shorter, in which case support corresponds to that expected use. A longer-lived product cannot simply use five years as a universal ceiling.
Other factors include comparable products, operating-environment availability and support for integrated components providing core functions. Record the information used in the Annex VII technical file. Commercial preference alone is not an adequate explanation for a shorter lifetime.
How do placement dates and customer promises fit together?
Article 13(8) connects vulnerability handling to placing on the market and the support period. Article 13(19) requires an accessible support end date at purchase. Do not substitute a blanket rule that every software product receives five years from its last sale: identify the product, relevant placement facts, version and committed end date.
For continuing sales, check that later supply remains consistent with the period the law requires. Distinguish a sale, initial placement on the Union market, a renewal and a release update. Have the responsible person review these facts and retain the explanation instead of calculating the commitment from a repository tag alone.
What happens to updates after support ends?
Article 13(9) requires each security update issued during support to remain available for at least ten years after issue or for the remainder of support, whichever is longer. Ending development of new fixes is different from removing existing downloads.
For example, an update issued in June 2029 must remain available at least until June 2039, even if support ends earlier. Keep its artifact, integrity information and installation instructions accessible. This illustrates update availability, not a universal support end date.
Operate the commitment across your supply chain
A product can outlive its runtime, operating system or a key library. Keep a dependency lifecycle register and choose an upgrade, replacement or maintenance plan before upstream support ends. The vulnerability-handling process should cover supported releases, not only the development branch.
Communicate and review the end date
Publish a consistent commitment in buyer information, user instructions and the support policy. Article 13(19) calls for an end-of-support notification where technically feasible. Resolve conflicting dates before they become a customer problem.
Under Article 13(10), limiting remediation under Annex I, Part II, point (2) to the latest substantially modified software version is conditional: earlier users must have free access to it without additional costs to adjust their hardware or software environment. Other vulnerability-handling duties continue for the earlier versions during support. A paid upgrade or hardware replacement is not automatically an acceptable substitute. Reporting and other applicable duties need their own analysis; a support label does not settle them.
Frequently asked questions
Is the CRA support period always five years?
No. It must reflect expected use and is at least five years unless expected use is shorter. Longer-lived products may require longer support. Document the rationale under Article 13(8).
Can we delete old security updates when support ends?
No. Article 13(9) requires issued updates to remain available for at least ten years after issue or the remaining support period, whichever is longer.
Can an upstream end-of-life date shorten our promise?
It is an input to planning, not an automatic release from the manufacturer obligation. Assess whether to upgrade, replace or maintain the component and keep the product commitment defensible.