1. The horizontal approach

As mentioned in the introduction, one of the regulatory drivers underlying the CRA proposal was the fragmented EU legal framework with regard to mandatory cybersecurity requirements for products (with digital elements).Footnote ¹⁷ Therefore, the Commission opted for a horizontal regulatory approach rather than (continuing to rely on) sectoral legislation to ensure legal certainty, avoid further market fragmentation, and minimise the compliance burden on manufacturers generated by several legal acts.Footnote ¹⁸

Accordingly, the CRA introduces objective-oriented and technology-neutral cybersecurity essential requirements that apply to all the products in scope. The broad, cross-sectorial scope of the Regulation is a direct consequence of such a horizontal foundation. The CRA applies to all products with digital elements (hereinafter, PDE) “the intended purpose or reasonably foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network.”Footnote ¹⁹

To understand the extent of such horizontal scope, it is necessary to unravel the notion of PDE. Within the meaning of “product with digital elements” falls any piece of hardware and software, including the software in the absence of which the product cannot perform one of its functions (ie, remote data processing solutions),Footnote ²⁰ even if placed on the market separately.Footnote ²¹ This notwithstanding, not all stand-alone software will have to comply with CRA’s essential requirements.

In fact, Recital 11 clarifies that remote data processing solutions, such as cloud solutions, fall in the scope of the CRA only insofar as they are necessary for a product to perform one of its functions, such as a mobile application requiring access to an API or to a database developed by the manufacturer. Thus, Directive (EU) 2022/2555 (NIS2) already applies to entities providing cloud computing services and cloud service models such as Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) or Infrastructure-as-a-Service (IaaS).Footnote ²²

In this respect, DIGITALEUROPE warned the EU legislator to clarify the interplay between the NIS2 and the CRA as many “cloud-based software tools will be subject to both the CRA and the NIS2, despite these targeting different aspects of the cybersecurity domain.”Footnote ²³ As a result of such pleas, the final text of the CRA contains a provision that requires the Commission to publish guidance to facilitate the implementation of the CRA by economic operators and ensure the consistency of such implementation.Footnote ²⁴ In particular, these documents should address inter alia the scope of the CRA, “with a particular focus on remote data processing solutions and free and open-source software.”Footnote ²⁵

Moreover, a partial carve-out is provided, by negative, for free and open-source software (FOSS) if it is not made available on the market, that is, supplied for distribution or use in the course of a commercial activity.Footnote ²⁶ Thus, policymakers felt that regulating FOSS cybersecurity was necessary amidst recent supply chain attacks involving open-source components (eg, Log4Shell or XZ Utils).Footnote ²⁷ In order not to hamper the development and deployment of FOSS, the EU legislator opted for a “light-touch” regulatory regime, including “softer” obligations for legal persons (open-source stewards) providing support on a sustained basis for the development of FOSS intended for commercial activities (eg, foundations supporting specific FOSS projects; or companies developing FOSS for their use that make it available; or not-for-profit entities developing FOSS in a business context).Footnote ²⁸ Despite such a “light-touch” approach, the FOSS community still fears that the new rules may eventually conflict with its decentralised and cooperative inherent nature.Footnote ²⁹

Then, some PDEs are outright excluded from the scope of the CRA as the Union sectoral legal acts that apply to them adequately address cybersecurity and information security risks. That is the case of medical and in-vitro devices,Footnote ³⁰ motor vehicles,Footnote ³¹ aeronautical equipment certified under Regulation (EU) 2018/1139, and marine equipment in the scope of Directive 2014/90/EU.

Lastly, the CRA does not apply to spare parts made available on the market intended to replace identical components in PDE, provided that they are manufactured according to the exact specifications and PDE are developed exclusively for national security or defense purposes.Footnote ³²

2. The risk-based approach

