What Is the EU Cyber Resilience Act? A Complete Guide for 2026
The EU Cyber Resilience Act (CRA) is the most significant piece of cybersecurity legislation to come out of Europe since GDPR. It establishes mandatory cybersecurity requirements for all products with digital elements sold in the EU market — and the first compliance deadline is September 11, 2026.
If you manufacture, import, or distribute software or connected hardware in Europe, the CRA applies to you. Here is what you need to know.
What Is the Cyber Resilience Act?
The Cyber Resilience Act (Regulation 2024/2847) is an EU regulation that requires manufacturers of products with digital elements to meet essential cybersecurity requirements throughout the entire product lifecycle. Unlike previous EU cybersecurity frameworks that focused on critical infrastructure (such as NIS2), the CRA targets the products themselves.
The regulation was published in the Official Journal of the European Union on November 20, 2024, and entered into force on December 10, 2024.
Who Does the CRA Apply To?
The CRA applies to three groups:
Manufacturers — anyone who develops or produces products with digital elements, whether hardware or software. This includes companies that develop commercial software, IoT device makers, firmware developers, and industrial control system vendors.
Importers — entities that bring products with digital elements into the EU market from outside the EU. Importers must verify that the manufacturer has met CRA requirements before placing the product on the market.
Distributors — companies that make products available on the EU market without being the manufacturer or importer. Distributors must verify that the product bears the CE marking and that required documentation is available.
If your product is used by customers in the EU, the CRA likely applies to you regardless of where your company is based.
What About Open Source?
The CRA includes specific provisions for open source software. Non-commercial open source projects maintained by individuals or foundations are generally exempt from the full manufacturer obligations. However, the CRA introduces a new category called open source steward for foundations and organizations that systematically support open source development.
Open source stewards have lighter obligations focused on cybersecurity policy, vulnerability handling, and cooperation with market surveillance authorities. Commercial products that incorporate open source components remain fully subject to CRA requirements — the manufacturer is responsible for the security of all components, including open source dependencies.
What Are the Key Requirements?
The CRA defines essential cybersecurity requirements in Annex I, organized into two sections:
Security Requirements (Annex I, Section 1)
Products must be designed, developed, and produced to ensure an appropriate level of cybersecurity. Key requirements include:
Products must be delivered without known exploitable vulnerabilities
Products must be shipped with secure default configurations
Products must protect against unauthorized access
Products must ensure confidentiality and integrity of data
Products must minimize the impact of security incidents
Products must support security updates throughout their expected lifetime
Vulnerability Handling Requirements (Annex I, Section 2)
Manufacturers must implement processes to handle vulnerabilities effectively:
Identify and document product vulnerabilities, including in third-party components
Create and maintain a Software Bill of Materials (SBOM) — see our guide on how to generate an SBOM
Address and remediate vulnerabilities without delay
Apply regular security testing
Publicly disclose fixed vulnerabilities with advisories
Share information about fixed vulnerabilities with affected users
What Is the SBOM Requirement?
One of the most discussed CRA requirements is the mandate to create and maintain a Software Bill of Materials (SBOM). An SBOM is a machine-readable inventory of all software components in a product, including third-party libraries and open source dependencies.
The CRA requires that SBOMs be created in a commonly used, machine-readable format. The two most widely adopted formats are:
CycloneDX — maintained by OWASP, optimized for security use cases
SPDX — maintained by the Linux Foundation, widely used in supply chain management
The SBOM must cover at minimum the top-level dependencies of the product. It must be kept up to date as the product evolves.
What Are the ENISA Reporting Obligations?
When manufacturers become aware of an actively exploited vulnerability in their product, they must report it to ENISA (the EU Agency for Cybersecurity) through a dedicated reporting platform. The reporting follows a three-stage process:
24-hour early warning — within 24 hours of becoming aware of the actively exploited vulnerability, the manufacturer must submit an early warning notification to ENISA
72-hour incident notification — within 72 hours, a more detailed notification including a general description of the vulnerability, initial assessment, and any corrective measures taken or planned
14-day final report — within 14 days, a final report including details of the vulnerability, severity assessment, information about affected products, and corrective measures applied
These reporting timelines are strict and begin from the moment the manufacturer becomes aware of the active exploitation — not from the moment of discovery of the vulnerability itself.
Product Classification: Default, Important, and Critical
The CRA categorizes products into three classes based on their risk profile:
Default category — the majority of products with digital elements. These require self-assessment by the manufacturer and must meet all essential requirements.
Important products (Annex III) — products with higher cybersecurity risk, divided into two classes. Class I includes identity management systems, VPNs, network management tools, SIEM systems, and boot managers. Class II includes hypervisors, container runtimes, firewalls, intrusion detection systems, microcontrollers, and industrial automation systems.
Critical products (Annex IV) — the highest risk category, including hardware devices with security boxes, smart meter gateways, and other products essential for critical infrastructure.
Important and critical products face stricter conformity assessment procedures, potentially requiring third-party audits and certification.
Key Deadlines
December 10, 2024 — CRA enters into force
June 11, 2026 — Conformity assessment bodies can begin operations
September 11, 2026 — Vulnerability reporting obligations begin
December 11, 2027 — Full compliance with all essential requirements
The September 2026 deadline is the most urgent — manufacturers must have processes in place to detect, handle, and report actively exploited vulnerabilities within 24 hours. See our CRA compliance checklist for a step-by-step preparation guide.
How to Prepare for CRA Compliance
Start preparing now. Here is a practical checklist:
Determine if the CRA applies to your products. Map your product portfolio against CRA scope. Any product with digital elements placed on the EU market is likely in scope.
Classify your products. Check whether your products fall under the default category, Annex III (important), or Annex IV (critical). This determines your conformity assessment path.
Generate and maintain SBOMs. If you do not already have SBOMs for your products, start generating them now. See our SBOM generation guide for step-by-step instructions.
Set up vulnerability monitoring. Implement continuous monitoring of your dependencies against vulnerability databases (NVD, OSV.dev, CISA KEV).
Establish ENISA reporting processes. Build internal processes to detect actively exploited vulnerabilities and report them within the 24-hour window.
Document your security practices. Create or update your SECURITY.md, vulnerability disclosure policy, and security documentation.
Run a CRA readiness assessment. Use tools like cra-scanner to assess your current readiness and identify gaps.
CRA vs. NIS2: What Is the Difference?
The CRA and NIS2 are complementary but distinct regulations. Read our detailed CRA vs NIS2 comparison for a full breakdown. In short:
NIS2 targets organizations (operators of essential and important services) and requires them to implement cybersecurity risk management measures
CRA targets products (products with digital elements) and requires manufacturers to build security into the products themselves
A company can be subject to both: NIS2 for how they manage their own cybersecurity, and CRA for the products they manufacture and sell.
What Happens If You Do Not Comply?
Non-compliance with the CRA can result in significant penalties:
Up to EUR 15 million or 2.5% of total worldwide annual turnover (whichever is higher) for failure to meet essential cybersecurity requirements
Up to EUR 10 million or 2% of turnover for other non-compliance
Up to EUR 5 million or 1% of turnover for providing incorrect or misleading information to authorities
Market surveillance authorities can also order products to be withdrawn from the EU market.
Start Now
The CRA compliance deadlines are approaching fast. September 2026 is less than six months away for the vulnerability reporting obligations, and December 2027 for full compliance.
The organizations that start preparing now will have a significant advantage. Those that wait risk scrambling to comply under pressure — or facing enforcement action.
Complaro helps engineering teams automate CRA compliance, from SBOM analysis to ENISA reporting. Join the waitlist to get started.