Cyber Resilience Act (CRA): Complete Compliance Guide for 2026

Cyber Resilience Act (CRA): Complete Compliance Guide for 2026

The Cyber Resilience Act (Regulation 2024/2847) is the world's first horizontal regulation establishing mandatory cybersecurity requirements for products with digital elements. It requires security by design, lifecycle security updates, and transparent vulnerability handling across hardware and software products sold in the EU.

The critical deadline is now six months away: from 11 September 2026, vulnerability reporting obligations apply — including to products already on the market.

If you manufacture, import, or distribute connected products or software in Europe, the CRA affects you directly. This guide covers the full scope, requirements, September 2026 action items, and what the Commission's March 2026 draft guidance means for your compliance programme.

---

CRA Quick Answer

The Cyber Resilience Act is the EU regulation that makes cybersecurity a market-access requirement for products with digital elements. If you sell software, connected devices, or essential remote-processing components into the EU, you need security-by-design controls, vulnerability handling, technical documentation, and from 11 September 2026 you need to meet the CRA's reporting obligations for actively exploited vulnerabilities and severe incidents.

CRA At a Glance

Question	Short answer
What is it?	EU Regulation 2024/2847 for cybersecurity requirements on products with digital elements.
Who must comply?	Manufacturers, importers, and distributors placing covered products on the EU market.
When did it start?	Entered into force on 10 December 2024.
First major deadline?	Article 14 vulnerability reporting applies from 11 September 2026.
Full application?	11 December 2027.
Core obligations?	Security by design, secure defaults, vulnerability handling, SBOM discipline, updates, conformity assessment, and CE-marking readiness.
Penalties?	Up to EUR15 million or 2.5% of worldwide turnover for core non-compliance.

What Is the Cyber Resilience Act?

The CRA establishes horizontal cybersecurity requirements for products with digital elements across their entire lifecycle — from design and development through market placement to end of life. It addresses the fundamental market failure that most connected products have had no mandatory cybersecurity requirements at the regulatory level.

Key principles:

• Security by design: Products must be designed with cybersecurity built in from the start — not bolted on after
• Security by default: Products must be delivered with secure default configurations
• Lifecycle responsibility: Manufacturers must provide security updates for the expected product lifetime (minimum 5 years)
• Transparency: Vulnerabilities must be reported and handled through coordinated processes
• Market access: Non-compliant products cannot bear CE marking and cannot be placed on the EU market

The CRA published in the Official Journal on 20 November 2024 and entered into force on 10 December 2024.

What an executive needs to know

For most teams, the CRA changes three things immediately:

1. Cybersecurity becomes a product-shipping requirement, not only a best practice.
2. Legacy products are part of the September 2026 reporting problem, not just new launches.
3. SBOM, vulnerability handling, and technical documentation become operational necessities because they are the only scalable way to meet the CRA's deadlines.

---

Who Must Comply?

The CRA applies to three categories of economic operators:

Manufacturers

Any entity that designs, develops, or produces products with digital elements — or has them designed, developed, or produced — and markets them under their own name or trademark. Crucially, if you sell software under your own brand (even if built on open-source components), you are the manufacturer for CRA purposes.

Importers

Any entity established in the EU that places a product from a manufacturer outside the EU on the market.

Distributors

Any entity in the supply chain (other than manufacturer or importer) that makes a product available on the market.

What Counts as a "Product with Digital Elements"?

The CRA covers:

• Hardware products with network connectivity: IoT devices, routers, smart home devices, industrial controllers, automotive components
• Standalone software: Applications, operating systems, firmware, middleware, libraries
• Remote data processing: Cloud-based components that are essential to a product's core function (not standalone SaaS services)

The March 2026 Commission draft guidance clarifies that software is considered "placed on the market" when it is first supplied for distribution or use on the EU market — including through offering it for download or remote access.

Exemptions

• Open source software developed in a non-commercial context (see Open Source section below)
• Products already covered by sector-specific EU legislation (medical devices under MDR, automotive under type-approval regulations, aviation under EASA)
• Products exclusively developed for national security or defence purposes

---

Product Categories and Conformity Assessment

The CRA categorises products based on their criticality level:

Default Category (Majority of Products)

• Conformity assessment: Self-assessment by the manufacturer
• Examples: Most consumer IoT, general-purpose software, smart home devices
• Procedure: Internal control (Module A) based on Annex VIII

Important Products — Class I (Annex III)

• Identity management and authentication software
• VPNs, network management systems
• SIEM systems
• Boot managers, BIOS firmware
• Firewalls, IDS/IPS for non-industrial use
• Routers and modems for internet connectivity
• Microprocessors and microcontrollers with security features
• Assessment: Self-assessment with harmonised standards, OR third-party assessment

