Skip to content

Embedded Devices Covered by EU Cyber Resilience Act (CRA)

Which devices are covered by the EU Cyber Resilience Act (EU CRA)?

  • An X-ray fluorescence (XRF) analyser connected with the Internet over WiFi.
  • A metal-sheet bending machine with an Ethernet port, which will only be used in the future.
  • The harvester ECUs connected over CAN bus.
  • A camera trap without any connectivity, where updates and photos are exchanged via SD card.
  • A full-body 3D X-ray scanner used by doctors.

The first four devices fall under the EU CRA. The fifth device doesn’t, because specific and stricter regulations exist for medical devices. In short, pretty much all embedded devices are covered by the EU Cyber Resilience Act (EU CRA) – unless stricter industry-specific regulations exist already

Products with Digital Elements

This Regulation applies to products with digital elements made available on the market, the intended purpose or reasonably foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network.

EU CRA, Article 2(1)

The XRF analyser has a physical data connection over WiFi with a network. The bending machine doesn’t have a physical data connection at the moment, but it will have one in the foreseeable future. The harvester ECUs are connected to a network via CAN bus. It doesn’t matter whether any of the ECUs is connected to the Internet. Updating one ECU over CAN or from a USB drive with malicious software can affect the other ECUs. Similarly, an attacker could introduce malicious software into a firmware image stored on the SD card of the camera trap. The next camera update would activate the attack. The camera trap has a logical but not a physical connection to other devices.

The X-ray scanner does not fall under the EU CRA, because specific regulation exists that “achieves the same or a higher level of protection as that provided [by the EU CRA]” (Article 2(5b)). Article 2 lists several PDEs that have their own stricter regulations:

These products must satisfy even stricter regulations than those set by the EU CRA.

(1)  ‘product with digital elements’ means a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately;
(2) ‘remote data processing’ means data processing at a distance the software for which is designed and developed by the manufacturer, or under the responsibility of the manufacturer, and the absence of which would prevent the product with digital elements from performing one of its functions;

EU CRA, Article 3(1) and 3(2)

Products with digital elements (PDEs) comprise a lot more products than just embedded devices. Every application running on a PC, laptop, phone or tablet must comply with the EU CRA. Operating systems, bootloaders, password managers, network managers, VPN, hypervisors and web browsers are further examples for software under the EU CRA. Hardware examples include microprocessors, microcontrollers, SoCs, SoMs, ASICs, routers, and modems. It is hard to find any software or hardware product that doesn’t have to comply with the EU CRA.

Critical, Important and Default Products

In short, all manufacturers of PDEs must comply at least with the EU CRA. Depending on the category, PDEs must prove compliance with the essential requirements of Annex I in different ways. PDEs are divided into three categories: critical, important and default PDEs. When a product passes the applicable assessment, the manufacturer receives a CE marking for cybersecurity (Article 30). CE markings prove the conformity (the “C” in CE) with European (the “E” in CE) regulations.

PDEs are ranked by their security risk and the potential damage resulting from exploiting a vulnerability. Critical PDEs have the highest risk followed by Class-II and class-I important PDEs. Default PDEs have the lowest risk.

  • Critical PDEs (Article 8 and Annex IV):
    • Hardware devices with security boxes.
    • smart meter gateways and other devices for advanced security purposes
    • smartcards or similar devices including secure elements (e.g., hardware-security modules).
  • Important PDEs (Article 7 and Annex III)
    • Class II:
      • hypervisors and container runtimes
      • firewalls, intrusion detection and prevention systems
      • tamper-resistant microprocessors and microcontrollers.
    • Class I:
      • Identity and privileged access management software and hardware (e.g., access control readers)
      • standalone and embedded browsers (e.g., WebKit, Chromium)
      • password managers
      • software searching for, removing and quarantining malicious software (e.g., BitDefender, CrowdStrike)
      • VPNs
      • network management systems
      • security information and event management (SIEM) systems
      • boot managers (e.g., U-Boot, GRUB)
      • public key infrastructure (PKI) and digital certificate issuance software
      • physical and virtual network interfaces
      • operating systems
      • routers, modems and switches
      • microprocessors, microcontrollers and FGPAs with security-related functionalities
      • virtual smart home assistants (e.g., Alexa, Siri)
      • smart home products with security functionalities including smart door locks, security cameras, baby monitoring systems and alarm systems
      • Internet connected toys
      • Personal wearable products for health monitoring or for use by children
  • Default PDEs (Article 6)
    • All other PDEs that are neither critical nor important PDEs.

