In the first and second posts of our CRA series, we examined the scope of the Cyber Resilience Act (Regulation (EU) 2024/2847, the CRA) and the substantive requirements it imposes across the lifecycle of products with digital elements (PDEs).
This third and final post focuses on two practical aspects of CRA compliance: (1) supervision and enforcement, and (2) the interaction of the CRA with other EU regulatory regimes.
Market surveillance and enforcement
Assessing the practical implications of the CRA requires understanding how it will be supervised and enforced. This will occur primarily at national level. Each Member State must designate one or more market surveillance authorities (MSAs) responsible for monitoring CRA compliance on its territory (Article 52 CRA). These authorities operate under the existing horizontal framework of the Market Surveillance Regulation (Regulation (EU) 2019/1020), which provides the procedural basis for inspections, information requests, and corrective measures.
How enforcement starts
MSAs can act on their own initiative, on the basis of consumer complaints or following information received from the European Union Agency for Cybersecurity (ENISA) or the Commission. Article 53 CRA gives MSAs broad rights to access technical documentation, and any other data needed to assess compliance. Economic operators (whether manufacturers, importers, or distributors) are required to cooperate.
The national procedure
Where an MSA has sufficient reason to consider that a PDE presents a significant cybersecurity risk, it carries out a formal compliance evaluation. That assessment covers both technical and non-technical risk factors. If the MSA concludes that the PDE does not comply with the CRA, it can require the economic operator to take corrective action within a period defined by the MSA, proportionate to the cybersecurity risk. Corrective action may include bringing the PDE into conformity, withdrawing it from the market, or recalling it.
If the economic operator fails to take corrective action within the deadline set by the MSA, the MSA can itself prohibit, restrict, withdraw, or recall the PDE.
Escalation to EU level
If an MSA believes that a PDE’s non-compliance is not limited to its own territory, it must inform the Commission and all other Member States. The CRA provides EU-level escalation mechanisms.
First, where an MSA has taken a measure against a PDE — such as prohibiting or withdrawing it from the market — another Member State may object within three months, or the Commission may consider the measure contrary to EU law. This triggers the so-called “Union safeguard procedure” (Article 55 CRA). The Commission then evaluates the national measure and must decide within nine months whether it is justified. If it is, all Member States must withdraw the non-compliant product from their markets. If it is not, the originating Member State must withdraw its measure.
Separately, the Commission can intervene on its own initiative where MSAs have failed to take effective measures. In circumstances justifying immediate intervention to preserve the internal market, the Commission may carry out its own compliance evaluation and may request ENISA’s support. It may then adopt corrective or restrictive measures at EU level by implementing act (Article 56 CRA). This is the most centralised enforcement tool under the CRA. However, the absence of specific deadlines for this procedure leaves some uncertainty about how quickly the Commission would act in practice.
Compliant products that still pose a risk
The CRA also addresses cases where a product is formally compliant but nonetheless presents a significant cybersecurity risk – for instance, a risk to the health or safety of persons, to fundamental rights, or to the security of essential entities under the NIS 2 Directive (Directive (EU) 2022/2555 – NIS 2). In that case, the MSA may still require the economic operator to take corrective actions, and the same escalation path to the Commission applies.
Sweeps
Finally, the CRA also enables MSAs to conduct simultaneous, coordinated control actions – known as “sweeps” – targeting particular product categories (Article 60 CRA). The Commission typically coordinates these actions. ENISA can propose product categories for sweeps, based on vulnerability and incident data it receives via the single reporting platform (namely the centralised platform through which manufacturers report actively exploited vulnerabilities and severe incidents). Sweeps may include test purchases under a cover identity.
Penalties
Article 64 CRA sets out the penalty framework. Member States must lay down national rules on administrative fines, structured in three tiers.
- The highest tier applies to non-compliance with the essential cybersecurity requirements (Annex I) and the core manufacturer obligations under Articles 13 and 14: fines of up to EUR 15 million or 2.5% of total worldwide annual turnover.
- The second tier covers other CRA obligations, including those of importers and distributors and in relation to conformity assessment: up to EUR 10 million or 2% of total worldwide annual turnover.
- The third tier applies to the supply of incorrect, incomplete, or misleading information to authorities or notified bodies: up to EUR 5 million or 1% of total worldwide annual turnover.
In each case, the higher of the two amounts applies, and the turnover threshold is calculated on the basis of the preceding financial year. When determining the amount of a fine, MSAs must take into account factors including the nature, gravity, and duration of the infringement and the size and market share of the economic operator.
Interaction with other EU regimes
The CRA does not operate in isolation. Several other EU instruments impose cybersecurity, data protection, or incident reporting obligations that may apply concurrently to the same product or the same economic operator. Understanding these interactions is important both for compliance planning and for avoiding duplication in internal processes.
CRA and NIS 2
The CRA and NIS 2 overlap in their subject matter but differ in their regulatory approach: the CRA applies to products, requiring manufacturers to build in cybersecurity by design and to handle vulnerabilities throughout the support period. NIS 2 applies to certain categories of entities and imposes organisational cybersecurity risk management and incident reporting obligations on them.
The two regimes intersect in practice. Entities in several NIS 2 sectors, such as digital infrastructure or manufacturing (which covers, among others, manufacturers of medical devices, computer and electronic products, and electrical equipment), will regularly manufacture or use PDEs that fall within the scope of the CRA. The cybersecurity of those products directly affects the entity's overall risk posture. The CRA acknowledges this: Recital 125 notes that the CRA aims to facilitate compliance of NIS 2 entities, in particular digital infrastructure providers, with their supply chain security obligations, by ensuring that the PDEs they use are developed securely.
CRA and the GDPR
The CRA applies without prejudice to the GDPR (Regulation (EU) 2016/679), as stated in Recital 32 CRA. The CRA’s essential cybersecurity requirements – which include obligations related to confidentiality, integrity, and access control – reinforce and partly overlap with the security of processing obligations under Article 32 GDPR.
CRA and the Product Liability Directive
Organisations should also consider liability exposure under the new Product Liability Directive (Directive (EU) 2024/2853), which complements the CRA. The Directive, to be transposed by Member States by 9 December 2026, provides that manufacturers - and, in certain cases, other operators in the supply chain - may face strict liability (irrespective of fault) where a defective product, including one with cybersecurity shortcomings, causes damage.
A product that fails to meet the CRA's essential cybersecurity requirements could therefore give rise both to regulatory enforcement under the CRA and to civil liability under the Product Liability Directive. As Member States prepare transposition, organisations should monitor national transpositions to assess the full scope of their liability exposure.
CRA and the AI Act
PDEs that incorporate artificial intelligence may fall within the scope of both the CRA and the AI Act (Regulation (EU) 2024/1689). The CRA recognises this overlap. High-risk AI systems that qualify as PDEs must comply with the CRA’s essential cybersecurity requirements, and their cybersecurity risk assessment must take into account AI-specific risks such as data poisoning and adversarial attacks (Recital 51 CRA). A PDE that meets the CRA's essential cybersecurity requirements is deemed to satisfy the AI Act's cybersecurity requirements, to the extent demonstrated in the EU declaration of conformity issued under the CRA.
Some overlap at the level of conformity assessment procedures remains possible, particularly for PDEs classified as important or critical under the CRA that also qualify as high-risk AI systems under the AI Act.
The Digital Omnibus on AI — one of two legislative proposals in the Commission's Digital Omnibus Package of 19 November 2025 — would address this. Negotiations between the European Parliament and the Council are advancing rapidly, with both institutions having adopted their respective positions in March 2026. Both positions point towards making the CRA conformity assessment the primary procedure for AI systems that also qualify as PDEs and establishing that compliance with the CRA's essential cybersecurity requirements would satisfy the AI Act's cybersecurity requirements, to the extent they are covered by the CRA declaration of conformity. If adopted, this would go a long way towards addressing the overlap in conformity assessment procedures.
Looking ahead: simplification and consolidation
A recurring practical difficulty is the overlap in incident and data breach reporting obligations. The CRA, NIS 2, and the GDPR each impose their own notification requirements, as do sector-specific instruments such as DORA (financial services), the CER Directive (critical entities), and eIDAS (trust services). Triggers, timelines, recipients, and information requirements differ across all of these. In practice, the most common overlaps will arise between the CRA, NIS 2, and the GDPR. For example, a cloud service provider that develops its own platform software and suffers a breach through an actively exploited vulnerability exposing customer personal data would face three parallel obligations: notification to ENISA and the relevant CSIRT under the CRA, incident reporting to its competent authority under NIS 2, and a personal data breach notification to the supervisory authority (and potentially to affected individuals) under the GDPR.
A separate proposal in the Digital Omnibus Package would address this. It proposes amendments to several EU instruments, including NIS 2 and the GDPR, and includes the creation of a single-entry point for incident and data breach reporting. The single-entry point, to be developed and operated by ENISA, would allow organisations to satisfy reporting obligations under NIS 2, the GDPR, DORA, the CER Directive, and eIDAS through a single secure interface, building on the CRA's existing single reporting platform. Under the proposal, a severe incident notification filed under the CRA could also satisfy NIS 2 reporting requirements, provided it contains the required information.
***
Both the Digital Omnibus and the Digital Omnibus on AI are subject to the ordinary legislative procedure and may still change. Organisations should monitor these developments, but should not delay CRA compliance planning on the assumption that the reporting and compliance landscape will be simplified in time.