Important Products — Class II (Annex III, Higher Risk)

• Hypervisors, container runtime systems
• Firewalls and IDS/IPS for industrial use
• Tamper-resistant microprocessors/microcontrollers
• Assessment: Third-party conformity assessment required

Critical Products (Annex IV)

• Hardware security modules (HSMs), smart cards, secure elements
• Smart meter gateways within smart metering systems
• Assessment: European cybersecurity certification required

Harmonised standards update: ETSI, CEN, and CENELEC are developing EU-wide harmonised standards on the Commission's mandate — including vertical standards for browsers, password managers, antivirus software, VPNs, SIEM, and boot managers. Most harmonised standards are expected to be published by end of 2026, providing manufacturers with clear technical benchmarks for conformity assessment.

---

Essential Cybersecurity Requirements (Annex I)

Part I: Product Requirements

1. Products must be designed, developed, and produced to ensure an appropriate level of cybersecurity
2. Products must be delivered without known exploitable vulnerabilities
3. Products must have secure default configuration, with the ability to reset to factory defaults
4. Protection against unauthorised access through appropriate control mechanisms
5. Protection of confidentiality of stored, transmitted, or processed data (encryption where appropriate)
6. Protection of data integrity
7. Processing of only necessary data (data minimisation)
8. Availability protections, including resilience against denial-of-service
9. Minimisation of negative impact on other devices/networks
10. Minimal attack surface design
11. Mitigation of impact through exploitation mitigation techniques
12. Security-relevant information recording and monitoring (logging)
13. Secure software update mechanisms, with user notification

Part II: Vulnerability Handling Requirements

1. Identify and document vulnerabilities and components (including SBOM)
2. Address vulnerabilities without delay through security updates
3. Apply effective and regular testing and review
4. Public disclosure of fixed vulnerabilities, including CVE identifiers
5. Coordinated vulnerability disclosure (CVD) policy
6. Mechanisms for secure distribution of security updates
7. Free security updates for the expected product lifetime (minimum 5 years)

---

The September 2026 Deadline: What You Must Do Now

The most urgent CRA obligation is Article 14 — which applies from 11 September 2026. This is not a preparation milestone; it is a hard enforcement date. From this date, failure to report qualifies as a CRA violation.

Scope: Legacy Products Are Included

A critical point that many manufacturers miss: Article 14 reporting obligations apply to all products with digital elements on the EU market, including products placed on the market before December 2027. If your IoT device, router, or software is on sale today and a vulnerability is discovered in September 2026, you must report it.

What Must Be Reported

Manufacturers must report to ENISA (via the Single Reporting Platform) and their designated national CSIRT:

Actively exploited vulnerabilities:

• Within 24 hours of becoming aware: Early warning notification
• Within 72 hours: Full vulnerability notification with available corrective measures
• Within 14 days after a corrective measure is available: Final report with description, severity, impact, and remediation

Severe incidents impacting product security:

• Same 24-hour / 72-hour early warning structure
• Within 1 month: Final incident report

The Single Reporting Platform (SRP)

ENISA is establishing the Single Reporting Platform (SRP), which will be operational by 11 September 2026. Manufacturers report once through the SRP — notifications are addressed to the CSIRT where the manufacturer has its main establishment, with information simultaneously made available to ENISA and relevant EU CSIRTs. A testing period will be available before the deadline.

September 2026 Action Checklist

To be ready before the September 2026 deadline, manufacturers must:

• Inventory products: Identify every product with digital elements you have on the EU market
• Build or update your SBOM: Every product needs a complete software bill of materials before you can reliably detect exploited vulnerabilities
• Establish CSIRT contact: Identify which national CSIRT you will report to based on your main establishment
• Register for SRP access: Set up access to ENISA's Single Reporting Platform before it goes live
• Create a CVD policy: Publish your coordinated vulnerability disclosure policy (security@yourdomain or HackerOne/Bugcrowd)
• Document the 24/72h workflow: Create and drill the internal escalation process for a 24-hour emergency notification
• Set up CVE monitoring: Monitor CVE databases for vulnerabilities in your software dependencies

---

Software Bill of Materials (SBOM): The Foundation of CRA Compliance

One of the most operationally significant CRA requirements is the mandatory Software Bill of Materials (SBOM) — a complete, machine-readable inventory of all software components in a product: libraries, frameworks, open-source packages, and their versions.

Why SBOMs are critical for CRA compliance:

1. Vulnerability detection: When a critical vulnerability is discovered in a dependency (e.g., a Log4Shell-type event), your SBOM lets you instantly identify which products are affected
2. 24-hour reporting requirement: Without an accurate SBOM, meeting the 24-hour early warning deadline is operationally impossible for any product with significant dependency trees
3. Evidence for market surveillance: National authorities can request your SBOM as part of conformity assessment

Minimum SBOM content under CRA:

• Name and version of each component
• Supplier/author of the component
• Unique identifier (e.g., Package URL/PURL)
• Dependency relationships
• Licence information

Standard formats: SPDX (ISO/IEC 5962) and CycloneDX are both widely accepted. CycloneDX is increasingly preferred for security use cases due to its vulnerability tracking integration.

---

Secure Development Lifecycle (SDL) for CRA Compliance

The CRA does not mandate a specific SDL framework, but the essential requirements in Annex I effectively describe what a CRA-compliant development process must produce. Embedding security at each phase is the only scalable approach:

Requirements Phase

• Define security requirements for every product feature from day one
• Conduct threat modelling as part of product planning
• Declare the expected product lifetime (minimum 5 years for the support period)

Development Phase

• Apply secure coding standards and systematic code review
• Use dependency management tooling to track and update third-party libraries
• Implement automated Static Application Security Testing (SAST)

Testing Phase

• Conduct penetration testing before each major release
• Apply Dynamic Application Security Testing (DAST)
• Run vulnerability scanning across all components

Release Phase

• Generate and publish the SBOM for each release
• Verify secure default configuration before shipping
• Document security settings for users

Operations Phase

• Monitor CVE databases and security advisories for your dependency graph
• Operate a patch management process with defined response timelines
• Run a formal Coordinated Vulnerability Disclosure (CVD) programme

---

Open Source and the CRA

The CRA's open source provisions are nuanced. The non-commercial open source exemption covers individual contributions and projects developed outside a commercial context. However, two scenarios bring open source actors into scope:

Open Source Stewards

A legal person (typically a foundation) that provides sustained support for the development of open-source software intended for commercial activities is subject to CRA obligations as an open source steward. This is a lighter-touch regime:

• Stewards must maintain a cybersecurity policy covering secure development and vulnerability handling
• Stewards must cooperate with market surveillance authorities
• Stewards must report actively exploited vulnerabilities and severe incidents from September 2026
• Notably: open source stewards are not subject to administrative fines under the CRA

Commercial Products Using Open Source

If you ship a commercial product that incorporates open-source components, you are the manufacturer for CRA purposes — responsible for the entire product including its open-source dependencies. The Commission's March 2026 guidance clarifies that manufacturers are not required to ensure a proposed fix is accepted upstream (i.e., you may patch locally), but you must still track and report vulnerabilities in all components.

---

March 2026 Commission Draft Guidance: Key Clarifications

The European Commission published its draft guidance document (Ares(2026)2319816) on 3 March 2026 — roughly 70 pages of practical clarification open for stakeholder feedback until 31 March 2026.

Key clarifications relevant to manufacturers:

• "Placing on the market" includes offering software for download or remote access — not just physical distribution
• Remote data processing components essential to a product's core function fall within scope
• Support period definition and how it interacts with the 5-year minimum update obligation
• Upstream reporting: Manufacturers do not need to guarantee their fix is accepted upstream by the open-source project
• Interplay with other EU legislation: Guidance on how CRA obligations interact with GDPR, NIS2, and the AI Act

The final guidance document is expected after the consultation period closes, and will provide the most authoritative interpretation of CRA scope ahead of the September 2026 deadline.

---

CRA Compliance Timeline

Date	Milestone
20 Nov 2024	Published in Official Journal
10 Dec 2024	Entered into force
3 Mar 2026	Commission publishes draft guidance (open for feedback until 31 Mar 2026)
11 Jun 2026	Conformity assessment body notification provisions apply; Member States must have designated notifying authorities
11 Sep 2026	Vulnerability reporting obligations (Article 14) apply — including for products already on market
11 Dec 2027	Full application of all requirements — CE marking, conformity assessment, technical documentation

---

Penalties

Violation	Maximum Fine
Non-compliance with essential cybersecurity requirements (Annex I)	€15 million or 2.5% of global annual turnover
Non-compliance with other CRA obligations	€10 million or 2% of global annual turnover
Providing misleading information to authorities	€5 million or 1% of global annual turnover

Market surveillance authorities can also:

• Order products withdrawn from the market
• Require corrective measures
• Prohibit or restrict market availability
• Order product recalls

---

Full Compliance Roadmap (December 2027)

