Eurosmart’s priorities for the Cyber Resilience Act

13 Nov 2023 Eurosmart’s priorities for the Cyber Resilience Act

Comments on the European Parliament negotiating position and, on the Council General Approach

Eurosmart welcomes the recent achievements of the co-legislators on the Cyber Resilience Act (CRA) to provide more consistency with the already existing EU cybersecurity regulatory landscape.

As an organization dedicated to promoting secure digital interactions and privacy protection for individuals, we believe that the proposals deserve further improvement to adequately fit in with the EU cybersecurity regulatory landscape.

The digital security industry reiterates some concerns that have been already addressed through a previous white paper. The junction between safety and cybersecurity must be clarified, legal definitions and clarification on the CRA requirements for EU cybersecurity certified products should be provided. For obligations to manufacturer including the definition of product lifetime, security update requirements, incident mechanism and disclosure of vulnerability, Eurosmart would like to raise the co-legislator’s attention to the mechanism that are already in place for EUCC (today SOG-IS) certified product or products falling under the scope of the NIS2. A full alignment with NIS2 and other requirements that are already in used for this kind of products should be ensured.

Moreover, certification obligation in the CRA context for all high-end security products will complexify existing high-level evaluation processes. Instead of an obligation, Eurosmart recommends working and relying on “presumption of conformity” that could be provided by EU cybersecurity certificates.

1.  Required use of European cybersecurity certification schemes

Eurosmart recommends prioritising the implementation of the CRA principles like implementation of Essential cybersecurity requirements on product categories where the conformance mechanisms are not yet regular practice. Certification obligation in the CRA context for all high-end security products will complexify existing high-level evaluation processes. Several types of evaluations are already required for various sectors and have maintained products at the State-of-the-Art for years through the assessment of advanced and sector-specific security requirements.

Eurosmart invites the co-legislators to reconsider the European Council proposal focusing on certification obligation for all high-end security products.

In the meantime, effort should be made to recognised EU cybersecurity certification schemes as a mean to demonstrate conformity with the CRA essential requirements. In this respect, Eurosmart supports the proposal from the Commission to amend article 18.

2.   Common specifications

EU Council – Article 18(3 and 7) – Also refer to recital (41)

European Parliament – Article 19  – Also refer to recital (38) (38a) (41)

Common specifications could be an alternative to harmonised standards to support implementation of this regulation. Common specifications may be very useful to leverage existing industry or sector-specific standards for which it has been demonstrated that they meet some or all of the essential requirements of Annex I. As such, common specifications could support a quick implementation of the CRA, even if harmonised standards are not available, while limiting the impact on the industry.

The idea whereby harmonised standards should prevail over common specifications and common specifications should be seen as a last-resort option when no harmonised standards are available is too restrictive. The Common specifications approach should be a complementary option which could address very specific products and use cases.

3.   High-risk AI system

As a general comment, enhanced clarity is necessary for the compliance requirements. The interplay between AI Act and CRA is not well established.

4.   Obligations of manufacturer

4.1.    On components

EU Council – Article 10(6) First paragraph

Pursuant to this proposed provision, the manufacturer of the product with digital element shall also ensure that the components vulnerabilities are handled in accordance with Annex I section 2.

Eurosmart would like to highlight that it may not always be possible. For instance, in the case where the component is an open-source library, the manufacturer of the product with digital element is not in position to handle vulnerabilities in such components if the provider of the open source library does not (especially security update, but also identification of vulnerability,). In addition, as open-source libraries are likely to be out of the scope of the CRA, their providers will not be required to handle vulnerability in accordance with the CRA. Therefore, this proposed provision is excessive as it puts all the burden on the manufacturer of the product with digital elements while the component provider may not fall under the CRA. Finally, it shall be noted that vulnerability handling of the product with digital element will indeed consider the components insofar as it is relevant for the product with digital element.

Therefore, Eurosmart recommends removing the following wording:” including its components”

4.2.    Product life-time – Support period

EU Council – Article 10(6) Second paragraph – Also refer to recital (33-a)

European Parliament – Article 10(6) Also refer to recital (32a)

The expected product lifetime should indeed be determined in accordance with the criteria listed herein. However, other criteria which could also limit the expected product lifetime should also be considered, such as:

