Search every question across sub-FAQs

Not completely. Draft CRA 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 draft 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.

From 26 March 2027, 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. In that case, both sets of substantive requirements can apply. 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.

From that date, for the EHR-system scenario covered by CRA Article 32(5a), the EHDS conformity-assessment procedure governs instead of a separate CRA procedure. The manufacturer should record the product's classification under both laws, the combined requirement map, the evidence used for each requirement, and the single EU declaration of conformity required when 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. Draft CRA 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.