The CRA hinges on a risk-based approach in line with recent EU legislation regulating the digital sphere. Accordingly, products are clustered into categories depending on their cybersecurity risk. CRA’s understanding of cybersecurity risk is functional and traditional at the same time. It is functional since it generally and neutrally refers to “the potential for loss or disruption caused by an incident,”Footnote ³³ leaving therefore enough room to encompass unintentional and intentional acts. It is traditional as it aligns with well-established risk assessment methodologies where risk is expressed as a combination of two variables, ie, the magnitude of the impact (ie, the loss or disruption) and the likelihood of occurrence of the incident.Footnote ³⁴

Besides a “default” category, products with digital elements are “important” if their core functionality is listed in Annex III.Footnote ³⁵ The rationale underlying this classification lies in the higher severity of the exploitation of potential vulnerabilities of such products due to either their cybersecurity-related functionality or the performance of a function carrying a significant risk of adverse effects in terms of its intensity and ability to damage other products with digital elements or to the health, security or safety of its users, through direct manipulation.Footnote ³⁶ This products category is further divided into two classes, IFootnote ³⁷ and IIFootnote ³⁸: products listed in class II reflect a higher level of cybersecurity risk as an incident might generate greater negative impacts.Footnote ³⁹

The last category of products is that of “critical” PDEs. Using the same approach seen above, products with digital elements whose core functionality is listed in Annex IV are critical.Footnote ⁴⁰ The classification builds on the criteria adopted with regard to important products and adds two other conditions: NIS2 essential entities have a critical dependency on the category of products, and/or incidents and exploited vulnerabilities concerning such category of products can lead to serious disruptions to critical supply chains across the EU market.Footnote ⁴¹

The main normative implication of such risk-based taxonomy lies in the different conformity assessment procedures the manufacturers of such products have to follow. As addressed in the next section, important and critical products with digital elements have to undergo stricter conformity assessment procedures than the internal control procedure,Footnote ⁴² that is, a self-assessment performed by the manufacturer.

In this respect, the CRA operationalises the risk-based approach in a different fashion than the AI Act, where AI systems, classified according to several levels of risk – as in the CRA, are associated with different safeguards to compensate for the risk they pose to protected values, such as fundamental rights, safety, and democracy. The rationale underlying the CRA opposes the view that minor risks require minimal precautions. For all the products falling in the scope of the CRA have to comply with the essential requirements set out in Annex I, whilst requirements set out in section 2, chapter 3 of the AI Act only apply to high-risk AI systems.

Similar to the AI Act,Footnote ⁴³ however, the CRA predetermines the level of risk of specific products with digital elements without leaving room for an ex-post re-determination based, eg, on risk management measures as in the logic of Article 35 GDPR.Footnote ⁴⁴ Moreover, such ex-ante pre-determination of the risk levels does not take into account the context where important or critical products are deployed.

Finally, the CRA deploys mechanisms to mitigate, besides cybersecurity risks, other risks such as the archetypical EU product safety health & safety risks, but also novel categories of risk, as is the case of the risk to compliance with obligations under Union or national law intended to protect fundamental rights; to the availability, authenticity, integrity or confidentiality of services offered using an electronic information system by NIS2 essential entities or to other aspects of public interest protection.Footnote ⁴⁵ Section IV further elaborates on the risk to compliance with fundamental rights obligations.

3. The product safety approach

The EU “product safety approach” hinges on ensuring that products – in this case, products with digital elements – are safe before they are made available on the Internal Market. It follows, therefore, an ex-ante, that is, pre-market regulatory logic. In a nutshell, the EU product safety acquis aligns with the so-called “New Legislative Framework” (NLF). Adopted in July 2008, the NLF consists of Regulation (EU) 765/2008, Decision 768/2008, and Regulation (EU) 2019/1020 and reformed the “New Approach” developed in 1985.Footnote ⁴⁶

