Cyber Resilience Act FAQ Interplay With EU Product Laws

No. The CRA adds horizontal cybersecurity requirements for products with digital elements; it does not generally replace product safety, radio equipment, machinery, vehicle, aviation, marine, or other Union product rules.

The practical question is whether the other law merely overlaps with the CRA, or whether the CRA itself excludes the product. If the CRA is not excluded, the manufacturer should expect to demonstrate compliance with each applicable framework, even where the same engineering evidence supports more than one requirement.

Start with Article 2, not with a broad assumption that sector rules displace the CRA. Article 2 excludes some products directly, including products covered by the medical-device and in vitro-diagnostic frameworks, products covered by Regulation (EU) 2019/2144, certified aviation products under Regulation (EU) 2018/1139, and marine equipment within Directive 2014/90/EU.

Then check delegated acts under Article 2(5). The Commission FAQ identifies Delegated Regulation (EU) 2025/1535 as excluding products within Regulation (EU) No 168/2013 on two- or three-wheel vehicles and quadricycles, except L1e category vehicles designed to pedal. Outside those exclusions and delegated acts, the existence of another EU product law with cybersecurity provisions is not enough by itself to switch off the CRA.

For radio equipment categories covered by Delegated Regulation (EU) 2022/30, the Commission FAQ describes a transition by placement date. RED cybersecurity requirements apply to covered radio equipment placed on the market from 1 August 2025 through 10 December 2027.

For the same categories placed on the market on or after 11 December 2027, the CRA applies for the relevant cybersecurity requirements. Commission Delegated Regulation (EU) 2026/339 repeals Delegated Regulation (EU) 2022/30 with effect from that date. Its recital 5 preserves RED market-surveillance control for covered radio equipment placed on the EU market from 1 August 2025 through 10 December 2027.

Yes, but only for the cybersecurity risks that the RED certificate or approval decision actually covers, and only within the Article 69(1) validity rule.

Article 69(1) keeps EU type-examination certificates and approval decisions issued for cybersecurity requirements under other Union harmonisation legislation valid until 11 June 2028, unless they expire earlier or that other legislation provides otherwise. The July 2026 Commission guidance explains that this does not equal full CRA compliance. It allows the manufacturer to rely on the certificate as evidence for already covered risks, while still performing the CRA cybersecurity risk assessment and addressing additional CRA risks such as vulnerability handling or attack-surface reduction where they are not covered by the RED certificate.

A connected machine can be subject to both regimes. The Machinery Regulation addresses essential health and safety requirements for machinery and related products, including cybersecurity-related safety requirements. The CRA addresses cybersecurity requirements for products with digital elements.

The Commission FAQ says a manufacturer of a product covered by both the CRA and the Machinery Regulation must comply with both. Compliance with one framework is not automatically compliance with the other, although the same technical measures, standards work, or risk analysis may support both where the manufacturer can show that the relevant requirements are actually covered.

Not completely. July 2026 Commission guidance applies the Article 69(1) rule to certificates or approval decisions issued for cybersecurity-related Machinery Regulation requirements. Those certificates can remain useful evidence for the covered cyber-safety risks during the Article 69(1) period.

The manufacturer still needs the CRA cybersecurity risk assessment. If that assessment identifies additional CRA risks not covered by the machinery certificate, those gaps must be assessed and mitigated under the CRA. The adopted Commission guidance gives Machinery Regulation examples tied to protection against corruption and the safety and reliability of control systems, but it treats them as covered-risk examples, not as a blanket CRA exemption.

The CRA and GPSR cover different risk categories. The CRA addresses cybersecurity risks for products with digital elements. The GPSR remains relevant for consumer-product safety aspects and risks that the CRA does not cover, unless those aspects are already governed by more specific Union harmonisation legislation.

For a connected consumer product, this means the CRA can govern cybersecurity while the GPSR can still matter for safety issues outside the CRA's cybersecurity scope. The correct analysis is by risk and product framework, not by choosing one law as the only applicable regime.

The CRA complements Directive (EU) 2022/2555, known as the NIS2 Directive, and the EU Cybersecurity Act; it does not replace either framework. The CRA sets product-level cybersecurity requirements for products with digital elements. NIS2 imposes cybersecurity risk-management and reporting duties on covered entities, including supply-chain security, while the Cybersecurity Act provides the framework for European cybersecurity certification schemes.

A NIS2 entity can use CRA conformity and support information as supply-chain evidence, but it must still perform its own NIS2 risk assessment. A European cybersecurity certificate can support CRA conformity only where the CRA, an implementing or delegated act, or the applicable conformity route gives it that effect for the covered requirements.

Keep the product and entity workstreams connected but separate. CRA records follow the product with digital elements: product risk assessment, secure design, vulnerability handling, support, Article 14 reports, conformity, and market-surveillance action. NIS2 records follow the covered entity's network and information systems, operations, supply chain, management accountability, and incident handling under national transposition.

One event can open both tracks. For example, exploitation of a vulnerability in a manufacturer's connected product may require CRA reporting by the product manufacturer and NIS2 incident analysis by a covered manufacturing, cloud, managed-service, health, energy, transport, or digital-infrastructure entity. Each owner should apply the threshold, recipient, clock, and evidence rules of the relevant regime rather than treating one submission as automatically completing the other.

Where European Digital Identity Wallets fall within the CRA's product scope, the CRA and the eIDAS framework both apply. The wallet provider must address the CRA's horizontal essential cybersecurity requirements and the wallet-specific security requirements in Article 5a of Regulation (EU) No 910/2014.