Beyond the September 2026 vulnerability reporting deadline, manufacturers need a broader programme to achieve full CRA compliance by December 2027:

Step 1: Scope Assessment

Determine which of your products fall under the CRA and their category (default, Class I important, Class II important, or critical). Map products to the correct conformity assessment route.

Step 2: Gap Analysis Against Annex I

Map your current product security practices against all 20 essential requirements. Common gaps discovered in CRA readiness assessments:

• No formal SBOM management process
• Vulnerability handling timelines not aligned with CRA's 24/72h/14-day requirements
• No secure update mechanism for deployed products
• No formal coordinated vulnerability disclosure policy published
• Security testing ad-hoc rather than systematic

Step 3: Security by Design Integration

Embed security requirements into your product development lifecycle across all phases (see SDL section above). This is a cultural and process change, not just a technical one.

Step 4: Vulnerability Management Programme

Establish:

• Coordinated vulnerability disclosure policy (published on your website)
• SBOM generation and maintenance for each product release
• CVE monitoring for your dependency graph
• 24/72h/14-day reporting workflow documentation and drills

Step 5: Technical Documentation

Prepare the full technical file required for CRA conformity, including:

• Product and design description
• Security requirements and their implementation
• Risk analysis
• Test results
• SBOM
• EU Declaration of Conformity

Step 6: Conformity Assessment and CE Marking

Complete the appropriate conformity assessment procedure for your product category and affix the CE mark.

Step 7: Continuous Lifecycle Compliance

The CRA creates ongoing obligations, not a one-time exercise:

• Update SBOM with every release
• Monitor and patch dependencies throughout the declared support period
• Maintain technical documentation
• Continue reporting obligations under Article 14

---

CRA and Other EU Regulations

Regulation	Relationship to CRA
NIS2	CRA addresses product security; NIS2 addresses organisational security. Products compliant with CRA help NIS2-regulated operators meet their supply chain security obligations.
GDPR	CRA's data protection requirements (data minimisation, encryption, access control) complement GDPR for product-level data handling.
DORA	Financial entities subject to DORA must use secure ICT products — CRA-compliant products reduce DORA ICT risk exposure.
AI Act	High-risk AI systems that are products with digital elements must comply with both CRA and the AI Act.
MDR/IVDR	Medical devices are exempt from CRA (covered by their own regulations).
Radio Equipment Directive (RED)	CRA will eventually replace RED's cybersecurity delegated acts for in-scope products.

---

How Orbiq Supports CRA Compliance

CRA compliance generates substantial documentation and evidence requirements throughout the product lifecycle. Orbiq helps manufacturers manage this continuously:

• Supply chain documentation: Track components and dependencies across your product portfolio — the foundation of SBOM management
• Compliance evidence: Centralise security testing results, vulnerability assessments, and conformity documentation in one place
• Trust Center: Share your product security posture, CVD policy, and compliance status with customers and market surveillance authorities
• Vendor management: Monitor the security status of components and third-party dependencies
• Continuous monitoring: Stay ahead of CRA obligations with automated compliance tracking across your product portfolio

---

Further Reading

• Cyber Resilience Act: Articles 13 & 14 — Notification and Reporting in Detail
• EU AI Act Compliance: Complete Guide (2026) — AI system requirements that intersect with CRA for AI-enabled products
• NIS2 Compliance Guide — Organisational security requirements that complement the CRA
• DORA Compliance Guide — Financial sector resilience requirements
• NIS2 Directive Overview — The full legislative framework and member state transposition

---

Sources & References

1. EU Cyber Resilience Act — Official Text (Regulation 2024/2847) — Official Journal of the EU, 20 November 2024
2. Commission Draft Guidance on CRA — Ares(2026)2319816 — European Commission, 3 March 2026; open for feedback until 31 March 2026
3. CRA Reporting Obligations — Official Page — European Commission Digital Strategy; covers Article 14 scope and Single Reporting Platform
4. CRA Implementation — EC Factpage — European Commission; implementation milestones and timelines
5. EU Cyber Resilience Act: Key 2026 Milestones — Hogan Lovells; analysis of June and September 2026 obligations
6. CRA's Phased Entry into Application Starts September 2026 — Bird & Bird, 2026
7. One Year Countdown to EU CRA Compliance — Keysight Technologies, September 2025; scope of September 2026 deadline
8. CRA Harmonized Standards Framework — Keysight, February 2026; status of ETSI/CEN/CENELEC standards
9. CRA Open Source Policy — European Commission; open source steward obligations and exemptions
10. DLA Piper CRA Compliance Guide — DLA Piper, February 2026

---