Digital Product Vulnerability Management Under The EU Cyber Resilience Act (CRA): Core Rules And Compliance Strategies For Chinese Enterprises.

Introduction: The CRA

On 23 October 2024, the European Parliament and the Council of the European Union formally adopted Regulation (EU) 2024/2847, commonly known as the Cyber Resilience Act¹ (CRA). It was published in the Official Journal of the European Union on 20 November 2024 and came into force on 10 December 2024, marking the start of a transition period. 

The CRA is the EU’s first cross-sectoral cybersecurity legislation to cover all categories of digital products. It has great significance for manufacturers of Chinese digital products that regard the EU as a key market. The CRA began its transitional period on 10 December 2024 and now eighteen months  has passed. The Cyber Vulnerability management and reporting obligations under the CRA (the focus of intense industry attention) will apply from 11 September 2026. The remaining obligations will be fully applicable from 11 December 2027. All provisions of the Act are binding in their entirety on EU member states and are directly applicable within their territories.²

This is the first article in our Cyber Vulnerability Governance and Compliance Response series which will compare the cyber vulnerability management rules of the EU and China. This instalment focuses on the EU rules with a particular analysis of the vulnerability of the governance obligation systems established by the CRA.

I. The CRA’s Compliance Framework and Main Content

(I) Legislative Background

The CRA is the EU’s first legislation covering the cybersecurity of products with digital elements (digital products) across all sectors. The background and main considerations behind its enactment have been explained in the preamble: cybersecurity is one of the key challenges facing the EU. In the coming years, the number and variety of connected devices will grow exponentially. Cyberattacks concern the public interest; they not only significantly impact the EU economy but also undermine the democratic order and threaten consumers’ personal safety and health. Consequently, the EU urgently needs to improve its cybersecurity governance systems. It can do this by establishing a unified legal framework that sets out the essential cybersecurity requirements that digital products must meet to access the EU market and optimize the functionality of the internal market.³

Two problems continue to drive up user and social costs in the EU and require urgent resolution:

• Supply side: the number and variety of connected devices is growing exponentially. However, the overall cybersecurity level of digital products remains low, security vulnerabilities are widespread and the accompanying security update services are insufficient and inconsistent in their standards.

• Demand side: users have insufficient awareness of product security information and limited channels to obtain it. This makes it difficult to select products with adequate cybersecurity capabilities and to use products securely.⁴

The CRA aims to address the security and information-asymmetry problems of digital products. Its core objective is to ensure the cybersecurity of digital products by establishing essential cybersecurity requirements and obligations among EU member states.

(II) Scope and Exclusions

The CRA regulates all digital products made available on the EU market. Any hardware or software product that, in its intended use or under reasonably foreseeable use, can establish a direct or indirect logical or physical data connection with a device or network falls within its regulatory scope.⁵ This scope covers smart home appliances, surveillance cameras, wearable devices, network communication equipment, industrial sensors, industrial control modules, connected office equipment, consumer electronics and numerous other categories. This definition is designed to bring the majority of products with networking capability and digital components within a unified cybersecurity governance system.

The CRA also sets out multiple exclusions, principally comprising three categories:

• Priority application of sectoral legislation: medical devices (Reg (EU) 2017/745, 2017/746), vehicles (Reg (EU) 2019/2144), aviation (Reg (EU) 2018/1139) and marine equipment (Dir 2014/90/EU).

• Public and national security exceptions: dedicated products for defense and national security and equipment that processes classified information.

• Structural exclusion: replacement parts manufactured to original-equipment specifications for replacing like components.⁶

For products regulated simultaneously by other EU sectoral legislation, the CRA sets out interface rules — where the sectoral legislation already imposes requirements on cybersecurity risks and achieves a level of protection equivalent to or higher than the CRA, the application of the CRA may be limited or excluded.⁷ For Chinese enterprises, this means that when determining whether the CRA applies, one cannot look solely at the product category but must also consider whether the product’s sector is already subject to specific regulation.

Special Note: Interface with the EU Artificial Intelligence Act (Regulation (EU) 2024/1689). Article 12 of the CRA provides that products listed as high-risk AI systems under Article 6 of the Artificial Intelligence Act, and falling within the scope of the CRA, are deemed to satisfy the cybersecurity requirements for high-risk AI systems under Article 15 of the Artificial Intelligence Act if they meet the essential cybersecurity requirements of the CRA (Annex I). The two acts form a ‘comply once, satisfy both’ arrangement — an important compliance-strategy benefit for Chinese enterprises subject to both instruments simultaneously.