The New Approach replaced the Old Approach, where national authorities drew up highly prescriptive technical legislation (and sometimes delivered certificates of conformity themselves). From the 80s, legislative initiatives, the Court of Justice case-law (in particular, the Cassis de Dijon Case),Footnote ⁴⁷ as well as the systematic application of the principle of mutual recognition aimed at preventing barriers for products within the EU market and promoting the free movement of goods. The New Approach legislative technique picked up the principles established in Cassis de Dijon, in particular: (i) harmonised legislation is limited to set out “essential requirements” that products placed on the EU market must meet; (ii) EU harmonised technical standards specify how products can meet such requirements from a technical perspective; (iii) products manufactured in compliance with harmonised technical standards (which is voluntary) benefit from a presumption of conformity with the relevant requirements.Footnote ⁴⁸

The NLF complemented and reformed the New Approach by taking into account several elements: accreditation, notification, the conformity assessment procedure (so-called “modules” were introduced), CE marking, and market surveillance. To make a product available in the EU market, manufacturers have to demonstrate the conformity of their products with the corresponding essential requirements through specific conformity assessment procedures. Consistently with NLF principles, besides manufacturers, who are understandably the stakeholders with the greatest burdens in terms of compliance, a wide array of parties along the supply chain, from importersFootnote ⁴⁹ and distributorsFootnote ⁵⁰ to authorised representatives,Footnote ⁵¹ must comply with specific rules.

Since it aligns with the NLF, the CRA imposes as a precondition for making PDEs available on the EU market, whereby PDEs must meet the essential requirements (ERs) set out in Part 1 of Annex IFootnote ⁵² and the processes put in place by the manufacturer must comply with the ERs set out in Part 2 of Annex I.Footnote ⁵³

For the purpose of complying with the abovementioned obligation, manufacturers have to carry out an assessment of the cybersecurity risks associated with the PDE.Footnote ⁵⁴ In line with the context-based tradition of risk management theory, the cybersecurity risk assessment has to be “based on the intended purpose and reasonably foreseeable use, as well as the conditions of use, of the product with digital elements, such as the operational environment or the assets to be protected, taking into account the length of time the product is expected to be in use.”Footnote ⁵⁵ This obligation clearly exemplifies the complementarity between the risk-based and product safety approach.

Manufacturers of PDEs must comply with many more obligations. For instance, when integrating components from third parties (including FOSS), manufacturers must make sure that such components do not compromise the cybersecurity of the PDE.Footnote ⁵⁶ Moreover, they have several documentation (as per Article 31 and Annex VII)Footnote ⁵⁷ and information obligations, vulnerability handling obligations, in accordance with the ERs set out in Part 2 of Annex I,Footnote ⁵⁸ as well as cooperation obligations.Footnote ⁵⁹

Notably, manufacturers also have to comply with a twofold set of reporting obligations. In the first case, when a manufacturer identifies a vulnerability in a component integrated into the PDE, it reports the vulnerability to the person or entity manufacturing or maintaining the component, and if it develops a patch, it then has to share the relevant code with said party.Footnote ⁶⁰ This provision was added later in the legislative process and is to be welcomed as it provides (legal) incentives for cooperation between stakeholders with a view to ensuring a high level of resilience.Footnote ⁶¹ In the second case, manufacturers notify the competent national market surveillance authority and ENISA of the exploited vulnerabilities and severe incidents having an impact on the security of the PDE.Footnote ⁶²

Importantly, CRA’s requirements and obligations combine a more traditional by-design approach,Footnote ⁶³ now fully entrenched in EU cybersecurity regulation,Footnote ⁶⁴ with a lifecycle approach, which is not a hallmark of EU product safety legislationFootnote ⁶⁵: not only cybersecurity cannot be (anymore) an afterthought but it must be taken seriously throughout a product’s lifecycle.Footnote ⁶⁶ In this respect, the CRA implicitly introduces a somewhat “principle of accountability,” as manufacturers have to determine themselves the support period of each PDE following several criteria and, if requested, they must be able to provide market authorities with the factors that were taken into account to determine such period.Footnote ⁶⁷