CRA recital 33 explains that a European cybersecurity certification scheme may help demonstrate compliance with both frameworks where the Commission has specified a presumption of conformity. That effect is limited to the requirements the scheme and presumption actually cover; it is not a general exemption from either framework.

No. The CRA regulates the cybersecurity of products with digital elements placed on the Union market. The General Data Protection Regulation (GDPR) regulates personal-data processing by controllers and processors. The same security measure may support both regimes, but a CRA declaration, certificate, or CE marking does not prove that processing has a lawful basis, meets transparency and data-subject-rights duties, or satisfies the GDPR's other requirements.

Keep the evidence mapping separate: identify which product-security control supports a CRA requirement and which GDPR processing risk or Article 32 measure it also supports. Do not treat either assessment as a substitute for the other.

A product can be both a product with digital elements under the CRA and an electronic health record system under the European Health Data Space Regulation. Where both regimes apply, it must meet both sets of substantive requirements. The CRA cybersecurity risk assessment may form part of the EHDS risk assessment, but the combined record must still show how each framework's requirements are met.

CRA Article 32(5a), inserted by the EHDS Regulation, coordinates the conformity route for that overlap by providing for the EHDS procedure instead of a separate CRA procedure. Check each Regulation's application and transitional provisions before deciding when that route and the underlying product duties apply; the EHDS amendment date is not a blanket start date for every EHR-system obligation. Record the classifications under both laws, the requirement map, the evidence used for each requirement and the single EU declaration of conformity required where several applicable Union acts require one.

The two instruments have different jobs. The CRA imposes ex ante cybersecurity duties on manufacturers and other economic operators before and after a product is placed on the market. The Product Liability Directive governs compensation when a defective product causes covered damage.

CRA non-compliance does not automatically decide every product-liability issue, and CRA conformity does not eliminate possible liability. Security-update availability, the support period, known vulnerabilities, user instructions, and corrective action can still be relevant evidence when defectiveness and damage are assessed under the liability regime.

The Commission FAQ frames the CRA and Data Act as different in nature. The CRA concerns placing products with digital elements on the market and meeting cybersecurity requirements. The Data Act concerns making product data and related service data available to users or third parties.

Where both apply, Data Act access obligations can be relevant to the CRA cybersecurity risk assessment. The FAQ says manufacturers should take those obligations into account when assessing intended purpose, reasonably foreseeable use, product environment, and risks connected to making data available. That is a risk-assessment input, not a general statement that Data Act compliance equals CRA compliance or that every legacy product must be redesigned solely because of the Data Act.

Article 12 applies when the same product is both a product with digital elements under the CRA and a high-risk AI system under the AI Act. CRA conformity satisfies the AI Act's Article 15 cybersecurity requirement only for the requirements covered by the CRA EU declaration of conformity. It does not establish compliance with the AI Act's other requirements.

The AI Act conformity-assessment procedure normally governs the covered cybersecurity requirements. Article 12(3) preserves stricter CRA treatment where an important or critical CRA product would otherwise use an AI Act procedure based on internal control: the manufacturer must use an applicable CRA route, including third-party assessment where Article 32 requires it. Record the product classifications under both laws, the requirement mapping, the selected procedure, and which body has authority for the combined assessment.

Yes, where more than one Union act requiring an EU declaration of conformity applies to the same product. Article 28(3) requires a single EU declaration of conformity in that situation, containing all information needed to identify the Union acts concerned.

This does not reduce the substance of the obligations. A single declaration is an administrative coordination mechanism; the manufacturer still needs evidence that each listed Union act's applicable requirements are met.

Often yes, if it is structured to prove each law's requirements. Article 31(3) requires a single technical-documentation set for products covered by Article 12 where other Union acts also require technical documentation. Article 13(4) also allows the CRA cybersecurity risk assessment to be part of a risk assessment required by other applicable Union law.

The Commission FAQ adds the important limit: manufacturers may use a single risk assessment covering different legislations or separate assessments, but they must be able to demonstrate compliance with each individual legislation. A combined file is therefore useful only if it maps each requirement, risk, standard, test result, certificate, and residual gap to the specific law it is meant to support.

No. The component analysis depends on whether the component itself falls within the exclusion or is designed and marketed more broadly.

The Commission FAQ says components intended for certified aviation products may still be covered where the component itself is not certified under Regulation (EU) 2018/1139. It gives similar logic for components intended for marine equipment where the component itself is not within Directive 2014/90/EU. July 2026 Commission guidance adds that components designed and constructed exclusively for integration into excluded vehicle frameworks can be outside the CRA, while generic components or components sold through channels beyond that supply chain can remain in scope.

No. Products described as dual-use products because they have civilian and defence or national-security applications remain subject to the CRA unless a specific exclusion applies.

Article 2 excludes products developed or modified exclusively for national-security or defence purposes and products specifically designed to process classified information. A manufacturer relying on either exclusion should document the product's intended purpose, design or modification history, market channel, and the facts that make the exclusive-purpose or classified-information test apply.

Keep an overlap matrix that starts with the product, intended purpose, reasonably foreseeable use, market channel, and each potentially applicable Union act. Record whether the product is excluded under CRA Article 2 or a delegated act, or whether the CRA applies alongside the other law.

For overlap cases, keep a requirement-to-evidence map showing the CRA Annex I requirement, the other law's corresponding requirement, the risk assessment section, standard or technical specification used, test result, certificate or approval decision, declaration entry, and any uncovered CRA risk. For Article 69 reliance, identify the issuing framework, certificate or approval decision, covered cybersecurity risks, expiry or Article 69 end date, and the CRA gaps that still require mitigation.