(III) Main Content

The CRA comprises of eight chapters, 71 articles and eight annexes, establishing an overall regulatory system that covers the entire chain of digital product security. It contains four core pillars.

• General provisions: defining the regulatory objects and scope and laying a solid foundation for the entire regulation.

• Obligations of manufacturers: implementing source controls on product security design and operation/maintenance services.

• Product compliance: unifying market access rules and specifying conformity assessment and certification requirements.

• Market surveillance: implementing supervision, sampling inspections and measures for handling violations.

The vulnerability management that is the focus of this article runs through three pillars: essential requirements (contained in Annex I Part II — essential requirements for vulnerability handling); manufacturer obligations (in Article 13 — general obligations, including the support period); and post-market reporting (in Articles 14 to 17 — mandatory and voluntary reporting of vulnerabilities and serious incidents). These three pillars constitute the CRA’s vulnerability governance obligation system.

(IV) Overview of Penalties

The CRA does not directly prescribe fine amounts to be enforced uniformly by the EU; rather, it requires each member state to establish penalty rules that are ‘effective, proportionate and dissuasive’ and to set fine ceilings. The three tiers set out in Article 64 are as follows:

1.Up to EUR 15 million or 2.5% of the total worldwide annual turnover for the preceding financial year (whichever is higher): breaches of the essential requirements in Annex I and the obligations under Articles 13 and 14 — that is, breaches of the essential requirements for vulnerability handling and the vulnerability reporting obligations — fall within the most severe tier;

2.Up to EUR 10 million or 2% of the total worldwide annual turnover for the preceding financial year (whichever is higher): breaches of Articles 18–23 (obligations of other economic operators), Articles 28, 30–33 (EU declaration of conformity, CE marking, technical documentation, etc.), and Articles 39, 41, 47, 49 and 53;

3.Up to EUR 5 million or 1% of the total worldwide annual turnover for the preceding financial year (whichever is higher): providing incorrect, incomplete or misleading information to notified bodies or market surveillance authorities.

Micro and small enterprises are not subject to the above tier-1 penalties for late submission under Article 14(2)(a) and 14(4)(a) (24-hour early warning) and open-source software stewards are exempt from administrative fines under the CRA framework. The tier-1 penalty (for Annex I and Articles 13 and 14) of EUR 15 million / 2.5% is not exempted for micro and small enterprises as a whole; the enterprise’s size is required to be taken into consideration only in discretion over the fine amount.

Viewed from the logic of the penalty design, placing breaches of Article 14 in the most severe tier reflects the EU’s positioning of the ‘visibility of vulnerabilities and incidents’ at the central hub of the entire digital product security governance — in a sense, it constitutes the ‘neural network’ of the entire governance system.

II. Mandatory Requirements Imposed by the CRA on Digital Product Vulnerability Management

Vulnerability management is one of the core regulatory focuses of the CRA, running through the entire post-market lifecycle of digital products. These obligations are clearly defined and strictly binding and constitute the compliance baseline that Chinese enterprises must observe when exporting products to the EU. Manufacturers’ vulnerability management obligations have a three-tier structure.

Tier 1 — substantive obligations: the product must be made available on the market without exploitable vulnerabilities and must possess continuous vulnerability-handling capability throughout the support period (Article 13, Annex I Part II).

Tier 2 — process obligations: structural processes such as Software Bills of Materials (SBOM), a Coordinated Vulnerability Disclosure (CVD) policy and a single point of contact must be established (Article 13, Annex I Part II).

Tier 3 — reporting obligations: mandatory reporting of ‘actively exploited vulnerabilities’ and ‘severe incidents’, with voluntary reporting permitted for other vulnerabilities and incidents (Articles 14 to 17).

This chapter focuses on the reporting obligations concerning product vulnerability management under the CRA, namely Articles 14 to 17.

(I) Reporting and Supervision

Under Article 14 of the CRA, once a manufacturer becomes aware of an actively exploited vulnerability or a severe incident having an impact on the security of a product with digital elements, it must fulfil a reporting obligation. This article regulates the mandatory reporting of vulnerabilities and severe incidents. Article 15 of the CRA adds a voluntary reporting mechanism, stating that manufacturers and other natural or legal persons may proactively report to the Computer Security Incident Response Team (CSIRT) or the European Union Agency for Cybersecurity (ENISA⁸) digital product security incidents and potential security risks that could give rise to similar risks. CSIRTs may prioritize mandatory reports before processing voluntary ones. Where a third party proactively reports a vulnerability that has already been exploited or a severe incident affecting product security, the CSIRT must promptly inform the manufacturer of the concerned product and urge it to become aware of and address the risk.

