What the Cyber Resilience Act Asks of a Connected Product
The regulation is often summarised as security requirements for connected devices, which is true and not actionable. What it actually obliges a manufacturer to build, to document, to report and to keep doing for years after the sale.
The Cyber Resilience Act is usually summarised as a rule that connected products must be secure. That is accurate and it is not something anybody can act on. The useful version is narrower: it is a CE-marking regime, it applies to almost anything with a digital element placed on the EU market, and most of what it demands is not a feature you add before launch but an obligation you carry for years afterwards.
Start with scope, because it is wider than people expect. The regulation covers products with digital elements — hardware and software — whose intended or reasonably foreseeable use includes a data connection to a device or network. That is not limited to obviously networked things. A sensor that talks to a gateway is in scope. So is the software you ship alongside it, and so is a component you sell to another manufacturer. There are carve-outs where sectoral legislation already covers the ground, medical devices and vehicles among them, and open-source software that is not supplied in the course of a commercial activity sits outside. Everything else is in.
Products are then sorted by risk. The default class carries self-assessment: the manufacturer declares conformity themselves. Two higher classes, described as important and critical, cover categories where a compromise is more consequential — identity management, password managers, network interfaces, industrial control system components, microcontrollers with security functions and similar — and these require either the use of harmonised standards or third-party assessment. Sorting your own catalogue into these buckets is the first concrete piece of work, because the answer determines whether your compliance route is paperwork you control or an audit you have to book.
The essential requirements themselves read as good engineering, which is the point. Products must ship without known exploitable vulnerabilities and with a secure default configuration. There must be a way to reset the product to that default. Access must be protected by appropriate control mechanisms. Data must be protected in transit and at rest as appropriate to the purpose. The attack surface must be minimised, and the effects of an incident limited. Security-relevant events must be recordable and monitorable. And updates must be distributable — security updates separated from functional ones where feasible, and delivered without delay and free of charge.
Two of the process obligations are what make this a long commitment rather than a launch checklist. The first is the software bill of materials: manufacturers must identify and document the components in their product, at least the top-level dependencies, in a machine-readable format. This is not published to the world, but it must exist and be kept current, and it is what makes the second obligation possible. The second is a vulnerability handling process that runs for the support period: monitor components for newly discovered vulnerabilities, remediate them without delay, and have a coordinated disclosure policy with a contact address that works.
The support period is the clause that reaches furthest into product planning. Manufacturers must determine and declare it based on how long the product is reasonably expected to be in use, and the regulation sets an expectation of at least five years unless the product's lifetime is genuinely shorter. Declaring a support period is easy; resourcing five years of security updates for a device sold at industrial margins is a business model question, and it is better answered before the product is designed than after it ships.
Reporting is the obligation with the shortest clock. Actively exploited vulnerabilities and severe incidents affecting the security of a product must be reported through the designated single reporting platform, with an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report later. A 24-hour clock is not something you improvise. Somebody has to know they own it, know where to file, and have the authority to do so on a weekend.
The dates worth putting in a plan: the regulation entered into force in December 2024, the reporting obligations apply from September 2026, and full application follows in December 2027. The gap between those last two is deliberate and slightly awkward — you can be obliged to report an exploited vulnerability before the rest of the regime applies to you.
If you build connected hardware, the honest summary is that the engineering requirements are mostly things a competent team would want anyway, and the process requirements are where the cost is. An SBOM that is current, a monitoring routine that notices when a dependency you shipped three years ago gets a CVE, an update channel that still works on the oldest device in the field, and a named person who can file within 24 hours — that is the actual project, and none of it is visible in the product.