Annex III and Annex IV list the important and critical products explicitly. The EU Commission can add products to or remove products from these lists. It has done so since the proposal in 2022 (see the section Covered Products in my newsletter from November 2023). For example, general-purpose processors and industrial IoT devices were in class II of the proposal. Microprocessors must now be tamper-resistant to be in class II or contain security-related functionality to be in class I. Industrial IoT devices were moved into the default class.

If a product integrates a class-I or class-II PDE but not as its core functionality, it does not automatically become a class-I or class-II product (Article 7(2), Sentence 2). The operator terminal of a machine doesn’t become an important PDE, because it runs its main applications (including an embedded web browser for the documentation) in a Docker container on an embedded Linux system. The same goes for the whole machine.

Article 32(1) defines the conformity assessment procedures (CAPs) available to manufacturers.

  • (CAP1) Internal control procedure (module A defined in Part I of Annex VIII).
    Manufacturers conduct a self-assessment how they comply with the essential requirements of Annex I and document their methods in the technical documentation following Annex VII: how they build security into their products, how they monitor and fix vulnerabilities, and how they notify the authorities about these vulnerabilities. They declare that they are solely responsible for the cybersecurity of their products.
  • (CAP2) EU-type examination procedure (module B defined in Part II of Annex VIII) and internal production control (module C defined in Part III of Annex VIII).
    Manufacturers must provide the technical documentation according to Annex VII and supporting evidence (e.g., results of tests carried out by appropriate labs, reasons for deviating from existing standards). Based on this information, a notified body (e.g., the TÜV) shall examine the compliance with the essential requirements. The notified body can run its own tests on the products or inspect the products.
  • (CAP3) Conformity assessment based on full quality assurance (module H defined in part IV of Annex VIII).
    Manufacturers must set up a quality system (§3) to ensure compliance with the essential requirements. Manufacturers must execute and document tests, inspection and reviews from design over development to production. They must set up repeatable processes and assign clear responsibilities. When possible, manufacturers follow existing standards. Based on the technical documentation, the notified body evaluates whether the quality system ensures the essential requirements. It also performs an audit on the manufacturers’ premises.
  • (CAP4) European cybersecurity certification scheme (defined in Article 27(9)).
    In contrast to CAP3, manufacturers don’t have to create their own quality system, but they use a quality system or certification scheme provided by EU authorities. Manufacturers must demonstrate that their implementation of the certification scheme achieves an assurance level of at least “substantial”. Manufacturers don’t have to involve a notified body or any other third part to carry out the conformity assessment. The certification schemes are not defined in the EU CRA but in separate acts – so-called delegated acts.

Manufacturers shouldn’t regard the conformity assessment as a necessary evil dictated by the bureaucratic monster in Brussels. Implementing the essential requirements makes their products harder to hack and more competitive. If this is not enough motivation to up their game, the damage to their brand and the serious penalties should be. One disgruntled ex-employee or begrudging competitor is all it takes to get them in trouble.