(II) Triggering Conditions: What Constitutes an Actively Exploited Vulnerability and a Severe Incident

Under Article 3(42) of the CRA, an ‘actively exploited vulnerability’ means a vulnerability for which there is reliable evidence that a malicious actor has made use of a flaw without the permission of the system owner. Recital 68 explains that examples of such vulnerabilities include weaknesses in the authentication and identity-verification functions of products. That recital further states that vulnerabilities discovered for bona fide testing, investigation, correction or disclosure purposes aimed at promoting the security or protection of the system owner and its users, without any malicious intent, are not subject to the mandatory reporting obligation.

Under Article 14(5) of the CRA, a severe incident includes: (1) an incident that has had or may have a negative impact on the digital product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive data, important data or core functions; or (2) an incident that has led or may lead to the introduction or execution of malicious code in the digital product, or in the network and information systems of users of the digital product.

As to how a vulnerability or incident becomes known, the CRA does not prescribe how a manufacturer becomes aware of a vulnerability or severe incident. In practice, ‘becoming aware’ may originate from customer or partner reports, threat intelligence, reports issued by security researchers or third-party cybersecurity bodies, notifications from government cybersecurity authorities, disclosures by ethical hackers, or internal telemetry, scanning or honeypot (i.e., security mechanisms used to lure cybercriminals away from legitimate targets) alerts. Notably, Article 13(17) and Annex I Part II (6) already require the establishment of a single point of contact and measures facilitating information sharing — these mechanisms themselves constitute legal gateways for ‘becoming aware of vulnerabilities’. Enterprises are advised to integrate external threat-intelligence subscriptions, CVD mailboxes, product telemetry alerts and security-operations-center monitoring into a unified ‘vulnerability or incident trigger matrix’. This sets a clear internal escalation path and timestamp record for each gateway.

(III) Reporting Recipients and the Main Establishment Rules

Under Article 14(1) of the CRA, a manufacturer shall report simultaneously to the CSIRT acting as coordinator and to ENISA through a single reporting platform. Article 14(7) sets out the rules for determining the reporting recipient.

• Where the manufacturer has a ‘main establishment’ in the EU: the CSIRT electronic notification endpoint of the member state where the main establishment is located is used. Main establishment means the member state in which decisions concerning the cybersecurity of its digital products are predominantly taken; where this cannot be determined, it is the place with the largest number of employees within the EU.

• Where the manufacturer has no main establishment in the EU (the situation for the vast majority of Chinese enterprises): it is determined in the following order:

(a)the member state in which the authorised representative acting on behalf of the manufacturer for the highest number of products with digital elements of that manufacturer is established;

(b)the member state in which the importer placing on the market the highest number of products with digital elements of that manufacturer is established;

(c)the member state in which the distributor making available on the market the highest number of products with digital elements of that manufacturer is established;

(d)the member state in which the highest number of users of products with digital elements of that manufacturer are located.

Special Note: For Chinese enterprises without a main establishment in the EU, the determination of reporting CSIRT is contingent upon the distribution of the commercial chain. This means that the choice of authorised representative or principal importer in a given member state will determine the future cross-border compliance interface. The language, regulatory culture and the maturity of the CSIRT  must all be evaluated together when selecting an authorised representative / importer. Enterprises are advised to identify their preferred CSIRT before 11 September 2026 and complete account registration, technical interfacing and internal drills accordingly.

(IV) Reporting Timelines

Under Article 14(2) and Article 14(4) of the CRA, once a product presents a vulnerability or severe incident, the manufacturer must strictly observe the statutory deadlines and complete reporting in accordance with the rules. The CRA sets out layered reporting rules corresponding to different stages of incident handling and specifies the content to be submitted at each node, as detailed below.

Early warning notification (24 hours)

• Vulnerability: report immediately upon becoming aware that a vulnerability has been exploited, and no later than 24 hours; the notification shall list the EU member states in which the product is known to be available.⁹

• Severe incident: report immediately upon becoming aware of a severe incident, and no later than 24 hours; the notification shall at least state whether the incident is suspected to be caused by an unlawful or malicious act and, where applicable, list the member states in which the product is available.¹⁰

