CRA Support Period: Five Years Is a Floor, Not a Default

· Yunus Yildiz

"The CRA requires five years of security updates" is the most repeated summary of Article 13(8), and the Commission's application guidance of 27 July 2026 says plainly that it is wrong: "A support period of five years is therefore not to be considered as the default for all products with digital elements."

This post goes through how the support period is actually set, what has to happen during it, how it works for software that ships a new version every few months, and what continues after it ends.

What the Support Period Is

During the support period, the manufacturer must ensure that vulnerabilities of the product, "including its components, are handled effectively" in line with the vulnerability handling requirements in Part II of Annex I: identifying components (including an SBOM), remediating without delay, testing, disclosing fixed vulnerabilities, coordinated disclosure, and distributing security updates. Those requirements apply from 11 December 2027.

How It Is Set

Article 13(8) ties the period to the length of time the product is expected to be in use, and names what must be considered:

  • reasonable user expectations;
  • the nature of the product, including its intended purpose;
  • relevant Union law determining the lifetime of products.

It also names what may be considered: the support periods of products with similar functionality from 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 guidance from the Commission and the market surveillance authorities' cooperation group (ADCO). All of it is to be weighed "in a manner that ensures proportionality".

Then the floor: the support period "shall be at least five years", unless the product is expected to be in use for less than five years, in which case it matches the expected use time.

Recital 60 shows which way the floor is meant to push. Products expected to be used longer than five years, "as is often the case for ... operating systems or video-editing tools", and routers, and above all industrial control systems, "should accordingly" get longer support. A shorter period needs a product whose nature justifies it; the recital's examples are a pandemic contact-tracing app and software that stops working when its subscription ends.

Write the reasoning down. The information taken into account goes into the technical documentation (Annex VII, point 4). A market surveillance authority can ask why you chose three years for something customers run for ten.

What Has to Happen During It

Three obligations follow from the period once it is set:

  • Tell buyers when it ends. The end date, "including at least the month and the year", must be specified "at the time of purchase in an easily accessible manner" (Article 13(19)). The user instructions must state the type of security support and the end date (Annex II, point 7).
  • Tell users when it has ended, by a notification, "where technically feasible in light of the nature of the product" (Article 13(19)).
  • Keep security updates available. Each security update issued during the support period must remain available "for a minimum of 10 years or for the remainder of the support period, whichever is longer" (Article 13(9)). That is a retention obligation on your download infrastructure that outlives the product.

Software With Frequent Releases

Here the guidance (section 5, paragraphs 128 to 131) matters most, because the Regulation reads naturally for a device with one firmware line and less naturally for a product that ships every quarter.

Each substantially modified version needs a declared support period. "Each substantially modified version of a software product with digital elements placed on the market has to have a declared support period that complies with Article 13(8)", including the five-year minimum unless that version's expected use time is demonstrably shorter.

But you may remediate only the latest version, under Article 13(10), if users of earlier versions can get the latest one free of charge and "do not incur additional costs to adjust the hardware and software environment". The guidance defines those costs narrowly. Testing, configuration changes, personnel time and upgrading underlying dependencies to replace end-of-life components are normal operational effort, not additional costs. New hardware, infrastructure replacement or "fundamental changes to the operating environment" are (paragraph 130). Its example 53 is an enterprise product that ships substantially modified versions every few months and relies on Article 13(10) to stop fixing older ones once users can upgrade.

Two limits apply. Article 13(10) covers only the obligation to address and remediate vulnerabilities (Annex I, Part II, point 2). Coordinated disclosure, information sharing and Article 14 reporting continue for every version (paragraph 131). And users who stay on an older version should be told, where technically feasible, that it is no longer being fixed. Nothing stops you from selling extended support for older versions; the guidance notes the CRA does not require it to be free.

Substantial Modification Does Not Reset the Clock

A substantial modification makes the modified product a new placing on the market, but its support period is not automatically restarted (section 5.1). The question is whether the modification changes what determined the expected use time. A software feature release on hardware that wears out on the same schedule does not; the support period follows the remaining expected use time. Replacing a controller's computing platform with one built to last much longer does, and the period is recalculated.

What Outlives the Support Period

The vulnerability handling obligations of Annex I, Part II end with the support period. The reporting obligations do not. The guidance states that "unlike the vulnerability handling obligations, which continue only for the length of a product's support period, the reporting obligations continue to apply after a product with digital elements is no longer supported" (paragraph 210). An actively exploited vulnerability in a version you stopped supporting three years ago is still reportable under Article 14, within 24 hours of becoming aware of it. ENISA's reporting form even has a field for it: "End of support indicator".

A Working Checklist

  1. Decide per product line, from expected use time, not from a policy number. Record the reasoning for Annex VII.
  2. Check your core dependencies. The support periods of third-party components that provide core functions may be taken into account, and in practice they constrain you: a base image or runtime that reaches end of life before your product does is a remediation problem waiting for a date.
  3. Publish the end date per version, month and year, where buyers see it before they buy.
  4. Decide your Article 13(10) policy for versioned software: which versions you fix, and whether upgrades are free and free of additional costs as the guidance defines them.
  5. Plan the end-of-support notice and the ten-year retention of security updates.
  6. Keep the reporting runbook for unsupported versions. It needs an owner even when nobody ships code for that version any more.

Sources

This article reflects our reading of the Regulation and the Commission's guidance as of the date above. The guidance is not legally binding. It is not legal advice.