5 years of security updates required by CRA for manufacturers

At least five years of free security updates per product: the CRA makes this mandatory, with consequences for manufacturers and their suppliers.

It comes down to four points:

  • Quickly fix vulnerabilities in your products,
  • Provide a reporting channel through which third parties can report vulnerabilities,
  • Deliver updates via a secure mechanism, and
  • Provide security updates free of charge.

The update obligation is thus only one component of the manufacturer obligations of the CRA.

You may charge for new features, but not for security patches. Where technically feasible, both must also be delivered separately: your customer should be able to close a vulnerability without having to purchase a new generation of features. Many release processes do not provide for this separation today.

How long must you provide updates?

You set the support period yourself, but not arbitrarily. It must reflect the product’s expected useful life (Article 13 CRA: https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=OJ:L_202402847#art_13). What matters is what the product is intended for and what users can reasonably expect; you may also orient yourself to comparable products on the market and to the commitments for core components supplied to you. The minimum is five years, unless the product is clearly used for a shorter period.

For a single product this is plannable. Across a portfolio it becomes a long-term task. A manufacturer with 15 product lines in several variants and firmware versions must assess vulnerabilities, build, test and deliver updates for each of them for years. You need development capacity for that, functioning build and test environments for old software versions, and a way to reach existing customers at all.

Manufacturers who have so far worked on the principle “product sold, support on demand” must fundamentally reorganize their support.

Ten years of availability the second deadline

Article 13 sets a second deadline: every security update you have once delivered must be retrievable for at least ten years thereafter, and longer if the support period runs longer.

The two deadlines operate differently. The support period indicates how long you must develop new updates. The ten‑year rule indicates how long an already published update must remain accessible. An early-delivered update accompanies you for the entire remaining support period; a late one remains available for ten years beyond its delivery.

You therefore need an update infrastructure that outlives active support. Download portals, update servers, signing keys and the associated documentation must be archived so that a patch is still available years after the last development hour.

The update obligation reaches into the supply chain

Your update obligation is only as enforceable as the commitments of your suppliers. In industrial practice, two to three years pass between the first evaluation of a component and its installation in a series product. Only after that does your support period of at least five years begin. Your supplier must therefore still patch the component seven to eight years after its appearance.

That belongs in supplier selection and in the contract. Does your supplier commit to this period? Do they actively track vulnerabilities in their component? The expensive case is the end of support for a part that is still in the field in your products. The obligation toward the market still remains with you.

The cost question security updates without revenue

Free security updates change the product support calculation. Until now, support could be set up as a separate revenue source or discontinued after the warranty period. For security-relevant updates the CRA excludes both.

The CRA allows one narrow exception: for tailor-made products for a specific commercial customer you may contractually agree something different. For off‑the‑shelf products there is no such leeway.

The costs of security maintenance over at least five years must therefore be included in the product price. It becomes tight for low‑priced products with many variants. If a single update must be qualified and rolled out across several lines and variants, that can quickly cost more than the original development of the product.

The expected useful life determines the support period

Industrial control systems often run in the field for ten to fifteen years, routers and operating systems much longer than five. Your support period then runs for as long. You only get below five years for products that actually have a shorter service life.

Decide consciously how long your products are expected to be used and document the basis for this estimate. This justification belongs in the technical documentation. If you set the useful life short while comparable products on the market are used for ten years, you will have to explain that to market surveillance.

The determination is not left to you alone. If it becomes apparent on the market that manufacturers set their support periods too short, the EU Commission can prescribe minimum periods for individual product categories.

What you need to build now

From December 2027 the CRA obligations will apply in full. Until then manufacturers need build environments for legacy products, robust supplier contracts and capacity planning that firmly anchors security support in the development process. The task is greatest for a broad portfolio, high supplier share and support that was previously demand‑driven.

Therefore, place the update obligation in the overall context of the Cyber Resilience Act before you set your priorities.

Which CRA obligations are still open for you?

The update obligation is only one of many CRA requirements that manufacturers must implement by December 2027. With the CRA readiness check you can assess in a few minutes where your company stands and where action is required.