The last step that manufacturers must take before marketing is demonstrating compliance with CRA essential requirements through a specific conformity assessment procedure. Finally, manufacturers draw up an EU declaration of conformity to state that the fulfillment of the ERs has been demonstratedFootnote ⁶⁸ and affix the CE marking,Footnote ⁶⁹ which indicates the conformity of a product.

Conformity assessment is one of the cornerstones of the NLF reform. In the specific context of the CRA, the risk-based taxonomy of PDEs (ie, default, important class I and II, critical, and FOSS) is mainly relevant as regards the different NLF proceduresFootnote ⁷⁰ manufacturers can or must follow to demonstrate compliance with the ERs. For the “default” category – which, according to the Commission, should cover the vast majority of PDEs,Footnote ⁷¹ manufacturers can either opt for self-assessment (ie, internal control procedure, based on Module A of Decision No 768/2008/EC) or a stricter procedure involving a third party (eg, EU-type examination procedure, full quality assurance or, if available, an EU cybersecurity certification scheme).Footnote ⁷²

As regards class I important PDEs, self-assessment is still allowed but additional safeguards are requiredFootnote ⁷³: manufacturers need to apply, alternatively, harmonised technical standards,Footnote ⁷⁴ common specificationsFootnote ⁷⁵ or European cybersecurity certification schemes. If not, the class I important PDE shall undergo third-party assessment. For class II important and critical PDEs self-assessment is excluded, even if the PDE complies with harmonised standards, technical specifications or EU cybersecurity certification schemes fully or in part.Footnote ⁷⁶ The only exception is provided for important PDEs that qualify as FOSS: manufacturers can follow the internal control procedure based on Module A, provided that they make the technical documentation available to the public.Footnote ⁷⁷ The rationale behind this regulatory choice lies in the transparency paradigm of the open source: anyone (tech-savvy enough) can verify the software’s degree of security.

1. Procedural challenges

To get an understanding of the fundamental rights relevance in the CRA’s enforcement mechanisms, the analysis needs to focus on the procedure of Article 57 CRA described above, ie, complaint PDEs that nonetheless present significant risks. From a procedural standpoint, the CRA is surprisingly concise. This opens up a number of significant questions. How much time has to pass between the Commission’s notification to the relevant market surveillance authority and its inaction before the Commission’s takeover? What are the exceptional circumstances that justify the immediate intervention of the Commission?

It is thus not clear when the Commission can effectively take over from national Market Surveillance Authorities in situations where PDEs do not comply with the CRA or do comply but present nevertheless a significant cybersecurity risk or other risks to fundamental values. Against the background of a widespread lack of staff and financial resources of market surveillance authorities at the Union level,Footnote ¹⁰⁰ it is not unreasonable to imagine that slow enforcement risks becoming the rule rather than the exception. The lack of deadlines leaves even more astonished if those procedures are compared with the Union safeguard procedure under Article 55 CRA. In that case, the Commission decides whether corrective or restrictive measures taken by national authorities are justified or not within a specific timeframe (ie, nine months from the notification from the relevant authority).

Moreover, other legal acts in EU “digital law” contemplate scenarios where subject to specific conditions, there is a transfer of enforcement powers from the national to the Commission level. However, Regulation (EU) 2022/2065 (Digital Services Act), for instance, sets precise deadlines for this referral.Footnote ¹⁰¹ All in all, the vague formula of the CRA would potentially leave in the hands of the Commission a blank cheque for choosing which PDEs to bring to the scrutiny of its offices, alleging the exceptional nature of the circumstances.

