Background

The CRA is the centerpiece of the latest European cybersecurity legislative package. It complements existing, predominately sector-specific legislations, such as the Second Network and Information Security Directive (“NIS2”), the Critical Entities Resilience Directive (“CER”), the Cyber Security Act (“CSA”) or the Digital Operational Resilience Act (“DORA”). Its scope also partly overlaps with the Radio Equipment Directive Delegated Act (“RED Delegated Act”) relating to internet-connected radio equipment.

The CRA marks a turning point for the cybersecurity of both consumer and industrial products in Europe. Compared to existing frameworks, it aims to regulate product security at the supplier level, imposing obligations on manufacturers, importers and distributors.

Following the Commission’s proposal in September 2022 (see our previous articles of 25 April 2022 and 4 October 2022; for a UK perspective, please see our article of 28 March 2023) and Council and Parliament’s position in July earlier this year, trilogue negotiations have been ongoing since September. A political agreement now appears to be within reach, with the trilogue expected to conclude at the end of this month.

Overview on the Draft CRA

The CRA introduces a comprehensive set of obligations for manufacturers, importers and distributors of “products with digital elements”. The notion of “products with digital elements” covers most software and hardware products and their remote data processing solutions, ranging from standard software solutions (e.g. text and photo editing software, games, operating systems) to IoT products (e.g. home automation devices, smart toys, routers). The decisive factor is that the foreseeable use of the product with digital elements is its connection to other devices or a network. While complex in nature, the regulation can be broken down into three key pillars:

Mandatory CE marking for products with digital components

• The CRA places products with digital elements under the existing CE (Conformité Européenne) mark framework. This triggers a number of market release obligations defined by the criticality category of a product (Non-Critical, Critical Class I and Critical Class II), which must be determined during the development phase.
• To obtain a CE mark, the product must pass a mandatory conformity assessment against the requirements of the CRA. This assessment can be carried out internally for “Non-Critical” products or, in the case of a "Critical Class II" or “Highly Critical” products, externally by an independent "Notified Body". Where “Critical Class I” products are concerned it depends on the use of “Harmonised Standards” whether the internal assessment procedure is available or whether the assessment must go through a “Notified Body". There is also the possibility for products of all categories to be assessed based on a (yet to be adopted) European cybersecurity certification scheme under the CSA. The use of Harmonised Standards or a European cybersecurity certification scheme will come with the benefit of a presumption of compliance with the requirements of the CRA. It is currently expected that most products (~90%) will fall into the "Non-Critical" category where an internal assessment will suffice. The CE marking process is completed by issuing an EU Declaration of Conformity for the product and affixing the CE mark.
• The CRA coordinates the conformity assessment procedures in case a product with digital elements is also classified as a high-risk AI system under the AI Act.

Compliance obligations during product development and after product release

• The CRA’s security requirements must be considered at all stages of product development (“security by default”). This includes ongoing risk assessments and management of product vulnerabilities. The compliance measures taken must be thoroughly documented.
• The CRA introduces a “cybersecurity support period” during which the manufacturer has to handle vulnerabilities of the product effectively. This includes, for example, security updates, ongoing monitoring of the product's compliance with the CRA, and maintaining a single point of contact for customers for the reporting of vulnerabilities.
• The CRA sets out mandatory information as well as instructions that must be provided to the customer, either physically or digitally.

Notification obligations for product vulnerabilities and cybersecurity incidents

• During the cybersecurity support period, both a vulnerability management system and a cyber incident response system must be maintained. The CRA provides for strict reporting obligations to either the European Union Agency for Cyber Security ("ENISA"), the National Computer Security Incident Response Teams ("CRITs"), or both (see below for details).
• The existing CRA drafts provide for a very short initial notification period of 24 hours after becoming aware of the incident. This deadline would even fall significantly short of the challenging deadline of 72 hours for reporting personal data breaches under the GDPR. Depending on the incident, public notification of customers may also be required.

The CRA will be enforced by “market surveillance authorities” (to be established by EU Member States), with fines ranging from 1% to 2,5% of the company's global annual turnover. This range of fines follows the European trend of enforcement through severe sanctions, such as those introduced in the GDPR and DSA.

Status Quo of the Trilogue Negotiations

EU lawmakers are currently negotiating a final political agreement on the CRA. The trilogue began on 27 September 2023, and the last meeting was held earlier this month on the 8 November 2023. While a lot of common ground seems to have been found, some key aspects of the regulation remain controversial. The following three aspects were at the centre of the discussion at the last trilogue meeting.

Notification obligations for vulnerabilities and security incidents

A common position on CRA reporting requirements has not yet been found. Legislators have been unable to reach a consensus on which body should be notified in case of an actively exploited vulnerability or a cybersecurity incident: The ENISA, the CRITs, or both? This question is of particular importance, given the sensitive nature of the information included in the notification.

There is also a lack of clarity about the scope of the reporting obligations. Prior to the start of the trilogue, it was rumoured that these obligations might be limited to serious cases, i.e. actively exploited product vulnerabilities, excluding failed attempts and security incidents with severe impact. Such a limitation would provide significant relief to companies during the cybersecurity support period.

Criticality categories of products

Apart from the ongoing debate on the naming of the product categories ("critical" or "impactful"), the discussion focused on the method for determining the criticality of a product and the list of critical products in Annex II. This list may be updated in the future by delegated or implementing acts (to be determined) of the Commission. Part of the proposed actions to regulate highly critical products was to require mandatory safety certification under an existing or yet to be defined framework.

Cybersecurity support period after product release

Finally, no agreement has yet been reached on the cybersecurity support period after a product has been placed on the market. The Council stipulated the expected lifetime as relevant period. Parliament argued for a minimum period of 5 years, unless the lifetime of a product is shorter. Notably, a proportionality approach now seems to have found its way into the determination of the support period, which could prevent extensive support obligations after the release of a product.

What’s Next?

A final agreement on the CRA between EU lawmakers is expected at the next trilogue meeting on 30 November. This finalisation would fit neatly into the original timetable, with a planned vote on the CRA in March 2024 and ratification before the Parliament elections in June 2024.

The application period of the CRA is still to be determined. While the Commission’s proposal suggested an application period of 24 months, the positions of Parliament and Council envisaged a longer period of 36 months. The legislators' stance on the application of the notification obligations are even further apart, ranging from 12 months (Commission) and 18 months (Council) to 24 months (Parliament).

In any event, it is required to monitor the development on the legislative progress on the CRA framework. We will continue reporting on the development of the CRA to support our clients in organising their development and market release practices accordingly.

*a paralegal in our Hamburg office, contributed to the drafting of this article.