The EU Cyber Resilience Act: Manufacturer Perspective
Episode 47: Better Built By Burkhard
The EU Cyber Resilience Act
Reasons and Objectives
The EU has a pretty good reason to introduce the Cyber Resilience Act (CRA):
Hardware and software products are increasingly subject to successful cyberattacks, leading to an estimated global annual cost of cybercrime of EUR 5.5 trillion by 2021.
[EU-CRA, p. 1]
The authors of the EU CRA state two major problems causing these damages:
Many “products with digital elements” have little or no protection against cyber attacks and little or no support for timely security updates.
Neither consumers nor businesses have sufficient information to choose products with good cybersecurity over those with bad cybersecurity.
The following examples bear out the authors problem analysis.
From remote, two hackers took control of the accelerator, brakes and steering wheel of a Jeep and eventually “parked” the car on the shoulder off the road. Fortunately, the driver knew what was happening, as this was a demonstration of what is possible. As I know first-hand, the security of agricultural, construction and industrial machines is in worse state than the security of cars.
Although never confirmed officially, the USA and Israel destroyed roughly one fifth of the Iranian centrifuges for uranium enrichment with the Stuxnet worm. They targeted Windows 7 computers that were in the same network as Siemens PLCs. The worm accelerated the centrifuges until they tore apart. Similar attacks are possible on many SCADA systems and PLCs.
Ransomware and supply chain attacks shutting down city administrations, businesses and power plants have become normal. The wars in Ukraine and Israel and the economic power struggle between the US and China will intensify such attacks. So, it is high time for the EU to take action. The EU CRA defines two main objectives:
Manufacturer Perspective. Manufacturers must ensure that their products are secure over the whole product lifecycle. They must deliver products without any known exploitable vulnerabilities and must fix the vulnerabilities with security updates in a timely fashion. Products must adhere to the essential cybersecurity requirements, which define very clearly what constitutes a secure product. Manufacturers must provide detailed documentation about vulnerabilities and how to handle them.
User Perspective. Private and business users must be able to assess the level of cybersecurity risk of a product easily and quickly. Official bodies monitor the compliance with the EU CRA. User and official bodies can only assess the risks properly and react to them, if manufacturers provide the up-to-date information in a timely fashion.
As a system architect and lead developer, I help manufacturers build their products. I don’t work with the users of these products, let alone with official bodies. Hence, I’ll focus on the manufacturer perspective in this newsletter.
Covered Products
This Regulation applies to products with digital elements whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. [EU-CRA, Article 2(1)]
[Whereby]
‘product with digital elements’ means any software or hardware product and its remote data processing solutions […]; [EU-CRA, Article 3(1)]
‘remote data processing’ means any data processing at a distance for which the software is designed and developed by the manufacturer […], and the absence of which would prevent the product with digital elements from performing one of its functions; [EU-CRA, Article 3(2)]
Any embedded device communicating with the cloud or with other embedded devices is regulated by the EU CRA. This means any embedded device. As soon as you can get data on or off a device, this is enough for a cyber attack. A USB drive was enough to infect the Iranian centrifuges with the Stuxnet worm.
Of course, the EU CRA is not limited to embedded devices but also covers pure software products like password managers, web browsers and remote access software (e.g., VNC, TeamViewer).
[EU CRA-Annex III] groups products into uncritical, class I (critical) and class II (highly critical) products.
Examples for Class II products: operating systems for servers, desktops and mobile devices; hypervisors and container runtime systems; public key infrastructure; general purpose microprocessors; secure elements; smartcards and their readers; industrial IoT devices and industrial automation & control systems (IACSs) used by essential entities; robot sensors, actuators and controllers; many more.
Examples for Class I products: web browsers; VPNs; update, patch and boot managers; remote access/sharing software; physical network interfaces; operating systems, microprocessors, IACSs and industrial IoT devices not covered by class II; routers and modems; firewalls; many more.
Examples for uncritical products: photo editors; word processors; games; all products neither in class I nor in class II.
Any products that contain class I or class II products are considered critical products [EU-CRA, Article 6(1)]. For all three categories, manufacturers must demonstrate that their products conform with the essential cybersecurity requirements of [EU-CRA-Annex I]. For uncritical products, a self-assessment is enough. Manufacturers of class-I products perform the assessment according to an approved standard or hire a an approved third party like the TÜV to do the assessment. For class-II products, a third-party assessment is mandatory (see [EU-CRA, Article 24] and [EU-CRA-Annex VI]).
Essential entities are defined in Annex 1 of the NIS2 directive as entities operating in sectors like energy, transport, finance, water, digital infrastructure (e.g., cloud providers, DNS) and space. So, the devices I am typically building - HMIs for agricultural, construction and industrial machines - belong to class I.
Obligations of Manufacturers
[EU-CRA, Chapter II] defines the obligations of manufacturers (Article 10), importers (Article 13) and distributors (Article 14). Manufacturers are first and foremost responsible for satisfying the essential cybersecurity requirements and for handling vulnerabilities correctly. However, importers and distributors must check that manufacturers adhere to their obligations. They can be held liable for manufacturers violating their obligations.
As I work with manufacturers only, I’ll focus on their duties.
When placing a product with digital elements on the market, manufacturers shall ensure that it has been designed, developed and produced in accordance with the essential requirements set out in Section 1 of Annex I. [EU-CRA, Article 10(1)].
When placing a product with digital elements on the market, and for the expected product lifetime or for a period of five years from the placing of the product on the market, whichever is shorter, manufacturers shall ensure that vulnerabilities of that product are handled effectively and in accordance with the essential requirements set out in Section 2 of Annex I. [EU-CRA, Article 10(6)]
Essential Cybersecurity Requirements
Manufacturers must provide a risk assessment how well their products conform to the essential cybersecurity requirements listed in Section 1 of [EU-CRA-Annex 1]. Quite surprising for an EU regulation, the requirements are very practical and reasonable for embedded devices.
Let me paraphrase and comment on the points from section 1 of [EU-CRA-Annex I], while preserving their numbering.
Products must satisfy the essential requirements for their whole lifecycle: from the idea over design, development, testing and production to their end.
Products “shall be delivered without any known exploitable vulnerabilities”. Now that’s a huge step for many manufacturers.
If applicable - and they are except for some pretty esoteric cases, the following requirements are mandatory for products with digital elements and especially for embedded devices.
Products shall be delivered with a configuration that is secure by default - that is a configuration satisfying the other points. Users can reset the product to this secure configuration.
Users must not gain unauthorised access to the product. Say good bye to the same password for all devices - even if you change it every 6 months.
Sensitive data stored on the product must be encrypted. Data transfer to and from the product (e.g., with the cloud) must be encrypted, too. This would also apply to data transferred over the CAN busses of agricultural and construction machines. I still have to meet a manufacturer who does that.
If the product receives, sends or stores data, it must be sure that the data hasn’t been manipulated. The product must guarantee the integrity of the data - normally by signing code and data.
The product should only process data that it really needs for its work (“minimisation of data”).
Even if the product is under attack, its essential functions must still work. For example, the brakes of a tractor must work even under a heavy denial of service attack.
Even if the security of a product was breached, the negative impact on other devices and services must be minimised.
The product shall be “designed, developed and produced to limit attack surfaces, including external interfaces”. So, turn up the compiler warnings and run static analysers and sanitisers on your code to avoid undefined behaviour, memory leaks, thread issues and more in your C and C++ programs (see Phillip Johnston’s article Leveraging Your Toolchain to Improve Security).
The product shall be built so that it can mitigate (known) security incidents. The product knows how to deal with code injection, privilege escalation, memory manipulation and other attack techniques.
The product monitors and records “the access to or modification of data, services or functions”. A trusted execution environment, for example, would monitor all function calls into the secure world and even forbid them if necessary.
If a fix for a vulnerability is available, the product can automatically perform an update or at least notify the users about its availability. So, OTA updates for embedded devices will be a must.
Handling of Vulnerabilities
Essential requirement (2) demands that products must be delivered without any known vulnerabilities. Section 2 of [EU-CRA-Annex 1] defines how manufacturers must handle the vulnerabilities that will inevitably occur during the lifetime of a product.
Let me paraphrase and comment on the points from section 2 of [EU-CRA-Annex I], while preserving their numbering.
Manufacturers must identify the vulnerability in each component of the product (e.g., in each package of an embedded Linux system) and document them in a software bill of materials SBoM (see Sergio Prado’s excellent article Introduction to SBOM management on embedded Linux).
Manufacturers shall remedy the identified vulnerabilities “without delay, including by providing security updates”. The vulnerabilities are ranked by their risk, which is determined by the severity, damage, occurrence probability and other factors.
Manufacturers must test and review the security of their products regularly. They should automate the tests and reviews as much as possible and integrate them in their CI/CD pipelines.
Once a security update is available, manufacturers shall publish which vulnerabilities are fixed and what the risk (severity, impact, likelihood, etc.) of the vulnerabilities is. Users shall be able to identify the products affected and to decide if and what they must do about the vulnerabilities.
Manufacturers shall coordinate the disclosure of vulnerabilities with all parties involved in finding and fixing vulnerabilities.
Manufacturers shall make it easy to share vulnerabilities in their products including a contact address for reporting vulnerabilities.
Manufacturers must deploy security updates to their products in a timely manner. They can best achieve this by OTA updates.
Manufacturers shall distribute security updates free of charge to users.
Penalties for Violations
As with GDPR, the penalties for violating the EU CRA are draconian. [EU-CRA, Article 53] sets out the penalties. Violating the rules laid down in [EU-CRA-Annex I] - essential cybersecurity requirements and handling of vulnerabilities - is subject to fines of up to €15,000,000 or 2.5% of a company’s worldwide annual sales, whichever is higher (see [EU-CRA, Article 53(3)]). So, manufacturers should better get their act together and start taking security seriously.
Timeline
The EU cybersecurity resilience act is still in the proposal stage. The European Parliament and the European Council still have to adopt the proposal. The EU CRA will probably enter into force in 2024. Then, manufacturers, importers, distributors and the EU member states have two years to adapt to the new regulations. From 2026, the EU can and will dole out the hefty fines. One year after the the entry into force (probably 2025), manufacturers must start reporting security incidents to the authorities.
My Experience and an Outlook
Over the last 10 years, I worked with roughly 30 manufacturers. One manufacturer had implemented OTA updates and secure boot. I am just implementing OTA updates, secure boot and disk encryption for another manufacturer. The other 28 or so manufacturers were and most likely still are in blatant violation of the EU CRA.
I have encountered unencrypted data transfers from the machine to the cloud, the use of the same 4-digit password for all machines changed every six months, unprotected access to the CAN busses, the main application running as root and much more - not only once but many times. I still have to see a company creating an SBoM. Even worse, these manufacturers don’t see the need to spend even a little time on closing the most glaring security holes.
I think that even the bigger manufacturers will struggle to get their products ready for the EU CRA in 2026. They are certainly used to comply with all kinds of regulations and they have enough people for compliance tasks. However, they lack the people with the expertise to implement the essential security requirements for their products. The big companies will have enough money to hire these people or somehow hack together a DIY solution that will help them avoid any penalties.
I reckon that most small and medium companies (SMBs) will be fairly unprepared in 2026. Then, it will be too late to find the right people, because they will be busy helping the big companies. The best hope for SMBs are probably companies who check the compliance of embedded systems as a service (see Foundries.io helps Arduino SoM meet EU security straight out-of-the-box). But, this service will cost good money!
Question to you, dear reader: How well do your customers comply with the essential cybersecurity requirements?
References
[EU-CRA] EU Cyber Resilience Act (Proposal): Proposal for a Regulation of the European Parliament and of the Council on horizontal cybersecurity requirements for products with digital elements and amending Regulation (EU) 2019/1020.
[EU-CRA-Annex] Annexes to the EU Cyber Resilience Act (Proposal), Annexes to the Proposal for a Regulation of the European Parliament and of the Council on horizontal cybersecurity requirements for products with digital elements and amending Regulation (EU) 2019/1020.
Carsten Rhod Gregersen: EU Cyber Resilience Act: the GDPR for IoT; embedded.com. A short summary of the EU CRA.
Kir Nuthi: An Overview of the EU’s Cyber Resilience Act; Center for Data Innovation. Another but slightly longer summary of the EU CRA.