A practical guide for companies shipping products with digital elements into the EU – including crypto-native, AI-native, and traditional enterprises
The EU Cyber Resilience Act (Regulation (EU) 2024/2847) is now law. It entered into force on 10 December 2024. Its main obligations apply from 11 December 2027 to products with digital elements made available on the EU market where the intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. Article 14 reporting obligations apply earlier, from 11 September 2026.
This is not a voluntary framework. It is a binding, horizontal EU product-cybersecurity regulation that applies across sectors to hardware, software, and separately marketed software or hardware components, subject to specific exclusions and role-based obligations for manufacturers, importers, distributors, authorised representatives, and certain other operators. Maximum administrative fines can reach €15 million or 2.5% of worldwide annual turnover, whichever is higher, for the most serious infringements.
At Hacken, we’ve spent eight years securing products at the intersection of Web3, fintech, and traditional infrastructure. Here’s what the CRA requires and what you need to do about it.
“If you sell hardware wallets, AI-enabled software, IoT devices, firmware, SDKs, or enterprise software into the EU, this applies to your pipeline now.”
What Is the EU Cyber Resilience Act?
The CRA is the EU’s first horizontal cybersecurity regulation for products with digital elements. Unlike NIS2 (which targets covered entities and the resilience of their network and information systems) or DORA (which targets financial-sector digital operational resilience), the CRA regulates the cybersecurity of products placed on the EU market and the obligations of the economic operators that make them available.
It creates mandatory cybersecurity requirements across the product lifecycle: secure design and development, vulnerability handling, security updates, user information, technical documentation, conformity assessment, and market surveillance. Products may be made available on the market only where the product and the manufacturer’s vulnerability-handling processes meet the essential cybersecurity requirements in Annex I.
If your offering is a pure cloud service with no software or hardware products and no manufacturer-controlled remote data processing solution that is necessary for a product function, the CRA may not apply directly – but NIS2 or sectoral rules may. Cloud or SaaS functionality is in CRA scope only where it meets the CRA definition of “remote data processing”, namely manufacturer-designed or manufacturer-responsible processing at a distance without which the product cannot perform one of its functions.
Key Dates – The Clock Is Already Running
The fixed dates matter more than a rolling countdown. As of July 2026, Chapter IV provisions on the notification of conformity assessment bodies are already applicable. Manufacturers should now treat Article 14 reporting readiness – which applies from 11 September 2026 – as the immediate priority, while using the remaining time before 11 December 2027 to complete product scoping, risk assessment, vulnerability-handling processes, technical documentation, and conformity-assessment planning.
Who Is Affected And How It Hits Different Industries
Crypto-Native Companies
Hardware wallets and custody devices should be assessed carefully against the CRA’s “core functionality” approach. They are products with digital elements where they combine hardware, firmware, and cryptographic software; however, their classification as default, Important, or Critical is not automatic. Depending on design and core functionality, a device may fall into an Important category (for example, hardware-based password managers or authentication hardware) or a Critical category (for example, hardware devices with security boxes or secure elements) if it meets the applicable technical description.
Beyond wallets, crypto-native companies should evaluate:
- HSMs and secure elements used in custody solutions – hardware security modules that generate and manage cryptographic elements may fall within the Critical “Hardware Devices with Security Boxes” description, while secure elements are expressly described under “Smartcards or similar devices, including secure elements.”
- Node hardware and mining devices – connected hardware placed on the EU market.
- Firmware and software updates for hardware products – the CRA requires vulnerabilities to be handled throughout the support period, which must generally be at least five years unless the product is expected to be used for less than five years, and may need to be longer where expected use is longer. Security updates must be provided without delay and, unless otherwise agreed for tailor-made business products, free of charge.
- Software libraries and SDKs distributed as standalone components – if a signing library, cryptographic SDK, or other software component is placed on the EU market separately during a commercial activity, it can be a product with digital elements in scope. Non-commercial free and open-source software and mere hosting/contribution activity are treated differently.
AI-Native Companies
AI systems that are embedded in products with digital elements must comply with the CRA. If your AI model ships inside a device, an application, or a software product, the CRA’s security-by-design and vulnerability handling requirements apply to the entire product – including the AI component.
For high-risk AI systems under the EU AI Act that are also products with digital elements, there is a convergence mechanism: the product is deemed to comply with the AI Act’s cybersecurity requirements where the CRA Annex I requirements and processes are fulfilled and the required cybersecurity protection is demonstrated in the CRA EU declaration of conformity.
In practice, AI-native companies should pay attention to:
- Model and software supply chain – the CRA requires manufacturers to take cybersecurity risks and product components into account. For AI products, focus due diligence on model-serving software, inference engines, libraries, APIs, remote processing functions, and other components or services needed for product functionality; treat datasets and model-update processes as part of the risk assessment where they can affect cybersecurity, rather than automatically calling every dataset a “component.”
- Update obligations – AI products that receive model updates, fine-tuning, or retraining are still under the CRA’s security update requirements.
- SBOM requirements – the CRA to draw up a software bill of materials in a commonly used and machine-readable format covering at least top-level dependencies. The CRA does not require publishing the full SBOM to all users by default; user-facing information is required only where the manufacturer decides to make the SBOM available to users.
Traditional Enterprises and Institutions
If your company manufactures, imports, distributes, or white-labels products with digital elements – such as industrial controllers, networking equipment, enterprise software, smart building systems, or medical-adjacent devices outside MDR/IVDR – you need to assess whether your role brings you into scope as a manufacturer, importer, distributor, or other economic operator.
The CRA also creates obligations for importers and distributors. Importers must ensure, among other points, that the manufacturer has carried out the relevant conformity assessment, drawn up technical documentation, and that the product bears the CE marking. Distributors must verify key compliance indicators such as CE marking and required manufacturer/importer information before making products available.
Product Classification – This Determines Your Compliance Path
For Important Class I products, self-assessment under internal control is available where the manufacturer fully applies relevant harmonised standards, common specifications, or applicable European cybersecurity certification schemes. If those do not exist or are not fully applied, the product and processes must go through EU-type examination plus internal production control or full quality assurance. Harmonised standards are being developed under Commission standardisation request M/606; technical product-category descriptions were separately adopted in Implementing Regulation (EU) 2025/2392.
Essential Cybersecurity Requirements – What to Build
Security by Design (Annex I, Part I)
Vulnerability Handling (Annex I, Part II)
Reporting Obligations – The 24-Hour Rule
Starting 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents having an impact on product security via the CRA Single Reporting Platform, addressed to the relevant CSIRT designated as coordinator and made accessible to ENISA.
- Within 24 hours – early warning of any actively exploited vulnerability in the product.
- Within 72 hours – vulnerability notification with available details on the nature of the exploit.
- Within 14 days after a corrective or mitigating measure is available – final report for actively exploited vulnerabilities. For severe incidents, the final report is due within one month after the 72-hour incident notification.
This is similar in structure to NIS2-style staged reporting, but it applies specifically to manufacturers of products with digital elements. If a manufacturer becomes aware of an actively exploited vulnerability or severe product-security incident and misses the applicable notification requirements, it risks breaching Article 14.
Fines – What Non-Compliance Costs
For startups and SMEs, the statutory maxima remains significant, but the final penalty is not automatic. Member States set penalty rules, and authorities must consider the specific circumstances, including the size and market share of the economic operator, especially for microenterprises, SMEs, and start-ups. The Commission’s implementation summary also notes that manufacturers qualifying as microenterprises or small enterprises may not be fined for failures to meet the 24-hour reporting deadline.
Market surveillance authorities can also require operators to end non-compliance and may prohibit, restrict, withdraw, or recall products where necessary, which for many companies may be a more immediate commercial threat than the administrative fine itself.
Implementation Checklist for CISOs
1. Product Scoping & Classification
2. Security by Design
3. Vulnerability Handling
4. Reporting & Documentation
5. Lifecycle & Governance
ISO 27001 Overlap – What You Already Have and What’s New
For organizations already certified or working toward ISO 27001:2022, significant overlap exists. But the CRA goes further in several areas. Here’s the mapping:
ISO 27001 gives you a strong governance and control foundation that will make CRA compliance easier – especially around risk management, access control, cryptography, secure development, supplier relationships, and incident handling. But ISO 27001 certification does not equal CRA compliance. The CRA’s product-level cybersecurity risk assessment, SBOM, support-period commitments, mandatory CRA reporting, secure-update obligations, EU declaration of conformity, CE marking, and conformity assessment are separate CRA obligations.
Organizations running both programmes should integrate them: use ISO 27001’s ISMS as the governance layer, and layer the CRA’s product-specific requirements on top as product security, vulnerability-handling, documentation, reporting, and conformity-assessment controls.
How Hacken Helps
Since 2017, Hacken has secured 1,500+ Web3 projects and built deep expertise in product security across hardware, firmware, smart contracts, and software supply chains. Our team combines product security engineering with compliance implementation experience across EU and GCC regulatory frameworks.
We help manufacturers and product companies navigate the CRA through:
- CRA Scoping & Product Classification – identify which of your products are in scope and which conformity assessment path each requires.
- Product Security Assessments – evaluate your products against Annex I essential requirements, including threat modelling and attack surface analysis.
- Vulnerability Handling Programme – build the CVD policy, vulnerability management process, and ENISA reporting procedures.
- Secure Development Advisory – embed CRA requirements into your SDLC, code review, and release processes.
- Conformity Assessment Preparation – prepare technical documentation and evidence for self-assessment or third-party examination.
