Skip to content
folhas.io
secure by design for connected products· Articles

Articles

The support period: the most expensive promise the CRA makes you make

The CRA obliges every manufacturer to declare for how long it supports the product: as a rule, at least five years. It is an engineering, contracts and supplier decision disguised as a field on a form.

Published
Updated

Update note (23 Oct 2026). We corrected the rule on how long security updates must stay available, since the ten years run from the issue of each update, added the date from which Article 13 applies and the example of the runtimes patched in October 2026, and now cite the Commission guidance of 27 July 2026, published after the first version of this article.

Of all the requirements of the CRA, the support period is the one that looks most administrative and is the one that commits the most. Article 13 obliges the manufacturer to determine a period during which it ensures effective vulnerability handling for the product, and to declare it, because the user has to know, at the moment of purchase, until when they can count on security updates.

The rule

The support period reflects the expected time of use of the product, and cannot be shorter than five years, unless the product is intended to be used for less time, in which case it covers that time of use. Factors in the determination include, among others, the user’s reasonable expectation, the nature of the product and the support period of comparable products on the market. The end-of-support date is indicated clearly, including, at a minimum, month and year. The Commission guidance of 27 July 2026, C(2026) 5252, points out that the five years are a minimum safeguard: a product expected to be used for longer should have a longer support period.

Two ancillary obligations that go unnoticed:

  • Security updates made available during the support period must remain available for at least ten years after each one is issued, or for the remainder of the support period, whichever is longer. The count runs per update: a fix issued in year four stays available at least until year fourteen. A published patch cannot vanish from the server two years later.
  • The technical documentation, including the reasoning behind the chosen duration, is kept for at least ten years after the product is placed on the market or for the support period, whichever is longer, and the market surveillance authorities can request the data on which the decision was based.

Why this is an engineering decision

Promising five years of vulnerability handling is not promising goodwill; it is promising that, five years from now, a technical path to fix and deliver still exists. That pulls on decisions taken right in the first month of the project:

  • Alignment with suppliers. If the chosen SoC has an announced end of life three years out, or the vendor’s BSP stops receiving patches, the five-year promise is left without a technical path to a fix for the remaining years. The product’s support period has to be reconciled with the life cycle of every critical component in the SBOM and, in supply contracts, with matching support clauses.
  • Durable update capability. The update mechanism (OTA or local) has to keep working for the entire period: signing keys managed and rotatable, flash space reserved for larger future images, distribution infrastructure budgeted as a recurring cost.
  • Build compatibility at five years. Rebuilding the firmware in 2031 with the 2026 toolchain requires reproducible builds and archived environments. Without that, the first serious CVE in an old component turns into an archaeology project.
Timeline bar chart: the product's CRA commitment lasts at least five years; an update issued in year four stays available for ten years from its issue, until year fourteen; an SoC with end of life at three years breaks the commitment, an embedded OS at four does too.
Each bar that ends before the five-year mark is a gap to close component by component: planned replacement, extended support contracted from the supplier, or your own documented mitigation.

And a contracts decision

The declared period goes into the user information and, in practice, into contracts with B2B customers, who will frequently ask for more than the minimum. It is worth separating two things contracts tend to merge: the CRA support period (vulnerability handling and security updates, a legal obligation) and commercial support (new features, SLA, assistance), which is negotiable. Selling the distinction to the customer keeps a five-year legal obligation from turning, by contractual drift, into a five-year roadmap promise.

What this means for manufacturers

For our own product, the decision we took was to treat the support period as a first-order design constraint, on a par with unit cost: no component enters the BOM without a known end-of-life date compatible with the target period, and the product budget includes the annual cost of the update infrastructure across the whole period.

A timing caveat: Article 13, including the support period, applies only from 11 December 2027. Products placed on the market before that date are only subject to it if they undergo a substantial modification afterwards (Art. 69(2)). But placing on the market counts unit by unit: units of a current model placed on the market on or after 11 December 2027 must comply, with a declared support period. Article 14 reporting, by contrast, has applied since 11 September 2026 to all products, including those already on the market (Art. 69(3)), and continues after the support period ends.

For those who already have a product on the market and will keep selling it after December 2027, the exercise is the inverse: list the components whose end of life falls within the support period you will have to declare and decide, for each one, between planned replacement, extended support contracted from the supplier, or your own documented mitigation.

Runtimes and software libraries are SBOM components too, with an end of life as concrete as an SoC’s, and the PHP and Node.js fixes of 21 Oct 2026 showed it clearly. PHP 8.1, out of support since 31 Dec 2025, got no fixed release, only minimal source-code backports with no new version number. Node 20, out of support since 30 Apr 2026, got no fix. PHP 8.2 did get it, but the project stops supporting it on 31 Dec 2026. No line of either runtime has five years of support from the project, so meeting the declared period takes one of the three routes: major-version migrations planned in advance, extended support contracted from a distribution or an LTS vendor, or your own fixes, which Article 13(6) requires you to share with whoever maintains the component. The case is covered in article 09. The Linux kernel and Python also have end-of-life dates set per branch, covered in article 10.

Sources