For an OEM sourcing electronic design in Europe, the Cyber Resilience Act – Regulation (EU) 2024/2847 – has quietly become a supplier selection criterion. Whoever places a connected product on the EU market carries the compliance burden, and a design partner that already builds to the regulation removes a category of risk from the programme.
The date that matters is close: 11 September 2026. It is not full application – that comes in December 2027 – but it is when the first enforceable duty starts, the obligation to report vulnerabilities. And it is a duty no policy document can satisfy on its own: it assumes the product was designed a certain way.
From 11 September 2026 every manufacturer must be able to detect, and report within 24 hours, an actively exploited vulnerability in its product. Without secure boot, signed updates and an SBOM the capability simply is not there – and it belongs in the hardware, not in the procedures.
Cyber Resilience Act deadlines: what applies and when
The regulation entered into force on 10 December 2024 and applies in stages. Three dates are worth keeping in mind:
- 11 June 2026 – Chapter IV applies: conformity assessment bodies must be notified by national authorities before they can operate. It is what makes a working certification chain exist by the time it is needed.
- 11 September 2026 – Article 14 applies: mandatory reporting of actively exploited vulnerabilities and severe incidents. It covers products already on the market, not only those placed after that date.
- 11 December 2027 – full application: essential cybersecurity requirements (Annex I), conformity assessment, CE marking extended to cybersecurity, technical documentation.
Reading “2027” and shelving the topic is the common mistake. The 2026 reporting duty is the first one with a penalty attached, and CRA penalties are not symbolic: up to EUR 15 million or 2.5% of worldwide annual turnover for breaches of the essential requirements and of the Article 13 and 14 obligations.
Who counts as the manufacturer under the CRA
This is the question that most often changes the picture for a buyer. Under the regulation, the manufacturer is whoever places the product on the EU market under their own name or trademark. Not whoever designed the board, not whoever wrote the firmware: whoever puts the nameplate on it.
Three practical consequences follow. A machine builder buying a communication module from an Asian supplier and integrating it into a cabinet answers for that module's vulnerabilities. An importer who rebrands a product becomes the manufacturer in full. And substantially modifying a product already on the market – adding connectivity to an existing machine, for example – pulls the obligations back onto whoever made the change.
Hence a sourcing rule worth adopting now, ahead of full application: ask for the supplier's SBOM and a written commitment on security updates at quotation stage. A component that cannot be patched is not a technical detail – it is a liability inherited with the delivery. It is also one reason European OEMs are moving embedded work closer to home: a supplier in the same regulatory space is answering the same questions you are.
Vulnerability reporting: 24 hours, 72 hours, 14 days
Article 14 requires the manufacturer to notify, through the single reporting platform set up by the CRA, the CSIRT of the member state where its main establishment sits and, simultaneously, ENISA. The windows are these:
The 24 hours start when the manufacturer becomes aware of the exploited vulnerability or the severe incident. That is what makes the duty an engineering matter rather than a paperwork one: meeting a 24-hour window requires a channel through which the news arrives, and the ability to work out which units in the field are affected.
In practice it takes three things that have to be designed rather than improvised: a public contact point for coordinated vulnerability disclosure – a reachable page and an address someone actually reads – an inventory of firmware versions deployed in the field, and the ability to ship a patch within the 14-day final report window. A fleet that can only be updated by sending a technician with a USB stick does not fit this calendar.
The CRA also covers devices with no internet connection
This is the most common misreading, and it leaves the most traditional manufacturers exposed. The regulation covers “products with digital elements” whose intended use, or reasonably foreseeable use, involves a logical or physical data connection direct or indirect to a device or a network.
Indirect is the decisive word. A sensor node on a CAN bus with no Ethernet and no radio, talking only to the controller of the machine it is mounted on, falls inside the scope if that controller is connected to a gateway, a PLC or a telemetry system. That is the architecture of very nearly every industrial and mobile machine built today.
The design consequence is that security cannot be concentrated on the one “connected” component. On a CAN network every node is a potential entry point, and the bus by design offers no message authentication. Perimeter thinking – a firewall on the gateway and an assumption that everything behind it is safe – is precisely what the CRA forces manufacturers to revisit.
What the firmware needs: secure boot, signed OTA and SBOM
The Annex I essential requirements become binding in December 2027, but a product in development today will reach the market after that date. These are decisions to take now, while they are cheap: adding secure boot to a validated design almost always means changing microcontroller and repeating the test campaign.
Secure boot and root of trust
The device must cryptographically verify the code it runs, starting from an immutable root of trust. On new designs the cleanest route is an MCU with TrustZone and native secure boot – the STM32 Cortex-M33 family (H5, U5, L5) provides secure boot, key storage and debug protection without external parts. The price delta against an equivalent MCU without those features is a few euros today; the cost of adding them later is a redesign.
Signed firmware updates
The OTA update must be authenticated, integrity-checked and reversible. Concretely: asymmetric image signing verified by the bootloader, dual bank flash with automatic rollback if the new image fails to run, and anti-downgrade protection so a device cannot be forced back to a vulnerable version. On CAN bus that means a bootloader able to update a remote node without dismantling the machine – a feature many programmes treated as a luxury before the CRA.
Software Bill of Materials
The SBOM is the traceable list of everything running in the product, in the standard CycloneDX or SPDX formats: real-time operating system (RTOS), communication stacks, cryptographic libraries, vendor HAL, and their versions. It exists to answer, in hours, the only question that matters when a CVE lands on a widely used library: do our products use it, and which ones. Without an SBOM that answer takes days of code archaeology, and the window is 24 hours.
Declared support period
The manufacturer must set and communicate how long security updates will be provided: the regulation points to at least five years unless the expected product lifetime is shorter. In industrial markets, where a machine stays in service ten to fifteen years, that requirement reaches back into component selection: an end-of-life microcontroller or an unmaintained software stack makes the commitment impossible to honor.
What to do before September 2026: five concrete steps
- Map the catalogue: list the own-brand products with a data connection, indirect ones included. That list is the scope.
- Publish a reporting channel: a coordinated vulnerability disclosure page with a monitored address, and a
security.txtfile per RFC 9116. It is the cheapest step and the most visible. - Rebuild the SBOM for active products: starting with the highest installed base. If the firmware was developed externally, request it from the supplier.
- Define the notification procedure: who decides a vulnerability is “actively exploited”, who files the report, within what time. A three-line procedure that works beats a manual that does not.
- Put the requirements into new projects: secure boot, signed OTA and SBOM generation belong in the specification alongside the functions, not after validation.
The Nexilica approach to CRA compliance
At Nexilica, based in Modena, Italy and working with manufacturers across Europe, regulatory compliance is not a closing phase of the project: it sits in the initial engineering consulting, next to CE marking and the feasibility study. On the hardware side that means selecting the microcontroller partly on its security features and its vendor-declared lifecycle, and handling electronic design with protected debug access in mind. On the software side it means building embedded firmware with a secure bootloader, a signing chain and automated SBOM generation in the build pipeline – where it costs nothing, because the toolchain already knows the dependency list.
The same applies to devices running embedded artificial intelligence, where the model itself – not only the firmware executing it – must be securely updatable and tracked in the SBOM.
The Cyber Resilience Act does not ask anyone to reinvent their product: it asks that the product can be updated, that you know what is inside it, and that you notice when something goes wrong. Those three properties are cheap when they go into the architecture at the start and expensive when they are retrofitted. If you are developing a product that will reach the EU market after 2027, or you have an installed base to bring in line by September, get in touch: we start from a scope assessment and what is actually missing.
