A manufacturer should map each product against the CRA and every other relevant Union act separately. Start with CRA Article 2 exclusions and limitation mechanisms, then identify overlapping product-safety, liability, privacy, data, machinery and sector-specific rules. Reuse consistent product, architecture, risk and test evidence where appropriate, but keep the legal conclusions distinct because compliance with one act does not automatically establish compliance with another.
The CRA Is Product Cybersecurity Legislation, Not the Entire EU Product-Law System
The CRA sets cybersecurity requirements for products with digital elements, manufacturer vulnerability-handling duties, conformity-assessment rules and market-surveillance mechanisms. A connected product can simultaneously raise physical safety, privacy, data-access, civil-liability, sectoral or machinery questions governed by other Union law. Product teams should therefore treat the CRA as one regulatory layer in a broader product compliance architecture.
Start With CRA Article 2 Scope and Express Exclusions
Article 2 expressly excludes several categories from the CRA, including products with digital elements to which the Medical Device Regulation, In Vitro Diagnostic Medical Devices Regulation and Regulation (EU) 2019/2144 on motor-vehicle type approval apply, as well as certain aviation-certified products and marine equipment. These are product-scope exclusions, not general statements that every sector-specific law displaces the CRA.
Article 2 Can Also Limit CRA Application Where Other Union Rules Cover the Same Risks
CRA Article 2 also allows the application of the Regulation to products covered by other Union rules to be limited or excluded where those rules impose requirements addressing all or some Annex I cybersecurity risks and the limitation or exclusion is consistent with the overall regulatory framework. Teams should therefore distinguish an express statutory exclusion from a later limitation adopted through the CRA mechanism.
Some EU Laws Apply Alongside the CRA Because They Regulate Different Questions
The Product Liability Directive addresses compensation for damage caused by defective products. The GDPR governs personal-data processing. The Data Act governs specified rights and obligations around access to and use of data. These regimes can interact with cybersecurity facts without becoming substitutes for CRA product-security obligations.
Product Safety and Cybersecurity Can Intersect
Cybersecurity failures can create physical or consumer-safety consequences. The General Product Safety Regulation expressly recognises appropriate cybersecurity features as part of product-safety assessment where malicious external influence could affect safety. The CRA can therefore supply a dedicated cybersecurity layer while safety law continues to address whether a consumer product is safe.
Product Liability Is a Different Legal Layer
Directive (EU) 2024/2853 treats software as a product and makes safety-relevant cybersecurity requirements one factor in assessing defectiveness. It also recognises defects linked to software updates and failures to provide safety-critical software updates where those matters remain within the manufacturer's control. CRA compliance can therefore become relevant evidence in a liability dispute, but CRA conformity does not create an automatic immunity from product-liability claims.
Sector-Specific Product Laws Need Their Own Applicability Analysis
Medical devices, in-vitro diagnostics, motor vehicles, machinery and other regulated product categories have their own scope, safety, documentation and conformity systems. The CRA does not create one universal rule for how every sectoral regime interacts with cybersecurity. Manufacturers should map the exact product, legal act, covered risks and any CRA exclusion or coordination rule.
Multiple Union Acts Can Contribute to One CE-Marked Product
A product can be subject to more than one Union harmonisation act requiring CE marking. In those cases the manufacturer should identify every applicable act, perform the required assessment under each, coordinate technical evidence and draw up the declaration correctly. One CE mark on the product does not mean only one legal act was assessed.
Shared Evidence Does Not Mean Shared Legal Tests
Architecture diagrams, software inventories, threat models, test reports, supplier records and change-control evidence can support several legal workstreams. Reuse can reduce duplication, but the same document may need to answer different legal questions under the CRA, safety law, privacy law or liability analysis. Preserve act-specific reasoning rather than copying one conclusion everywhere.
Build a Product-Level Regulatory Applicability Matrix
For each product, record the potentially applicable Union acts, scope conclusion, exclusion or overlap basis, regulated risks, responsible team, conformity route, documentation set and review trigger. This prevents a product from being treated as CRA-only merely because cybersecurity is the most visible current project.
Keep Regulatory Change Management Centralised
The surrounding framework is not static. Product classification, harmonised standards, guidance, sector-specific rules and implementation measures can change. A central regulatory register should identify which products are affected and whether the change alters CRA scope, another legal regime or the way evidence can be shared across both.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.