At least five years of free security updates for every product: the CRA makes this mandatory, with consequences for manufacturers and their suppliers.
It boils down to four points:
- Fix vulnerabilities in your products promptly,
- Provide a reporting channel through which third parties can disclose vulnerabilities to you,
- Deliver updates via a secure mechanism, and
- Provide security updates free of charge.
The update obligation is thus only one component among the manufacturer obligations under 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 buy a new generation of features. Many release processes do not support 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 period of use (Article 13 CRA). What matters is what the product is intended for and what users can reasonably expect; you may also refer to comparable products on the market and to the commitments for supplied core components. The minimum is five years, unless the product is demonstrably used for a shorter time.
For a single product this is plannable. Across a portfolio it becomes an ongoing task. A manufacturer with 15 product lines in multiple variants and firmware versions must assess vulnerabilities, build, test and deliver updates for each of them over years. That requires development capacity, functioning build and test environments for older software versions, and a way to reach existing customers at all.
Manufacturers that previously worked on a “product sold, support on demand” principle must fundamentally redesign their support.
Ten years of availability and the second deadline
Article 13 sets a second deadline: every security update you have once released must remain retrievable for at least ten years afterward, and longer if the support period runs longer.
The two deadlines interact differently. The support period determines how long you must develop new updates. The ten-year rule determines how long an already published update must remain accessible. An early-released update accompanies you for the entire remaining support period; a late one remains available for ten years beyond its release.
So you need an update infrastructure that outlives active support. Download portals, update servers, signing keys and the accompanying documentation must be archived so that a patch is still available years after the last development work.
The update obligation reaches into the supply chain
Your update obligation is only as robust as the commitments of your suppliers. In industrial practice, two to three years often pass between the first evaluation of a component and its integration into a series product. Only then does your support period of at least five years begin. Your supplier must therefore be able to patch the component seven to eight years after its appearance.
This belongs in supplier selection and in the contract. Does your supplier commit to that period? Do they actively track vulnerabilities in their component? The costly case is the end of support for a part that is still in the field in your products. The obligation toward the market remains with you.
The cost question security updates without revenue
Free security updates change the calculus of product support. Until now, support could be designed as its own revenue source or discontinued after the warranty period. The CRA excludes both for security-relevant updates.
The CRA allows one narrow exception: for bespoke products made for a specific commercial customer, you may contractually agree otherwise. Off-the-shelf products do not have this leeway.
The costs of security maintenance over at least five years must therefore be factored into the product price. It becomes tight for low-cost products with many variants. If a single update must be qualified and rolled out across multiple lines and variants, the cost can quickly exceed the original development cost of the product.
The expected service life determines the support period
Industrial control systems in the field often run ten to fifteen years, routers and operating systems well beyond five. Your support period then runs that long as well. You can fall below five years only for products that are genuinely used for a shorter time.
Decide consciously how long your products are expected to be used, and record what you base that assessment on. This justification belongs in the technical documentation. If you set the service life short while comparable products on the market run for ten years, you must be able to explain that to market surveillance.
The determination will not remain solely with you anyway. If it becomes apparent on the market that manufacturers set support periods too short, the EU Commission can prescribe minimum periods for specific product categories.
What you need to build now
From December 2027 the CRA obligations 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 largest for broad portfolios, high supplier content and support that previously ran on an ad hoc basis.
Arrange the update obligation within the overall picture 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 numerous 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 needed.
