What Is the Cyber Resilience Act? The Complete Guide for Businesses 2026

The EU Cyber Resilience Act (CRA) is the first horizontal regulation establishing mandatory cybersecurity requirements for all products with digital elements sold on the European market. From smart home devices and industrial controllers to enterprise software and open-source libraries, the CRA fundamentally changes how manufacturers, importers, and distributors approach product security. It shifts the burden of cybersecurity from buyers to makers — and backs it with penalties comparable to GDPR.

This guide covers everything businesses need to know: who is affected, what is required, how products are classified, the implementation timeline, how the CRA relates to NIS2 and DORA, and a practical compliance roadmap. Whether you manufacture hardware, develop software, or distribute digital products in the EU, the CRA applies to you.

What Is the Cyber Resilience Act?

The Cyber Resilience Act (EU Regulation 2024/2847) was published in the Official Journal on November 20, 2024, and entered into force on December 10, 2024. It establishes essential cybersecurity requirements for the design, development, production, and maintenance of products with digital elements. The regulation complements the existing EU cybersecurity framework — building on the 2020 EU Cybersecurity Strategy and working alongside the NIS2 Directive and the EU Cybersecurity Act.

The core principle is security by design: products must be designed with cybersecurity in mind from the start, not bolted on after development. Manufacturers bear responsibility for the entire product lifecycle, including providing security updates for at least five years after market placement.

Why Was the CRA Introduced?

Three factors drove the CRA. First, the cost of cybercrime reached an estimated EUR 5.5 trillion globally, with a significant share attributed to vulnerabilities in connected products. Second, there was no horizontal EU regulation requiring cybersecurity for digital products — existing rules covered specific sectors (medical devices, vehicles, aviation) but left the vast majority of products unregulated. Third, consumers and businesses had no reliable way to assess the cybersecurity of products before purchase. The CE marking under the CRA aims to provide that signal.

Who Must Comply With the CRA?

The CRA assigns obligations to three categories of economic operators:

Manufacturers

Any entity that develops or produces products with digital elements for the EU market, whether based in the EU or not. Manufacturers bear the heaviest obligations: security-by-design, conformity assessment, CE marking, vulnerability handling, security update provision, and SBOM (Software Bill of Materials) documentation. Non-EU manufacturers must appoint an authorized representative in the EU.

Importers

Entities that place products from non-EU manufacturers on the EU market. Importers must verify that the manufacturer has performed the conformity assessment, that the product bears CE marking, and that required documentation (including SBOM) is available. Importers are responsible for ensuring non-compliant products do not enter the EU market.

Distributors

Entities that make products available on the EU market without being the manufacturer or importer. Distributors must verify that products bear CE marking and that the manufacturer and importer have met their obligations. If a distributor discovers that a product does not comply, they must not make it available until compliance is achieved.

Which Products Are Covered?

The CRA covers "products with digital elements" — defined as any software or hardware product and its remote data processing solutions that includes a direct or indirect connection to a device or network. This is extraordinarily broad:

• Hardware with embedded software: IoT devices, smart home products, network routers, industrial sensors, wearables, smart meters
• Standalone software: Operating systems, browsers, office suites, enterprise applications, mobile apps, firmware
• Software components: Libraries, SDKs, APIs that are distributed as products
• Consumer electronics: Smart TVs, connected appliances, gaming consoles, connected vehicles (for digital components not covered by UNECE)

What Is Excluded?

• Pure SaaS services with no client-side component (cloud-hosted applications where the user accesses only through a browser without downloads)
• Medical devices (covered by MDR/IVDR)
• Vehicles and aviation products (covered by existing type-approval regulations)
• Non-commercial open-source software (but commercial integrators using open-source components are responsible for CRA compliance of the final product)
• National security and military products

The SaaS Question