Related to that, whereas Recital 113 CRA sheds light on the meaning of “exceptional circumstances,” it only makes reference to seemingly less problematic situations of emergency where non-compliant products are widely made available by the manufacturer throughout several Member States or used in key sectors by NIS2 entities while containing known vulnerabilities that are being exploited by malicious actors and for which the manufacturer does not provide available patches. This notwithstanding, there is no indication in Article 57, nor in the corresponding recitals, as to the criteria for determining what an exceptional circumstance might amount to in the case of complaint PDEs.

A possible solution to the question of which criteria should be taken into account in determining the exceptionality of circumstances could look at the gravity of the risk posed by the (compliant) product. This argument follows from the interpretation of Recital 113 CRA, whereby exceptionality is linked to a cross-border effect or the critical context in which the product is used.

From a comparative perspective, it is possible to resort to the AI Act, with a view to critically reflecting on relevant “regulatory siblings,” that is, “legal rules which bear a striking terminological resemblance, if not sometimes an identical form.”Footnote ¹⁰² In particular, Article 82 AI Act, laying down (procedural) enforcement rules for compliant AI systems that present a risk, is the regulatory sibling of Article 57 CRA. In the case of the AI Act, however, the Commission does not have the power to request the relevant authority to evaluate a compliant AI system or to carry out an evaluation, as in the CRA.

The ambiguities addressed above reveal a picture of legal uncertainty, which eventually leaves considerable power in the hands of the Commission. In this regard, recent developments in EU product safety acquis, notably the CRA, the AI Act,Footnote ¹⁰³ and the General Product Safety Regulation,Footnote ¹⁰⁴ or in the Digital Single Market (eg, Digital Services ActFootnote ¹⁰⁵ and Digital Markets ActFootnote ¹⁰⁶), can be seen as significant steps in the ongoing paradigm shift where enforcement powers, once the exclusive prerogative of national authorities, increasingly assume Union relevance through a centralisation on the Commission.

2. Substantive challenges

As seen above, Article 57 lists, besides significant cybersecurity risks, several other risks that shall be managed by economic operators if posed by their products. Whereas the risk to the health or safety of persons is the bread and butter of EU product safety legislation, the remaining three categories, ie, (i) the risk to compliance with obligations intended to protect fundamental rights; (ii) availability, authenticity, integrity or confidentiality of services offered by NIS2 entities or, (iii) other aspects of public interest protection deserve more attention. If the last risk-category has already been criticised for being ultimately a too vague and broad open clause,Footnote ¹⁰⁷ for the purpose of this paper, the analysis focuses only on the risk to compliance with fundamental rights obligations.

The main research question underlying the legal analysis was to what extent the CRA could enhance the protection of fundamental rights. A closer look at the abovementioned provision reveals how the CRA upholds fundamental rights and, consequently, how the “risk to rights” is operationalised in this piece of EU law. The risk is not to fundamental rightsFootnote ¹⁰⁸ per se, but to the compliance with obligations intended to protect fundamental rights. In the first scenario, the emphasis is more on the violation of the essence of the right; in the second scenario, on the other hand, the risk is somewhat more specific, ie, with respect to compliance with a second-level norm implementing a fundamental right. The question that must be asked is whether the difference between the two approaches is merely semantic or, however subtle, substantial. In other words, does the assessment that the law requires change completely?

This is a major difference from the “regulatory sibling” of the AI Act. Article 82 AI Act mandates market surveillance authorities to require the relevant economic operator to take all appropriate measures to ensure that the high-risk AI system, although compliant with the Act, no longer presents a risk to fundamental rights. And not to the compliance with fundamental rights obligations. Such an approach is coherent with the rights-based regulatory foundation of the AI Act, even if the choice to achieve fundamental rights protection ends in the context of AI by recourse to product safety means has attracted a lot of criticism.Footnote ¹⁰⁹

Here lies the crux of the CRA. Thus, the Commission’s CRA proposal was more ambiguous, as Recital 59 referred to risks to fundamental rights (like the AI Act), whereas Article 46 was already in its final form, ie, risks to the compliance with obligations under Union or national law intended to protect fundamental rights.

