EU institutions finalise agreement on cybersecurity law for connected products

European Union policymakers reached a political deal on the Cyber Resilience Act on Thursday evening (30 November), bridging their differences on the last outstanding issues.

The Cyber Resilience Act is a legislative proposal to introduce security requirements for connected devices, from smart toys to industrial machinery. The EU Commission, Parliament and Council arranged the law’s final disposition in a so-called ‘trilogue’ meeting.

As Euractiv anticipated, the agreement was largely pre-cooked at the technical level, with many aspects of the proposal being endorsed during the political meeting. However, EU negotiators settled the last political hurdles after some intense discussions.

“The Cyber Resilience Act will strengthen the cybersecurity of connected products, tackling vulnerabilities in hardware and software, making the EU a safer and more resilient continent. The Parliament has protected supply chains, ensuring that key products such as routers and antiviruses are identified as a priority for cybersecurity,” leading MEP Nicola Danti told Euractiv.

Vulnerability handling

Manufacturers of connected devices will no longer be able to launch products on the market if they know of significant vulnerabilities that can be hacked. Instead, they will have to handle these potential entry points as soon as they become aware of them throughout a predetermined support period.

Whenever manufacturers become aware of a security incident or a vulnerability being actively exploited, they must report it and inform the competent authorities of their actions to mitigate the security risk.

Actively exploited vulnerabilities are an extremely sensitive type of cyber threat intelligence since the entry point for hackers is still to be patched. Therefore, who should handle this sensitive information was a sticking point in the negotiations.

The EU Council of Ministers moved this task from ENISA, the EU cybersecurity agency, to the national computer security incident response team (CSIRTs), that have a similar task under the revised Networks and Information Systems Directive (NIS2).

At the same time, the European Parliament insisted on keeping ENISA in the loop and to avoid giving national authorities too much discretion in keeping this highly sensitive information for themselves.

The compromise was found in the notification sent simultaneously from the manufacturers to the competent CSIRT and ENISA via a single reporting platform. However, EU countries pushed the idea that they should be able to restrict the information sent to ENISA on cybersecurity grounds.

The conditions for such restrictions were the object of intense discussions, resulting in rather narrow conditions. In particular, the CSIRT will be able to limit the notification when the concerned product is predominantly present in its domestic market and does not entail a risk for other EU countries.

In addition, national authorities will not be obliged to disclose any information they consider necessary to protect essential security interests. This caveat is in line with EU treaties.

The third condition applies if the manufacturer itself sees an imminent risk in case of further dissemination and states it in the notification.

In turn, MEPs obtained that ENISA would still be given some information to monitor any systemic risk for the single market. The EU agency will be made aware of the manufacturer and product concerned, together with some general information on the exploit.

Another point the parliamentarians pushed for is wording stating that ENISA should be given sufficient resources to cope with the new tasks. While this did not make it into the law, it will be part of a joint declaration from the EU’s main institutions.

Open source software

Another negotiation point is dealing with open-source software integrated into commercial products. Here, an agreement was reached at the technical level and endorsed at the political level.

As Euractiv previously reported, the idea was to cover only software developed in the context of commercial activities and to have more limited rules for open-source software stewards regarding documentation and vulnerability handling.

In the final iteration of the text, seen by Euractiv, non-profit organisations that sell open source software on the market but reinvest all the revenues in non-for-profit activities were also excluded from the scope.

National security exemption

Member states obtained the exclusion from the regulation’s scope any product developed or modified exclusively for national security or defence purposes.

Secondary legislation

A recurring discussion in EU law-making is the type of secondary legislation used, as delegated acts see the involvement of the Parliament, which is not the case for implementing acts.

The definition of the support period will detailed under a delegated act, whereas that for special product categories will be done under an implementing act.

Allocation of revenues from penalties

The EU Parliament pushed to introduce wording requiring the sanctions under this legislation to be reinvested into cybersecurity capacity-building activities. This point did not make it into the legal text, but there will be a reference in the law’s chapeau.

[Edited by Alice Taylor]

Read more with EURACTIV