What the Cyber Resilience Act requires from manufacturers

Documentation, documentation, documentation (that’s actually better than it sounds)

Sarah Fluchs
9 min readMar 20, 2024

What is the Cyber Resilience Act?

The Cyber Resilience Act (CRA) will be the first regulation worldwide that defines security requirements for products as a market entry barrier, or less formally: without security, “products with digital elements” can no longer be offered in the EU from 2027.

The EU is not reinventing the wheel for this, but rather adding security as a new piece of the puzzle to the existing concept of the CE mark, which safety-relevant products such as sunglasses, children’s toys or pressure vessels already have to carry today. Until now, the CE mark covered requirements for a product’s safety, it’s new that it now contains security requirements — and that opens up a whole new category of products that will carry a CE mark in the future. (You can read about the basic mechanisms of the CE mark and how the CRA fits in here, and the significance of harmonized European standards for the CE mark here).

What is the current status of the legislation?

The EU’s Cyber Resilience Act (CRA) was passed by the EU Parliament on March 12 (517 votes in favor, 12 against, 78 abstentions). This came as a bit of a surprise, as it was rumored at the beginning of the year that the act might not be passed before the parliamentary elections in June 2024. Now all that is missing is the approval of the European Council, then the CRA can come into force.

Parliament and Council had already reached agreement on the content at the end of 2023 in the trilogue negotiations between the Commission (which presented the draft CRA in September 2022), Parliament and Council, so it is likely that the Council will approve the version now adopted in Parliament.

The version of the CRA adopted by Parliament on March 12, 2024 is publicly available; it is the first public update since the draft version of September 15, 2022 and most likely also the final version, pending “legal-linguistic finalization” — but this does not change the content.

When the CRA comes into force, it will apply immediately in all EU member states, because unlike for example NIS-2, the CRA is not a directive that must first be translated into national law by the member states, but a regulation. This means that after a transitional period of 36 months, the requirements of the CRA will apply to manufacturers of the affected products. With the CRA likely to come into force this year, this means that manufacturers will have to comply with the requirements from 2027.

So, now it’s getting interesting: Which products are affected and what are the requirements?

Affected products

The products generally affected are “products with digital elements (=software and hardware products and its remote data processing solutions) made available on the market, the intended purpose or reasonable foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network”.

Or, in short: all hardware and software that could have a data or network connection during use. Even shorter: everything that communicates digitally. That’s a lot of products.

The strictest requirements, above all the mandatory need to have the fulfillment of cybersecurity requirements checked by an external body (e.g. TÜVs), only apply to “important products with digital elements” and “critical products with digital elements”. These can be found in Annex III and IV of the CRA and cover three product types:

  1. Basic IT infrastructure: browsers, operating systems, routers, modems, switches, network and boot managers, network interfaces and virtualization infrastructure.
  2. Products with security functions: authentication systems, password managers, virus protection, VPN, SIEM, PKI, microcontrollers and other embedded systems with security functions, firewalls, IDS and IPS, smart home devices with security functions (e.g. door locking systems), smart meter gateways and hardware security modules such as smart cards and security boxes
  3. Products that can record personal information (of children) or health data: Toys and baby monitors with an internet connection, wearables with health functions and personal assistants.

The “important products” and “critical products” have been significantly reduced compared to the 2022 draft. Back then, the list was very long, including industrial control systems, robots, IIoT and microcontrollers.

Requirements

Essential requirements and harmonised standards

The essential requirements that the CRA places on products are listed in Annex I. They can be summarized as follows:

  1. Incident prevention & design principles: Design principles and (regular) measures to develop secure products by design. (The teeth-brushing of product development, so to speak).
  2. Incident readiness & resilience: Anything that helps to mitigate the effects if a vulnerability is found and exploited. (A tire stack, so to speak.)
  3. Incident & Vulnerability handling: The process that ensures that a security incident is professionally addressed and quickly resolved. (The fire hose, so to speak.)

Annex I is very short and the requirements are generic. This is intentional, as the concrete formulation of the requirements is to take place in so-called “harmonized standards”. These are currently being developed in the European standardization organizations CEN/CENELEC. Existing standards are to be used wherever possible. However, a horizontal standard that would be equally suitable for all products in the very broad area of application of the CRA does not yet exist.

The fulfillment of these “essential requirements” must be documented. The visible results that manufacturers must produce to comply with the CRA are three types of documentation:

EU declaration of conformity

The central documentation that must be available for products is the CE mark. This may be affixed if an “EU declaration of conformity” has been drawn up. This declaration of conformity is basically just a formal document that declares that the product conforms to the above mentioned “essential requirements”.

