Cyber Resilience Act Requirements: What Changes for Connected Device Makers

What the Cyber Resilience Act is

Cyber Resilience Act (CRA)

The Cyber Resilience Act is the EU regulation that sets cybersecurity requirements for hardware and software products with digital elements, and makes meeting them a condition for placing those products on the EU market.

The European Commission puts it plainly: products must meet the requirements before they are sold in the EU, they carry the CE marking to show it, and national market surveillance authorities enforce it. For connected devices, that changes what security is. It used to be a feature for the brochure. Now it decides whether the product can be sold at all.

The scope is wide. A product with digital elements is any hardware or software that connects, directly or indirectly, to a device or a network. That covers consumer smart home devices, wearables, gateways, industrial sensors and the apps and firmware that run them. Medical devices, vehicles and some other products under their own sector rules sit outside it.

We covered how the CRA sits next to the NIS directive and the main ETSI and IEC security standards in our overview of IoT security regulations. Here we go one level down, to what the CRA asks of the device and of the team that builds it.

Cyber Resilience Act timeline: the dates that matter

The CRA entered into force on 10 December 2024. The main obligations introduced by the Act will apply from 11 December 2027, with reporting obligations to apply as of 11 September 2026.

Provisions on notifying conformity assessment bodies apply from 11 June 2026, so the bodies that will certify higher-risk products are being set up now.

The order matters more than the exact dates. Reporting of actively exploited vulnerabilities applies to products already on the market, including those sold before the main obligations start. A team that has no way to learn about exploited vulnerabilities in its fleet, or no one on call to file a report, is exposed from the first deadline, not the last.

Product cycles make the rest urgent too. Hardware frozen in the next few months will often still be on sale years from now, and what its update path, secure boot and logging can do is fixed at design time.

What the CRA requires from the device

The essential requirements in Annex I of the Regulation split into two parts: properties of the product, and how the manufacturer handles vulnerabilities. Translated into engineering work, the product requirements look like this.

Teams that already build connected products well will recognise most of this list. The difference is that every line now needs evidence in the technical documentation, and a gap can keep the product off the market.

Vulnerability handling, SBOM and support period

The second part of Annex I covers the manufacturer's process. Manufacturers must identify and document vulnerabilities and components, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies.

They must also fix vulnerabilities without delay, test security regularly, publish information about fixed vulnerabilities, run a coordinated vulnerability disclosure policy with a contact address for reports, and distribute updates securely. Where technically feasible, new security updates shall be provided separately from functionality updates.

Treat the support period as a design input, not something to settle after launch. The support period shall be at least five years; where the product is expected to be in use for less than five years, it shall correspond to the expected use time. Each security update made available during the support period must remain available for a minimum of 10 years or for the remainder of the support period, whichever is longer.

Reporting actively exploited vulnerabilities

Reporting applies first. A manufacturer notifies any actively exploited vulnerability in its product simultaneously to the CSIRT designated as coordinator and to ENISA, through a single reporting platform.

The timing is strict: an early warning within 24 hours of becoming aware of an actively exploited vulnerability, a vulnerability notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available.

Severe incidents that affect the security of the product follow the same early warning and notification steps, with a final report within one month after the incident notification.

Conformity assessment: self-assessment or third party

Most products can be assessed by the manufacturer itself through internal control. The Commission notes that most products, such as household appliances, computer games or mobile applications, fall into this category.

Products listed in Annex III as important need more. Class I includes, among others, routers and modems, operating systems, microcontrollers and microprocessors with security-related functionalities, smart home products with security functionalities such as smart door locks, security cameras and alarm systems, connected toys and wearables for children or health monitoring. A class I product can still be self-assessed if the manufacturer fully applies harmonised standards or an appropriate certification scheme; otherwise a third party is involved.

Class II, which includes firewalls and tamper-resistant microcontrollers, always needs a third-party procedure. Critical products in Annex IV, such as smart meter gateways and secure elements, may be required to hold a European cybersecurity certificate.

The penalty for not meeting the essential requirements or the reporting obligations reaches up to EUR 15 000 000 or 2.5% of total worldwide annual turnover, whichever is higher.

What changes in firmware and the update path

For most device makers, the CRA comes down to three pieces of engineering: how the device boots, how it updates, and how the team knows what is inside each image.

Boot and identity. Secure boot that only runs signed images, unique credentials per device and locked debug interfaces are the foundation for most of the Part I requirements. On microcontrollers this usually means a verified bootloader such as MCUboot and keys provisioned on the production line.

Updates that cannot brick the fleet. Indeema has delivered firmware with MCUboot, custom bootloaders, A/B updates with rollback and secure boot. In one data-link project, the design record specifies a factory slot and two update slots, an image that is verified before the boot choice changes, and automatic rollback to the previous firmware if the new one fails its self-test or power is lost during its first boot. That design has a price in flash. With a 1.5 MB image, two OTA slots need 3 MB and a factory slot raises application space to 4.5 MB, which exceeds a 4 MB flash part. So decide the update architecture before you choose the memory part.

Knowing what is inside. An SBOM generated by the build for every release, not written by hand once, lets a team answer the first question after any disclosure: which devices carry this component.

Our embedded firmware team builds these parts as one design: bootloader, update client, signing and the build pipeline that produces the SBOM.

Where to start this quarter

You don't need to wait for harmonised standards for any of this. The Regulation already says what the product and the process must do.

If a hardware freeze is coming up, now is the cheapest moment to check the design. Our firmware engineers can go through boot, identity, the update path and SBOM generation with your team, and tell you what the current hardware can support and what needs a board revision.

Common mistakes

1. Treating the CRA as a documentation task

   The paperwork is ready, but the device cannot receive a signed security update.

   Instead: Start with boot, identity and the update path, then document what the device does.

2. Planning for the main obligations only

   The team has no process when reporting starts for products already on the market.

   Instead: Set up the disclosure contact, monitoring and on-call reporting first.

3. Writing the SBOM once by hand

   It is out of date after the next release and useless when a disclosure arrives.

   Instead: Generate it in the build for every firmware release and keep it with the release.