Pure SaaS is generally excluded, but the boundary is nuanced. If your SaaS product includes any downloadable component — a desktop client, browser extension, mobile app, or on-device processing module — those components fall under the CRA. Cloud infrastructure services are excluded. The practical implication: most modern SaaS products that include desktop or mobile clients have at least some CRA-relevant components.

Product Classification and Risk Tiers

The CRA classifies products into three risk categories, each with different conformity assessment requirements:

Default Category (Vast Majority of Products)

Products not listed in Annex III or IV. Conformity assessment: manufacturer self-assessment against essential requirements. This covers the vast majority of consumer and business software, IoT devices, and connected products. Self-assessment means the manufacturer evaluates compliance internally — no third-party audit required, but the assessment must be documented and available for market surveillance authorities.

Important Products — Class I

Listed in Annex III, Part I. Examples: identity management systems, browsers, password managers, VPNs, network management tools, firewalls, intrusion detection systems, and routers for industrial use. Conformity assessment: self-assessment using harmonized standards (when available) OR third-party assessment. If no harmonized standard exists for the product category, third-party assessment becomes mandatory.

Important Products — Class II

Listed in Annex III, Part II. Examples: operating systems, hypervisors, microprocessors, smart meters, industrial IoT not covered by sector regulation, public key infrastructure, and container runtime systems. Conformity assessment: mandatory third-party assessment by a notified body. Self-assessment is not sufficient.

Critical Products

Listed in Annex IV. Currently includes hardware security modules (HSMs), smart cards, smart card readers, and tamper-resistant elements. Conformity assessment: European cybersecurity certification (when an applicable EU scheme exists). Until a certification scheme is available, Class II assessment rules apply.

Essential Security Requirements

The CRA defines two sets of essential requirements in Annex I:

Part I: Security Requirements for Products

• Products must ship without known exploitable vulnerabilities
• Secure by default configuration — out-of-the-box settings must be secure, not just convenient
• Protection against unauthorized access through appropriate authentication and identity management
• Confidentiality protection: encryption of data in transit and at rest where applicable
• Integrity protection: mechanisms to detect unauthorized modification of data and software
• Data minimization: process only data necessary for the intended purpose
• Availability: resilience against denial-of-service attacks, graceful degradation
• Minimal attack surface: disable unnecessary features, ports, and services by default
• Automatic security update capability with user opt-out option

Part II: Vulnerability Handling Requirements

• Documented vulnerability handling process covering identification, remediation, and disclosure
• Coordinated vulnerability disclosure (CVD) policy — publicly accessible, with clear contact information
• Security testing: regular testing and review of product security
• Software Bill of Materials (SBOM) generation and maintenance for every product
• Timely distribution of security patches — free of charge, with clear information about fixed vulnerabilities
• Five-year minimum security support period from market placement (or the product lifetime, whichever is shorter)

Vulnerability Reporting Obligations

One of the CRA’s most impactful requirements: manufacturers must report actively exploited vulnerabilities to ENISA within strict timelines:

1. Within 24 hours: Early warning notification to ENISA — confirm the vulnerability is actively exploited, provide initial severity assessment and affected products
2. Within 72 hours: Full vulnerability notification — technical details, exploitation methods, affected product versions, recommended mitigations
3. Within 14 days: Final report — root cause analysis, patch status, notification to affected users

This reporting obligation is already active since September 11, 2026. Manufacturers who discover actively exploited vulnerabilities in their products must report — regardless of whether the full CRA compliance deadline has passed.

Implementation Timeline

• December 10, 2024: CRA entered into force
• September 11, 2026: Vulnerability reporting obligation active (24h/72h/14d)
• December 11, 2027: Full compliance deadline — all products on the EU market must meet essential requirements, carry CE marking, and have completed conformity assessment
• Ongoing: Five-year security update obligation from date of market placement

The practical implication: if you are a product manufacturer and have not started CRA preparation, the vulnerability reporting deadline has already passed and you have approximately 14 months until full compliance is required.

Conformity Assessment and CE Marking