A declaration of conformity can be obtained through various procedures. Depending on the procedure, a third-party inspection may or may not be necessary.

The simplest way is module A / “internal control”. In this case, the manufacturer declares conformity with the “essential requirements” himself.

For third-party assessments, there are three options:

  • Module H: Examination on the basis of a quality management system
  • Module B+C: “EU-type examination” — an EU-appointed inspection body (e.g. TÜV, DEKRA, etc.) performs the examination.
  • Acquisition of a certificate in accordance with the EU Cybersecurity Certification Scheme.

The “important entities” and “critical entities” must undergo one of these third-party assessments in order to receive a declaration of conformity and thus the CE mark. For all others, a self-declaration is sufficient.

The declaration of conformity for the product must be supplied with the product or be publicly available.

Technical documentation

The technical documentation must contain all information that is necessary for conformity with the “essential requirements”, or in the words of the CRA: “all data and details of the means used to ensure conformity with essential requirements”.

More specifically, this means

  • a risk analysis that analyzes in particular the applicability of the essential requirements for the product (this prominent positioning of the risk analysis and the explicit linking of the risk analysis with the essential requirements is new compared to the 2022 version),
  • Design information that serves to document the “essential requirements Part I”; in particular system architecture drawings and interactions of system components,
  • Documentation of the vulnerability management process in accordance with “essential requirements Part II”; including SBOM,
  • Test reports from the conformity assessment procedure and a list of the harmonized standards applied.

(By the way, there is an international standard for creating technical documentation: EN IEC/IEEE 82079–1:2020.)

The technical documentation must be created for every product that falls under the CRA — regardless of whether it is “important”, “critical” or not.

The technical documentation is not public; after all, it contains potentially sensitive information. However, the market surveillance authority — in Germany this will probably be the BSI or BNetzA — can request access to the technical documentation in justified cases. Such a case would be conceivable, for example, if the exploitation of a vulnerability for a specific product becomes known.

Information & instructions to the user

The “information & instructions to the user” should enable the user to actually operate the product securely.

To this end, the product’s intended use and the essential functions are to be described, as well as the security features of the product. In addition, the user should be warned which types of use or modification of the product are risky from a security perspective and what measures they need in order to use the product securely: What needs to be configured during commissioning? How can security updates be installed?

Like the technical documentation, the user manual must be created for every product that falls under the CRA — regardless of whether it is “important”, “critical” or not.

In contrast to the technical documentation, however, the user instructions must be delivered with the product. In a sense, it is the product’s “security business card” showing its users how much thought the manufacturer has invested into the product’s security. The user instructions are therefore perhaps the biggest new feature due to the CRA that users will notice; especially for B2B products.

Summary

Finally, here are all requirements to be met and documents to be created at a glance:

Now what?

There has been a lot of fuss and speculation recently about the “important” and “critical” products, as many manufacturers wanted to avoid the conformity assessment procedure involving third parties. With success: this list is now much shorter and the majority of those affected will probably only have to draw up a self-declaration in 2027.

However, the “essential requirements” must be fulfilled by every manufacturer of networked products, whether they appear in Annexes III and IV or not. And the three types of documentation — conformity declaration, technical documentation, information & instructions to the user — must also be created by everyone.

This is quite a lot of documentation to be drawn up, which is particularly worrying for small companies. The CRA therefore promises that the EU will provide simplified formats as well as assistance for this documentation for small and medium-sized enterprises.

But in fact, what on the surface looks like tedious documentation actually requires thought processes that really do lead to better security and make perfect sense regardless of CRA regulation:

Thinking about intended functions, documentation of those functions, foreseeable misuse of those functions, a risk analysis? If you do this well, you as a manufacturer will get ahead of things to decide which security measures are actually necessary.

A vulnerability management process, instructions to the user on what they need to consider for secure use? If you do this well, as a manufacturer you will make your customers, who are increasingly concerned about security, very happy.

Also, you don’t have to wait for the release of the harmonized standards (which probably won’t be ready before 2025 anyway) to start taking these steps.

As a manufacturer, you can moan about the CRA — but it’s coming anyway. Then you might as well see it as an opportunity to finally tackle the annoying security issue in a structured way, right? The good news is that the required documentation offers both the right incentives and the freedom to do a really good job of communicating the security of your products — and thus stand out from the competition.

--

--

Sarah Fluchs

Friction generates heat — true for writing and engineering. Fluchsfriction generates writings on security engineering. Heated debates welcome! CTO@admeritia