What the Cyber Resilience Act (CRA) means for Hardware Manufactures

Introduction

The EU has released a new regulation that is aimed at hardening connected devices. This ranges from infrastructure usage to consumer applications. Specifically, it affects not just hardware but all products with digital elements. This includes any programmable or network-connected component, i.e. microcontrollers, firmware and embedded Linux systems. Like other regulations, many hardware manufacturers will ignore the implications until it’s too late, turning a years long transition period into a few months of crunch at best.

The Cyber Resilience Act is in force since December 2024 and will enter in full force as of 11 December 2027, where reporting obligations apply from 11 September 2026. Products put on the market before 11 December 2027 are only required to meet CRA conformity requirements, if they are substantially modified. However, vulnerability reporting applies to all products with digital elements that are still within their support period or actively being placed on the market.

Disclaimer: I’m a computer scientist, not a lawyer. The goal is to summarize the most important information, please consolidate the legal text: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2847.

Who the CRA applies to

The regulation is aimed at anyone who introduces products with digital elements into the EU market, i.e. manufacturers, importers, distributors and authorized representatives.

As a rule of thumb, if your company logo is on the casing, you are liable to implement the Cyber Resilience Act for the specific product. If your company only manufacturers OEM components that are put together by a third-party, you may be not liable directly. However, in this case you will be asked to provide documentation, SBOMs and other security relevant information by your customers. Being prepared gives you a huge edge over competitors.

Product categories

Products are basically split into three categories: products with digital elements, important products and critical products. Depending on the security impact, assessment may be carried out by yourself or a third-party notified body.

Category	Example	Full List	Assessment
Products with digital elements	Smart toys, fridges, wearables, non-critical industrial controllers	Anything not listed in Annex III or IV	self assessment is possible
Important product (Annex III, Class I/II)	network management, firewalls, operating systems	https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#anx_III	formal security evaluation is sometimes required
Critical product (Annex IV)	hardware security modules, root DNS/CA servers	https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#anx_IV	formal security evaluation is required

Implications

Manufacturer obligations

The manufacturer is required to perform a cybersecurity risk assessment during the full product life cycle. This includes the inspection of third-party components which are integrated with the final product.

Furthermore, the manufacturer must determine a support period for the expected product lifetime, where upcoming vulnerabilities are handled effectively. The support period is typically at least 5 years, unless the device’s lifetime is shorter. Both technical documentation and security updates must be available and remain downloadable for at least 10 years. If the support period exceeds 10 years, this longer period applies. Security updates must be free of charge and be released as soon as possible, not bundled into future release cycles. Importantly, the support period must be provided clearly and understandably at the time of purchase.

Reporting obligations

As soon as an actively exploited vulnerability is found, the manufacturer is obligated to report an early warning within 24 hours to the Computer Security Incident Response Team (CSIRT) of the EU member state the company mainly operates and the ENISA (the EU Agency for Cybersecurity). Then a full notification has to be reported within 72 hours, where all known technical details must be provided.

A final report must be submitted no later than 14 days after corrective measure is available. For severe incidents, this deadline extends to one month from the 72 hour notification.

Essential Cybersecurity Requirements

The Cyber Resilience Act covers a basic set of requirements, that must be met. See https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#anx_I for a full list.

All the points below should be implemented with a security-by-design approach and should not be an afterthought. Even if an incident occurs, the essential and basic functions of the device must be maintained, including measures against denial-of-service attacks.

Secure Defaults & Updates

Besides obviously releasing your products without known exploitable vulnerabilities, products must be shipped with a secure default configuration. For example, the device must not use a fixed default password. Instead, manufacturers must ensure that each device has a unique password and that this password is communicated to the customer. Upcoming vulnerabilities must be addressed through security updates. Where applicable, those security updates should be rolled out via automatic updates and installed within an appropriate time frame. Furthermore, an mechanisms to temporarily postpone or disable automatic updates must be provided clear and easy to use. The user still needs to be notified of available updates.

Testing requirements

Effective and regular tests must be carried out, together with reviews of the security of the product. This means that ad hoc testing is not enough. Tests must be performed systematically, ideally with automated hardware testing.

Data protection

The manufacturer must ensure the protection against unauthorized access to the devices. For example, authentication and access management must be established, together with reporting of unauthorized access.

Data collected and processed on the device must be minimal and limited to the necessary intended purpose. Relevant security events must be monitored and recorded, with an opt-out for users. Additionally, the user must be able to permanently and securely remove all data and settings, including data that has been transferred to another product or system.

The confidentiality and integrity of data stored and transmitted on devices must be protected. This may be done by encrypting relevant data at rest or in transit by state-of-the-art mechanisms. In practice, this means using TLS, SSH, VPNs or other mechanisms, carried over protocols like TCP, HTTP or MQTT.

As a practical example, we have implemented a tunnel for TCP over HTTP using WebSockets. A device connects via a normal HTTP request to a central relay, where connection with a destination server is established. From this point, both device and server can communicate via established protocols like SSH, but the underlying connection is routed over HTTP WebSockets. This allows for network traffic without opening unwanted ports. The device can be routed behind a NAT and doesn’t even need internet access, just a connection to the relay. Other solutions like using a VPN where devices cannot reach each other but connect to a central or distributed authority are also valid, granted they are configured correctly.

Attack surface reduction

Furthermore, all attack surfaces must be limited, for both software and hardware interfaces. For example USB ports can be disconnected, if they do not serve any purpose during regular operation.

Vulnerability handling requirements

Manufacturers are required to identify and document vulnerabilities. Specifically, a coordinated vulnerability disclosure policy must be enforced. This means introducing a documented process for receiving, evaluating and responding to vulnerability reports. To make it easy for users, you must provide a contact address for vulnerability reports, i.e., a dedicated email on your website or information with your shipped software.

After performing a security update, information must be disclosed and shared publicly. This includes a description of the vulnerability and information allowing users to determine the impact and severity of the vulnerability.

Software Bill of Material

To systematically uncover vulnerabilities, it’s required to be able to generate a software bill of material (SBOM) for CVE scanning, covering at least the top-level dependencies.

Multiple strategies are possible, depending on existing infrastructure. The cleanest solution is to generate an SBOM together with the software build pipeline. Here, exact dependencies are usually known. Using a declarative approach like nix-based systems or Yocto builds allow for fine control and SBOMs can be stored for later use. Alternatively, multiple projects like Trivy or Syft allow for scanning of images, containers or binary artifacts. This comes with the downside that some dependencies or versions may not be identified correctly or missed completely. Of course SBOMs can be collected and generated through multiple sources and aggregated, although this is not trivial either. Relying on a good build pipeline is usually the best option and is advantageous for reproducibility anyway.

Non-compliance

EU member states are responsible for implementing and enforcing the penalties. For non-compliance with the essential cybersecurity requirements fines may go up to 15 million EUR or 2.5% of global annual revenue, for non-compliance with obligations 10 million EUR or 2% of global annual revenue. Additionally, authorities can prohibit your product from being sold and order a recall.

Conclusion

The Cyber Resilience Act introduces strict, long term obligations that require manufacturers to rethink product design and maintenance for the whole product life cycle. While the requirements are strict, they are long overdue. Recent events have shown us the importance of a strong cyber resilience and the next big incident may be just around the corner.

The regulation emphasizes two key principles: security-by-design principles to prevent incidents in the first place, backed up by measures to report and patch exploited vulnerabilities. This effectively reduces the possibility of impact and scope, while improving information flow to affected users.