Notification (72 hours)

• Vulnerability: where the information has not yet been submitted in a prior step, report immediately upon becoming aware that the vulnerability has been exploited, and no later than 72 hours after; the notification shall include general information on the product concerned, the general nature of the exploit and of the vulnerability, the corrective or mitigating measures already taken, and the corrective or mitigating measures available to users; where applicable, it shall also indicate the manufacturer’s assessment of the sensitivity of the notified information.¹¹

• Severe incident: where the information has not yet been submitted in a prior step, report immediately upon becoming aware of the severe incident, and no later than 72 hours after; the notification shall include the nature of the severe incident, a preliminary assessment, the corrective or mitigating measures already taken, and the measures available to users; where applicable, it shall also indicate the sensitivity assessment.¹²

Final report (14 days / 1 month)

• Vulnerability: unless already provided through information disclosure, a final report shall be submitted within 14 days of the corrective or mitigating measures becoming available and contain at least the following information: (i) a description of the vulnerability, including its severity and impact; (ii) where available, information concerning the malicious actor that has exploited or that is exploiting the vulnerability; (iii) details about the security update or other corrective measures that have been made available to remedy the vulnerability.¹³

• Severe incident: unless already provided through information disclosure, a final report shall be submitted within one month from the date of submission of the 72-hour incident notification, containing at least the following information: (i) a detailed description of the incident, including its severity and impact; (ii) the type of threat or root cause that is likely to have triggered the incident; (iii) applied and ongoing mitigating measures.¹⁴

Intermediate reports (as needed)

• Vulnerabilities and severe incidents: the CSIRT designated as the coordinator initially receiving the notification may, where necessary, require the manufacturer to submit intermediate reports on the exploited vulnerability or the severe incident.¹⁵

(V) Notifying Users

In addition to reporting to regulators, once a manufacturer becomes aware that a vulnerability has been exploited or a severe incident has occurred, it must immediately notify the affected users and, where necessary, all users, informing them of the details of the vulnerability or incident and the risk-mitigation and corrective measures available to users; where appropriate, the information shall be published in a structured, machine-readable and easily processable (i.e., automatic) format. If the manufacturer fails to inform the users of the product with digital elements in a timely manner, the notified CSIRTs designated as coordinators may, observing the principle of proportionality and where necessary to prevent and mitigate the impact of that vulnerability or incident, directly issue notices to users.¹⁶

Where it is necessary to disclose information to the public in order to prevent or mitigate a severe incident affecting the security of digital products or to address an ongoing security incident, or where such disclosure serves the public interest, the CSIRT of the member state may, after consulting the manufacturer concerned and where necessary jointly with ENISA, notify the public of the incident or require the manufacturer to discharge its public-notification obligation.¹⁷

Once a security update or other corrective or mitigating measure is available, ENISA shall, in agreement with the manufacturer of the digital product concerned, add the reported and publicly disclosed vulnerability information into the European vulnerability database¹⁸ established under Article 12(2) of the NIS 2 Directive.¹⁹

Special Note: If a Chinese enterprise fails to notify users in a timely manner, the CSIRT’s direct disclosure to users may trigger a chain of consequences. First, brand and reputational risk (being ‘notified on behalf of’ by a foreign regulator exposes internal response failure); second, it may be out of step with the domestic disclosure obligations under China’s Regulations on the Administration of Cybersecurity Vulnerabilities of Network Products (《网络产品安全漏洞管理规定》) in terms of time windows. Enterprises are advised to consider the EU’s notification obligations and China’s reporting obligations in a coordinated manner when establishing internal notification processes, so as to avoid the misalignment of time windows.

(VI) Delayed Dissemination

In special circumstances, in particular at the request of the manufacturer and considering the information sensitivity indicated by the manufacturer under Article 14(2)(a) of the CRA, reporting may be delayed on justified cybersecurity grounds. The delay shall be strictly limited to what is necessary. Where the CSIRT decides to defer notification, it shall immediately inform ENISA of the decision, the reasons for the deferral, the expected reporting time and comply with the corresponding reporting procedures. ENISA may assist the CSIRT on the applicable cybersecurity grounds for delayed dissemination.²⁰ Note that the rules on delayed dissemination govern the CSIRT’s onward distribution to other CSIRTs after receipt, not the manufacturer’s reporting to the CSIRT. In other words, the manufacturer’s reporting obligation to the CSIRT is not relaxed; what is relaxed is the speed at which the information spreads to other member states.

