Developing guidelines for the Cyber Resilience Act

Executive summary

The Cyber Resilience Act (CRA) will for the first time introduce mandatory EU-wide cybersecurity requirements for all hardware and software products. If implemented right, it will provide a clearer regulatory framework for cybersecurity of connected devices.

The CRA can increase Europe’s cyber resilience, but for this to happen, certain elements must be made actionable for manufacturers, users and authorities. Recognising the complexity of its legal provisions, the CRA stipulates that the European Commission shall develop guidance to support authorities and the market in interpreting the text, including through consultation with industry.

In this paper, we put forward concrete recommendations for issues that need to be addressed in the upcoming guidelines, including beyond those set out explicitly in the CRA:

● Software as a product: The CRA applies New Legislative Framework (NLF) concepts to software, yet there are significant distinctions between tangible products and software. Placing software on the market requires not only making it available for download, but also transferring usage rights and providing access to it. Agreeing to a licence without payment, common with free and open-source software (FOSS), should not constitute placing it on the market.

● FOSS: Upstream open-source organisations are not considered manufacturers under the CRA. However, FOSS can be classified as a product once it enters commercial circulation. To clarify this, we suggest examples of activities that should not be deemed commercial. The CRA’s focus on making products available in the EU poses challenges for FOSS, given its less controllable regional scope. The guidelines should restrict this concept to ready-to-use open-source packages for commercial use, specifically targeting companies integrating or offering open-source products in the EU market. The introduction of open-source stewards provides flexibility to accommodate the unique nature of FOSS, and we propose several ways in which the guidelines could support stewards.

● Remote data processing: The CRA excludes cloud-based solutions, yet lacks clarity on when these services fall under its scope. The guidelines should explicitly state that remote data processing, including cloud solutions, isn’t classified as a ‘product with digital elements.’ To be considered part of a product, such processing must be essential for its functions and developed by the product’s manufacturer. Scope should be limited to bidirectional data exchanges directly enhancing product functions, excluding services solely receiving data or not interacting directly.

● Substantial modification: Rules governing substantial modifications must be straightforward to ensure practical application of the CRA without requiring extensive legal analysis for each update. By default, security updates alone should not constitute a substantial modification. Similarly, upgrades should not automatically trigger substantial modification unless new risks arise. We propose simplified conformity assessments for substantial modifications when risks are sufficiently mitigated.

● Support period: Defining the support period should balance consumer expectations with practical constraints. Manufacturers should determine this period, with exceptional cases open to challenge only based on clear evidence. Flexibility in communicating support duration should be provided, ensuring consumer understanding.

● Vulnerability handling: The guidelines should clarify that patches are necessary only for vulnerabilities impacting product security in intended use. They should also clarify that effective vulnerability handling can serve as an appropriate mitigation whenever products cannot be updated remotely by the manufacturer to remedy known exploitable vulnerabilities prior to making them available on the market.

● Vulnerability reporting: The notion of ‘becoming aware’ should align with existing language in the European Data Protection Board (EDPB) guidelines on personal data breach notifications. ‘Severe incidents’ under the CRA should correspond to the definition of ‘significant incident’ under the Directive on measures for a high common level of cybersecurity across the Union (NIS2) and its interplay with the definition of special categories of personal data in the General Data Protection Regulation (GDPR). The guidelines should minimise vulnerability reporting obligations for legacy products.

● Interplay with other legislation: Potential overlaps with other regulations need clear guidance to avoid duplicate reporting in line with the once-only principle.6 Overly crowded cybersecurity reporting has been identified as a significant impediment to EU competitiveness in our recent report The Single Market Love Story. The guidelines should provide a reporting template applicable across all relevant legislation.

We urge that guidelines should be developed alongside the secondary legislation foreseen in the CRA, notably the Art. 7(4) delegated act on the technical description of the categories of important and critical products in Annexes III and IV.