Practically the CRA transforms product security from a best practice into an auditable lifecycle requirement:

• manufacturers must be able to issue an early warning within 24 hours of becoming aware of an actively exploited vulnerability, 
• provide fuller notifications within the short statutory windows, 
• submit reports via the single reporting platform to be operated by ENISA, and 
• maintain machine-readable Software Bill of Materials (SBOM) and similar evidences which can be audited by the regulator.

These requirements are not optional engineering add-ons but legally significant controls that force trade-offs across legacy portfolios, third-party dependencies and supplier contracts. 

Nearly every connected product with digital elements falls under the Act. 

• Check for any commercial product with hardware or software that can connect directly or indirectly to a network 
• Confirm your product is not a device already covered under other legislations (e.g. medical devices) 
• Exclude only purely non-commercial open-source software delivered without revenue intent and assess the rest 

Deloitte recommends a structured, three-year path to full CRA compliance:

• Phase 1: Inventory products, analyse gaps and secure budget
• Phase 2: Integrate security-by-design, generate SBOMs and prepare technical files 
• Phase 3: Operationalise 24-hour incident reporting and long-term patch support 

Based on client discussions, we see the following three high-effort requirements:

• Generate and maintain a continuously updated, machine-readable SBOM for every release. This also includes securing and documenting the full hardware-and-software supply chain. 
• Implement 24-hour vulnerability-management and incident-reporting processes that include legal and comms teams 
• Perform self-assessment and gather needed evidences
   

The route to the CE mark depends entirely on product risk classification. 

• Default category products self-assess against the technical file and sign an EU Declaration 
• Class I “Important” products may self-assess only if they follow harmonised standards 
• Class II “Critical” products require a notified-body audit with no self-assessment option 

For each product, a complete technical file needs to be maintained that authorities can request at any time. The self-assessment needs to be treated as a legally binding process, not a tick-the-box exercise.

 CRA obligations overlap with several sector-specific cybersecurity EU laws. 

• NIS 2 for operators of essential and important services 
• DORA within the financial sector
• MDR/IVDR for medical devices (which are out of scope of the CRA)
• CRA can issue delegated acts and for lex-specialis guidance to further clarify the interrelationship with NIS2 and DORA.