• the nature of the technology which may limit the possibility to provide security update over time. For instance, hardware-based product may be harder to fix if a vulnerability directly stems from the hardware design of the product; or
• the nature of the conformity assessment and reviews of the security of the product with digital elements (Annex I – section 2 – point 3). If In-depth conformity assessment or reviews of the security of product are used (e.g., EU CSA security certification), a higher and deeper knowledge of the product with digital element and its design is provided, combined with a proactive identification of product impacted by vulnerabilities, which in turn is prone to spot any vulnerabilities.

Therefore, Eurosmart recommends adding the above-mentioned criteria for the definition of the expected product lifetime.

4.3.    Security update

EU Council – Article 10(6) Fourth paragraph

It should be clarified from when the security update should be made available for a duration of 10 years. Would either the placing on the market or the release of the security update be considered?

European Parliament – Article 10(6) Annex I – section 1 – item (3)(a and b)- Also refer to recital (32b)

Automatic security updates by default are not possible in some cases. Some products with digital elements may not be able to automatically install security update, especially because their connectivity depends on the user which may not always connect them (e.g., payment card).

4.4.    Access to the source code to other undertakings extending vulnerability handling services

European Parliament – Article 10(6a)- Also refer to recital (32c)

Where the support period is shorter than five years and the handling of vulnerabilities has ended, the vulnerability handling service should be managed by a third-party.  For This provision may violate the IP of manufacturer as well as the freedom to decide on an appropriate vulnerability handling period. This provision may conflict with sectorial certification schemes and with national laws limiting technology transfer.

In addition, the nature of the technology may limit the possibility to provide security update over time. For instance, hardware-based product may be harder to fix on the long term if a vulnerability directly stems from the hardware design of the product.

Therefore, Eurosmart recommends removing this statement.

4.5.    Subsequent versions of a software product

EU Council – Article 10(6a)

Eurosmart very much welcomes this provision. It may be very useful for manufacturers which may have placed on the market several versions of a software and that would like to alleviate the burden of security update preparation by only issuing security updates for the latest version.

5.   List of essential requirements

5.1. Distinguish obligations for placing on the market and obligations during the whole product lifetime

EU Council – Article 10(12)

European Parliament – Article 10(12)

Eurosmart recommends clarifying which of the essential requirements of Annex I – section 1 should be met from the placing on the market over the expected product lifetime (see dedicated comment on that point). Eurosmart recommends bringing clarification on that point. 

See also section 6.3 of this document (definition of essential requirement).

5.2.    SBOM – Information format

Council – Article 10(15)

The format of the information and instructions referred to in Annex II should be defined as soon as possible to provide visibility to industry, which will be substantially impacted by the CRA. Therefore, the definition of this format should not be postponed after the adoption of the text but defined in the course of the adoption of the regulation.

Eurosmart recommends defining in the regulation the format of the information and instructions referred to in Annex II, and not postponing it after the adoption of the regulation.

European Parliament – Article 10(15)

Format and element of SBOM, format and procedure of notification etc. are technical documents by essence. As they are not providing any additional political aspect to the CRA, Eurosmart recommends relying on implementing acts rather than delegated acts.

6.   Reporting obligations

6.1. Limitation in time

EU Council – European Parliament – Article 11- Also refer to recital (34) and (35)

The reporting obligations introduced in this article should be limited in time. Under the current version, they are perpetual, which is not acceptable for manufacturers. Manufacturers should not be required to abide by these obligations decades after the products with digital elements are not produced anymore.

Therefore, Eurosmart recommends introducing a limitation in time for the reporting obligations.

6.2. No corrective or mitigating measures are available

European Parliament – Article 11(1)- Also refer to recital (34) and (35)

Eurosmart very much welcomes the addition covering the case of notified vulnerability, which does no corrective or mitigating measures available. In such cases, the vulnerability should remain confidential.

6.3. Notification procedures – actively exploited vulnerabilities.

European Parliament – Article 11(1a) (1b)

Eurosmart very much welcomes this new approach for the notification of actively exploited vulnerability, which leaves more time to the manufacturer to collect and analyse information.

However, Eurosmart believes, the deadline should be extended.

Moreover, Eurosmart supports the provision that acknowledges notified vulnerability should only be made public once corrective or mitigation measures – if possible – have been put in place.

6.4. Notification of significant incidents

European Parliament – Article 11(2) – Also refer to recital (19) and recital (35)

Eurosmart very much welcomes the proposal to limit the notification to significant incidents. This approach will alleviate the burden for manufacturer while ensuring that only relevant and useful information about incidents is notified. This new approach for the notification of significant incident, which leaves more time to the manufacturer to collect and analyse information.

