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

Of all the CRA’s requirements, 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.

Two ancillary obligations that go unnoticed:

  • Security updates made available during the support period must remain available for at least ten years after the product is placed on the market, or for the remainder of the support period, whichever is longer. 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 or 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 in the first month of the project, not the last:

  • 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 built on sand. 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 and published updates stay available for ten; an SoC with end of life at three years breaks the commitment, an embedded OS at four does too.
The promise and what holds it up: any component that dies before the commitment turns the promise into sand.

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. It is easier to design for five years than to patch your way to them.

For those who already have a product on the market, the inverse exercise: list the components whose end of life falls within the declared support period and decide, for each one, between planned replacement, extended support contracted from the supplier, or your own documented mitigation.

Sources