The next list shows, which conformity assessment procedures apply to which product categories. Each CAP demonstrates how the PDE complies with the essential requirements of Annex I (see section Essential Security Requirements of my newsletter from November 2023). The higher the cybersecurity risk is the more elaborate the assessment procedure is. The list is ranked from the lowest to the highest risk.

  • Manufacturers can use CAP1 for default PDEs (see Article 32(1a)).
  • Manufacturers can choose CAP2 or CAP3 for important class-I PDEs (see Article 32(2)).
  • If a European cybersecurity certification scheme is available and applicable, manufacturers of important class-II PDEs must apply CAP4 and prove at least assurance level “substantial” for their products. Otherwise, they can choose freely between CAP2 and CAP3 (see Article 32(3)).
  • If a delegated act defines a cybersecurity certification scheme for critical PDEs, manufactures must follow this act. This delegated act may require a higher assurance level than “substantial”. If such a delegated act doesn’t exist, the rules for important class-II PDEs apply (see Article 32(4)).

Although a lot of free and open-source software (FOSS) like Linux, Docker containers, Chromium, WebKit and openssh is an important PDE, its manufacturers don’t have to perform the same onerous assessments according to CAP2 or CAP3. Article 32(5) allows FOSS manufacturers to perform a self-assessment according to CAP1 – no matter whether the software is a critical or important PDE.

Important Dates

Or: When do things get serious for new and legacy products?

Here is a summary of the important dates.

  • Effective date – 11 December 2024: The EU CRA enters into force.
  • Notification date – 11 September 2026 (21 months after effective date): Manufactures must notify the relevant authorities about exploitable and severe vulnerabilities.
  • Penalty date – 11 December 2027 (36 months after effective date): The EU may charge manufacturers with penalties for violations of the EU CRA.

The EU commission adopted the EU CRA on 10 October 2024. The EU CRA was published in the Official Journal of the EU on 20 November 2024 and enters into force 20 days after its publication (Article 71(1)) – on 11 December 2024, the effective date.

Manufacturers must comply with all obligations of the EU CRA for products they place on the EU market after the penalty date, 11 December 2027 (Article 71(2)). From then on, the EU can charge manufacturers with heavy penalties for violations. Manufacturers should use the three years from the effective to the penalty date (the transitional period) to implement the required processes and to practice them day in and day out.

If manufacturers have placed products on the market before the penalty date and have released “substantial modifications” after the penalty date, these legacy products fall under the EU CRA as well. Products are excluded from the EU CRA, if they only receive bug fixes after the penalty date (Article 69(2)). Even if a product was released in 2019 and still receives functional updates in 2028, the manufacturer must fully satisfy the EU CRA.

There is another important date: the notification date. From 11 September 2026 , manufacturers must notify the relevant authorities – both ENISA and CSIRT – about “any actively exploited vulnerability contained in the [PDE]” (Article 14(1)) and about “any severe incident having an impact on the security of the [PDE]” (Article 14(3)) via a single reporting platform. The relevant authorities are the EU-wide ENISA (European Union Agency for Cybersecurity) and the national CSIRTs (computer security incident response teams). ENISA is also responsible for establishing the reporting platform.

Support Period

The introductory paragraph §61 requires the support period of products to be at least five years or as long as the typical lifetime of the product. In rare cases, the lifetime can be shorter than five years. The example for such an exception is a contact tracing app for the Corona virus, where support is required only for the duration of the pandemic.

The typical lifetime of construction, agricultural and industrial machines is at least 15 years. Owners typically use the machines for 15 or more years. When determining the support period, manufacturers must take into account the typical lifetime of the machines, the expectation of the users and the nature of the machines (§60). Manufacturers cannot arbitrarily set the support period to five years to avoid compliance with the EU CRA for the remaining ten years in use.

When customers buy a product, they must be aware when the support for their product ends. Putting the end date for support in the fine print is not good enough. If a product has a user interface, manufacturers should use it to notify their users about the end of the support (§57).

When products have reached the end of support, the EU CRA has an interesting suggestion (§62). The manufactures should consider to release the source code of the product to another organisation willing to perform security updates. Alternatively, they could publish the source code so that users can fix security issues themselves.

Tags:

Leave a Reply

Your email address will not be published. Required fields are marked *