In the first scenario seen above, the relevant authority, or the Commission, would have to carry out a contextual and expert-based fundamental rights impact assessment to determine whether a specific PDE entails a risk to specific rights and freedoms. As rights and freedoms are not easily quantified,Footnote ¹¹⁰ these evaluations usually imply ascribing values to them.Footnote ¹¹¹ This activity requires complex interpretative reasoning, a good knowledge of the relevant legal sources and case law, and, finally, normative judgments.Footnote ¹¹²

In the second scenario, on the other hand, the relevant authority – or the Commission – “only” has to verify whether a specific PDE complies with a set of obligations aiming to safeguard fundamental rights. At first glance, the outcome of such an assessment could be binary: an obligation is either respected or violated. Yet, such a non-flexible understanding of compliance seems to be at odds with the very rationale of risk, which is inherently scalable and granular. In the field of data protection, Gellert proposed that the GDPR’s “risk to fundamental rights” should be considered in terms of “risk of non-compliance with the GDPR”: “the lower the compliance, the higher the potential violations of the data subjects’ fundamental rights. Inversely, just as a low level of compliance signals the likely infringement of the data subject’s rights and freedoms, ensuring in turn that the rights and freedoms are not violated by the processing operation contributing to higher levels of compliance.”Footnote ¹¹³

In light of the above, also the compliance check will entail normative, qualitative and/or quantitative, context-based evaluations depending on the specific obligation scrutinised.Footnote ¹¹⁴ Products with digital elements of everyday use, falling in the scope of the CRA, like smart cameras, alarm systems, fitness trackers, headsets, etc. collect, process, and share a significant amount of users’ personal and sensitive data over time (eg, position, temperature, blood pressure, heart rate). Under the CRA, a PDE will be assessed against its degree of compliance with, eg, GDPR’s principles relating to personal data processing, such as data minimisationFootnote ¹¹⁵ – which, not surprisingly, is the only data protection-related essential requirements of the CRA, as well as data subject rights, eg, right to erasure,Footnote ¹¹⁶ which might be at risk of not-be-complied with if the PDE does not afford the end-user the possibility of deleting all personal data concerning him/her from the device.

Yet, does Article 57 CRA really enhance and complement existing EU or national legislation safeguarding fundamental rights and liberties, such as Regulation (EU) 2016/679 (GDPR)? The answer is in the affirmative. Data Protection Supervisory Authorities do not have the same enforcement powers of Market Surveillance Authorities for infringements of the GDPR, although some may argue that the corrective measure of a definitive limitation on processing under Article 58(2)(f) GDPR, essentially amounting to a ban, has effects similar to the most severe corrective powers of MSAs under EU product safety legislation. As a result of the interplay between the GDPR and the CRA, however, where a PDE, although compliant with the CRA, poses nonetheless a risk to the compliance of GDPR obligations, national Market Surveillance Authorities or the Commission will be able to take the same measures that the authority can enforce vis-à-vis non-compliant products. It might even go so far as to demand the withdrawal of the PDE from the Single Market. In other words, if a PDE in CRA’s scope fails to provide safeguards to protect users’ privacy and personal data protection can be subject to the Commission (or national authorities) product safety enforcement powers.

This notwithstanding, market surveillance authorities do not seem well-suited to carry out these value-based regulatory assessments due to the long-standing experience of data protection authorities in this field. Also, in the light of the chronic understaffing and underfunding issues, coupled with an unclear procedure, it is likely that an authority’s lack of readiness to initiate an enforcement procedure may give the Commission the opportunity to take severe restrictive and corrective measures on the grounds of eminently qualitative assessments. Against the backdrop of the relevance of non-technical factors (geopolitical factors, such as undue influence by a third country on suppliers) to determine the significance of cybersecurity risk,Footnote ¹¹⁷ the underlying risk is “to weaponize” fundamental rights to achieve political ends.