Cyber Resilience Act
In shortSoftware and connected devices will need security updates for a defined period — with CE marking.
At a glance
- Instrument
- Regulation (EU) 2024/2847, in force since December 2024
- Who is covered
- Manufacturers, importers and distributors of products with digital elements — hardware and software alike
- Core duties
- Security across the lifecycle, vulnerability handling, security updates, conformity assessment and CE marking
- Support period
- As a rule at least five years, aligned with the product's expected lifetime
- Reporting duties
- Actively exploited vulnerabilities and severe incidents must be reported promptly
- Free software
- Open-source software supplied non-commercially is largely exempt; commercial supply is covered
The Cyber Resilience Act is the first European instrument to place security requirements directly on products rather than on their operators. It covers products with digital elements — from a connected sensor through a controller to application software.
The idea behind it is a shift of responsibility: security should no longer rest mainly with the user applying updates, but with the manufacturer supplying them over a committed period.
The central duties
Security across the entire lifecycle, starting at development. Documented vulnerability handling with reporting channels. Security updates over a defined support period aligned with expected lifetime and generally lasting at least five years. A conformity assessment resulting in CE marking. And prompt reporting of actively exploited vulnerabilities.
What this means for procurement
Until now the question of update supply was a matter of negotiation and rarely asked. In future it is a product property you can rely on.
Three points therefore belong explicitly in tenders and purchase contracts: the committed support period, the reporting route for vulnerabilities, and the procedure for delivering updates. For machinery this connects directly to remote maintenance and the data access governed by the EU Data Act.
The relationship with NIS2
NIS2 binds operators, the Cyber Resilience Act binds manufacturers. The two interlock: an operator can only meet its duties if products receive security updates, and a manufacturer learns through the reporting channels what is actually being exploited.
The point often missed
Open-source software is treated in a differentiated way: non-commercially supplied projects are largely exempt, commercial supply is covered. Anyone building open components into their own product and distributing it carries the manufacturer duties for the whole — an argument for knowing your own dependency chain that has nothing to do with ideology.
Common questions
- Does the CRA concern us as a buyer?
- Not as an addressee if you only purchase. Indirectly very much so: you will be able to rely on committed support periods and vulnerability handling — which belongs in your procurement requirements.
- What changes for software we develop and sell ourselves?
- You become a manufacturer under the regulation: security requirements across the lifecycle, documented vulnerability handling, provision of security updates, and a conformity assessment with CE marking.
- How does the CRA relate to NIS2?
- NIS2 binds operators, the CRA binds manufacturers. Anyone who is both — a provider operating and distributing its own software — has to serve both sides.
- What does it mean for using free software?
- For non-commercially supplied projects little changes. Anyone supplying free software commercially, or building it into a product, carries the manufacturer duties — which has an upside: the user gets committed maintenance.