To place a product on the EU market, manufacturers must complete a conformity assessment appropriate to their product category, prepare an EU declaration of conformity, and affix the CE marking to the product. The CE marking signals to buyers and market surveillance authorities that the product meets CRA essential requirements.

The assessment process:

1. Internal assessment (default and Class I with harmonized standards): Document how the product meets each essential requirement, prepare technical documentation per Annex VII, conduct or commission security testing, maintain the documentation for 10 years.
2. Third-party assessment (Class II and Class I without harmonized standards): Engage a notified body to evaluate the product against essential requirements. The notified body issues a conformity certificate. First notified bodies are expected to be designated throughout 2026.
3. EU certification (critical products): Obtain certification under an applicable EU cybersecurity certification scheme. Until schemes are available, Class II rules apply.

How the CRA Relates to Other EU Regulations

CRA vs. NIS2

The CRA and NIS2 Directive address different but complementary aspects of cybersecurity. The CRA regulates the cybersecurity of products — it targets manufacturers, importers, and distributors. NIS2 regulates the cybersecurity of organizations — it targets operators of essential and important services. A company can be subject to both: as a manufacturer of digital products (CRA) and as an operator of essential services (NIS2). There is no conflict; the CRA strengthens the product side while NIS2 strengthens the operational side.

Key differences: CRA imposes product-level requirements (security by design, vulnerability handling, CE marking). NIS2 imposes organizational requirements (risk management, incident reporting, supply chain security). CRA reporting goes to ENISA for product vulnerabilities. NIS2 reporting goes to national authorities (e.g., BSI) for operational incidents.

CRA vs. DORA

DORA (Digital Operational Resilience Act) applies to financial institutions and their critical ICT service providers. If a financial institution uses products that fall under the CRA, the CRA governs the product manufacturer’s obligations, while DORA governs how the financial institution manages ICT risks including those from third-party products. For ICT service providers to the financial sector: DORA applies to your service delivery, and the CRA may additionally apply if you distribute software products.

CRA vs. ISO 27001

ISO 27001 certifies an organization’s information security management system. The CRA certifies product cybersecurity. They operate at different levels: ISO 27001 demonstrates that your organization manages security well; the CRA demonstrates that your specific product meets cybersecurity requirements. Having ISO 27001 helps with CRA compliance (it provides evidence of security processes) but does not replace the product-specific conformity assessment.

Penalties for Non-Compliance

The CRA establishes a tiered penalty framework:

• Up to EUR 15 million or 2.5% of global annual turnover for non-compliance with essential requirements (Annex I) — whichever is higher
• Up to EUR 10 million or 2% of global annual turnover for non-compliance with other CRA obligations
• Up to EUR 5 million or 1% of global annual turnover for providing incorrect, incomplete, or misleading information to authorities

Beyond financial penalties, market surveillance authorities can order product recalls, market withdrawals, and public warnings. For products that present serious cybersecurity risk, authorities can take immediate restrictive measures without waiting for the manufacturer to act. The reputational damage from a public recall can exceed the financial penalty.

The Open-Source Question

The CRA’s treatment of open-source software has been the subject of intense debate. The final regulation distinguishes between:

• Non-commercial open-source: Software developed and distributed without commercial intent is exempted from CRA obligations. Community-driven projects, personal tools, and academic research software fall outside the scope.
• Commercial open-source: If open-source software is developed in a commercial context (e.g., freemium models, commercial support, enterprise editions), the CRA applies to the commercial entity providing it.
• Open-source stewards: A new category created by the CRA for entities that systematically facilitate the development of open-source products intended for commercial use. Stewards have lighter obligations focused on cybersecurity policy and vulnerability handling coordination.
• Integrators: When a company commercially integrates open-source components into its products, that company — not the open-source project — is responsible for CRA compliance of those components. This underscores the critical importance of SBOM management.

Practical Compliance Roadmap

For manufacturers who have not yet started CRA preparation:

1. Months 1–2 — Product inventory and classification: List all products with digital elements that you place on the EU market. Classify each by risk category (default, Class I, Class II, critical). Identify all third-party and open-source components in each product. This step requires collaboration between product management, engineering, and legal.
2. Months 2–4 — Gap assessment against essential requirements: For each product, evaluate current compliance against Annex I requirements. Document where products already meet requirements and where gaps exist. Prioritize gaps by risk level and remediation effort. Pay particular attention to: secure default configuration, update mechanism, SBOM completeness.
3. Months 4–8 — Security-by-design implementation: Address identified gaps in product architecture and code. Implement or improve automatic security update mechanisms. Establish secure default configurations. Review and reduce attack surfaces. Build vulnerability handling processes if they do not exist.
4. Months 6–8 — SBOM and vulnerability management: Generate SBOMs for all products using standardized formats (CycloneDX or SPDX). Establish continuous vulnerability monitoring for all components. Set up the ENISA reporting workflow. Create or formalize the coordinated vulnerability disclosure policy.
5. Months 8–12 — Conformity assessment and documentation: Prepare technical documentation per Annex VII. For default and Class I products: complete internal conformity assessment. For Class II products: engage a notified body. Prepare the EU declaration of conformity. Affix CE marking. Train sales and distribution teams on CRA obligations.
6. Month 12+ — Ongoing compliance: Maintain security update capability for five years. Monitor for vulnerabilities continuously. Report actively exploited vulnerabilities within 24 hours. Update SBOMs with each product release. Retain documentation for 10 years.

Frequently Asked Questions

Does the CRA apply to SaaS-only products?

Pure SaaS without any downloadable component is generally excluded from the CRA. However, if your SaaS includes a desktop client, mobile app, browser extension, or any software that runs on the user’s device, those components are in scope. Most modern SaaS products have at least one in-scope component. Review your product architecture carefully before assuming exclusion.

What happens if we miss the December 2027 deadline?

Products that do not comply with CRA essential requirements cannot legally be placed on the EU market after December 11, 2027. Market surveillance authorities can order product recalls, impose fines up to EUR 15 million or 2.5% of global turnover, and issue public warnings. Products already on the market before the deadline must also be brought into compliance. There is no grandfathering provision for non-compliant products.

Do open-source projects need to comply?

Non-commercial open-source software is exempted. However, companies that commercially integrate open-source components into their products are responsible for CRA compliance of those components. The open-source project itself has no obligation; the integrator does. This makes SBOM management and dependency monitoring essential for any company using open-source in CRA-regulated products.

How does the CRA affect companies outside the EU?

The CRA has extraterritorial effect. Any product placed on the EU market must comply, regardless of where the manufacturer is located. Non-EU manufacturers must appoint an authorized representative in the EU. If your product is downloadable by EU customers (including through app stores), the CRA likely applies. This mirrors the GDPR’s extraterritorial reach.

What is the relationship between CRA and CE marking?

CE marking under the CRA signifies that a product meets the essential cybersecurity requirements and has undergone the appropriate conformity assessment. It is mandatory for all CRA-regulated products placed on the EU market. Without CE marking, products cannot be legally sold. The CE marking is the visible signal to buyers and authorities that the product has been assessed for cybersecurity.

How do we handle products with long lifecycles?

The CRA requires security updates for at least five years from market placement, or the expected product lifetime, whichever is shorter. For products with lifecycles exceeding five years (industrial equipment, infrastructure components), manufacturers should consider extended support commitments. The five-year minimum is a floor, not a ceiling — market expectations and competitive pressure may demand longer support periods.

What is an SBOM and why does the CRA require it?

A Software Bill of Materials (SBOM) is a comprehensive inventory of all software components in a product, including open-source libraries, third-party modules, and their versions. The CRA requires SBOMs because knowing what is inside a product is essential for vulnerability management: when a new CVE is published for a library, the SBOM tells you immediately which products are affected. Standardized formats (CycloneDX, SPDX) are recommended for interoperability.