Where the manufacturer indicates the following in notification referred to in Article 14(2)(b): (i) that the notified vulnerability has been actively exploited by a malicious actor and, according to the information available, it has been exploited in no other member state than the one the CSIRT designated as coordinator to which the manufacturer has notified the vulnerability; (ii) that any further dissemination of the notified vulnerability would likely result in the supply of information that the disclosure of which would be contrary to the essential interests of that member state; or (iii) that the notified vulnerability poses an imminent high cybersecurity risk stemming from the further dissemination — then, before fully transmitting the report to the CSIRT and ENISA, only the following may be simultaneously disclosed to ENISA: a notification was made by the manufacturer, the general information about the product concerned, the general nature of the exploit, and the information that security related grounds were raised. If ENISA determines, after assessment, that the risk poses a systemic risk to the EU’s unified market, it may urge the manufacturer to disseminate the full notification.²¹

III. Impact of the CRA on Chinese Enterprises Exporting to the EU and Compliance Recommendations

Chinese enterprises engaged in the EU market must comprehensively address the compliance challenges posed by the CRA. Enterprises should first determine the regulatory classification of their products, then strictly comply with incident reporting, risk disclosure and other requirements, and properly manage the reporting process. Externally, maintain regularized engagement with regulators; internally, build a complete compliance system and improve risk-response capabilities. The key implementation points are detailed below.

Determine whether the product falls within the scope of the CRA: The CRA’s regulatory reach is extremely broad. It essentially covers all connected hardware and software and digital products made available on the EU market including common categories such as consumer electronics, smart home, industrial control equipment and embedded software. The CRA also specifies statutory exemption categories that may be excluded by law — medical devices, in-vehicle equipment, aviation and marine equipment, dedicated products for defense and security, classified-information equipment and original-equipment replacement parts. Where sector-specific legislation already establishes security requirements of an equivalent or higher standard, the application of the CRA may be limited or exempted. For Chinese enterprises exporting overseas, the primary core task is to accurately complete the compliance classification of products and clarify their own regulatory status. Once it is confirmed that the product falls within the scope of the CRA, the enterprise becomes the primary party responsible for compliance; from the moment the product enters the EU market, it must fully comply with the full chain of statutory obligations such as vulnerability governance and incident reporting.

Determine the EU gateway, authorised representative, importer and preferred CSIRT: For Chinese enterprises without a main establishment in the EU (the vast majority of cases), the main-establishment determination rule means that the choice of authorised representative and importer carries the significance of fixing the regulatory focus. Enterprises are advised to confirm the EU authorised representative and principal importer, determine the preferred coordinator CSIRT and complete single-reporting-platform account registration, technical interfacing and a first drill as soon as possible.

Establish a vulnerability or incident awareness matrix: Integrate all possible vulnerability or incident gateways — external threat intelligence, CVD mailboxes, product telemetry alerts, customer support tickets and communications with security researchers — into a unified enterprise vulnerability-or-incident awareness matrix; set an original timestamp, a preliminary classification (ordinary vulnerability / exploitable vulnerability / actively exploited vulnerability / severe incident) and an escalation path for each record. This is the legal basis for the traceability of reporting deadlines.

Establish structural processes such as SBOM, a CVD policy and a single point of contact: Establish SBOM generation and maintenance processes and clarify internal access permissions and external disclosure policies for SBOM; formulate and publish a CVD policy externally, specifying the single point of contact, the reporting channels and the response commitments. The CVD policy should consider the reception pathways for reporters within China under the Provisions on the Management of Network Product Security Vulnerabilities and other regulations, so as to avoid any inconsistency between the external reception interface and the internal compliance interface.

Strictly execute the tiered time-limited reporting rules: Where a product presents an exploited vulnerability or severe incident, report to the CSIRT and ENISA through the single reporting platform, strictly observing the 24-hour early warning, 72-hour notification and 14-day (or 1-month) final-report deadlines, while cooperating with regulatory requirements to submit intermediate reports.