However, Eurosmart believes, the deadline should be extended.

6.5. Information to the impacted users

European Parliament– Article 11(4)

Eurosmart raises several concerns regarding the provision of this article.

First, it may be difficult for manufacturer to inform users, as he may not know who the users are, especially when the products with digital elements are sold through distributors.

In addition, informing users about a significant incident having an impact on the security of the product with digital elements may raise substantial issues. First it may put at risk industrial and/or trade secrets belonging to the manufacturer. Also, such information may be exploited by malicious entities to carry out cyber-attacks on products with digital elements that have not been fixed, or whose users have not applied mitigation measures. In such situations it is usually better to set up corrective measures without any further information to the users to limit the risks.

Therefore, Eurosmart recommends removing the obligation for manufacturer to inform users about a significant incident having an impact on the security of the product with digital elements, and instead leave it to the CSIRT or the ENISA to decide whether the users should be informed.

7.   Definitions

7.1. Data

EU Council – European Parliament – Article 3(6) – Also refer to Recital (7)

Data, when processed by another software or hardware could be understood by national authorities in the light of the definition provided for in article 3(6) as being a “computer code” (For example a word file, or a movie on a DVD, processed by a software to trigger some specific actions).

It seems it is not the intention of the text to also cover data whether formatted in machine-readable format or not. However, this ambiguity could lead to major divergence of implementation of this text within EU.

Therefore, Eurosmart believes a clarification should be brought in that regards to remove any ambiguity and risk of divergence of implementation with EU. Thus Eurosmart recommends adding the following text within recital (7):

“Data (personal or non personal) whether formatted in a machine readable language or not is not a software.”

7.2. Actively exploited vulnerability

EU Council – Article 3(39) – Also refer to recital (19a)

The proposed definition of “actively exploited vulnerability” seems broader than the one initially proposed by the European Commission, as now unsuccessful attempts are also included. This broader definition raises legal concerns.

Only attempts for which the consequences are visible are likely to be noticed, meaning those that are successful. In contrast, unsuccessful attempts, without any consequences are very likely not to be noticed. Therefore, it seems very difficult for the manufacturer from a practical standpoint to establish and identify unsuccessful attempts of exploitation of vulnerabilities.

Therefore, Eurosmart recommends to only include in the definition of “actively exploited vulnerability successful attempts”.

7.3. Cyber threat

European Parliament – Article 3(39a)

Eurosmart very much welcomes this definition that was missing.

7.4. Essential requirements

Council – Annex I section 1

The content of Annex I gathers several types of essential requirements which may be classified as follows:

• Essential requirements applicable for the design of the product with digital elements and before its placing on the market : 1; 3(h) and 3(i);
• Essential requirements applicable at the placing on the market of the product with digital elements: 3(a), 3(aa) and 3(aaa);

Regarding the rest of the essential requirements (3(aaa), 3(b), 3(c ), 3(d), 3(e ), 3(f ), 3(g) ), Eurosmart recommends these essential requirements to be met at the placing on the market and not over the expected product lifetime. 

According to article 10(12), it seems that these essential requirements should be met from the placing on the market of the product with digital elements over the expected product lifetime. Eurosmart asks for clarifications on this point within Annex I. In addition, for better readability and understanding, Eurosmart suggests reshaping the content of Annex I to clearly distinguish the different types of essential requirements:

• those applicable for the design of the product with digital elements and before its placing on the market;
• those applicable at the placing on the market;
• those applicable from the placing on the market over the expected product lifetime;

European Parliament – EU Council – Annex I section 1

The following essential requirements can’t be met by some types of products with digital elements, and rather appears as a feature than an essential requirement:

• “including the possibility to reset the product to its original state” in Council and Parliament 3(a);
•  “including a default setting that security updates be installed automatically” in Council 3(a);
• “with a clear and easy- to-use opt-out mechanism.” In Council 3(a);
• “set as a default setting – which can be switched off – that security updates are installed automatically on products with digital elements if not installed within a certain timeframe” in Council 3(aaa);
• “through automatic updates by default, but with a clear and easy-to-use opt-out mechanism, and where applicable through the notification of available updates to users, and the option to temporarily postpone them” in Council 3(k);

Therefore, Eurosmart suggests to either remove them or to keep them and indicate that they are optional features.