Standardize reporting and delayed-handling management: Enterprises must clearly understand the boundary between mandatory and voluntary reporting and pay particular attention to third-party reporting scenarios — vulnerabilities and security incidents reported by external parties will directly trigger the enterprise’s statutory handling obligations. For special cybersecurity scenarios, enterprises may apply for delayed dissemination in accordance with the rules, but this authority is tightly constrained: it may only be sought on justified security grounds, and the reasons for the deferral and the expected reporting deadline must be synchronously reported to ENISA; the minimal-reporting mechanism in extremely exceptional circumstances must be applied with particular prudence, and arbitrary delay in reporting or abuse of compliance-exemption authority is strictly prohibited.

Embed vulnerability coordination clauses: Embed compliance coordination clauses in contracts with upstream component suppliers, downstream distributors, authorised representatives and importers, specifying two-way vulnerability notification and collaborative remediation, deadlines for security-update distribution, confidentiality and regulatory assistance, allocation of penalty consequences and obligations to preserve technical documentation and provide cooperation.

Implement user and public disclosure obligations: When a vulnerability or security incident happens, the enterprise must immediately notify the affected users with the incident details, risk-mitigation plans and corrective measures, and proactively discharge its notification obligations. Where the enterprise is slow to act or respond and fails to complete the user notification in a timely manner, the corresponding regulator may directly disclose the incident information to the public. This may damage the enterprise’s overseas brand reputation and give rise to reputational risk.

Establish regularized official engagement mechanisms: Enterprises must proactively engage with ENISA, the CSIRTs of the member states where products circulate and the national market surveillance authorities; cross-border security incidents require coordinated handling with multiple regulators, and enterprises must accept regularized compliance reviews and sampling inspections.

Build an internal compliance system: Establish a dedicated response team, clarify the specialist positions for compliance, technology, overseas liaison and emergency response, and fix dedicated external points of contact; formulate a full set of internal systems covering vulnerability tiered handling, cross-border reporting, delayed-reporting approval and information disclosure, achieving process standardization and traceability. 

Regularized drills and product optimization: To reduce risk, enterprises must integrate CRA compliance requirements into product R&D, design and iteration processes at the source. They should conduct regularized full-process emergency drills covering vulnerability handling, cross-border reporting and user notification, and improve their vulnerability-patch delivery and post-market operation-and-maintenance service capabilities.

Conclusion and What’s Next in This Series

CRA compliance is now imminent. Chinese enterprises, regardless of the scale of their EU business, need to establish their vulnerability management and reporting systems and processes as soon as possible. We hope this series helps enterprises see mechanisms beyond the provisions and opportunities beyond compliance — the process of transforming mandatory obligations into long-term product competitiveness is the process by which Chinese digital products continue to rise in the global market.

In subsequent articles in this series, we will provide: a comprehensive overview of China’s regulatory system for cybersecurity vulnerabilities in network products, a special interpretation of China’s Regulations on the Administration of Cybersecurity Vulnerabilities of Network Products, and a horizontal comparative study of cybersecurity vulnerability management between China and Europe. 

*Yang Chen (intern) also contributed to this article

For further information, please contact:

LU, Sipei (Ryo), Partner, JunHe

lusp@junhe.com

---

[1] The full title of the Cyber Resilience Act is REGULATION (EU) 2024/2847 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) No 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act).

[2] See Article 71 of the CRA.

[3] See recitals 1–2 of the CRA.

[4] See recitals 1–2 of the CRA.

[5] See Article 2(1) of the CRA.

[6] See Article 2(2), (3), (4), (6) and (7) of the CRA.

[7] See Article 2(5) of the CRA.

[8] ENISA’s former name was the European Network and Information Security Agency, hence the abbreviation ENISA. Even when the name was changed to European Union Agency for Cybersecurity, the abbreviation ENISA was retained.

[9] See Article 14(2)(a) and Article 14(4)(a) of the CRA.

[10] See Article 14(4)(a) of the CRA.

[11] See Article 14(2)(b) and Article 14(4)(b) of the CRA.

[12] See Article 14(4)(b) of the CRA.

[13] See Article 14(2)(c) and Article 14(4)(c) of the CRA.

[14] See Article 14(4)(c) of the CRA.

[15] See Article 14(6) of the CRA.

[16] See Article 14(8) of the CRA.

[17] See Article 17(2) of the CRA.

[18] See Article 17(5) of the CRA.

[19] The full title of the NIS 2 Directive is Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union, amending Regulation (EU) No 910/2014 and Directive (EU) 2018/1972, and repealing Directive (EU) 2016/1148 (NIS 2 Directive).

[20] See Article 16(2) of the CRA.

[21] See Article 16(2) of the CRA.