Cyber Resilience Act (CRA): Comprehensive Product Cybersecurity Compliance Guide

The Cyber Resilience Act (Regulation (EU) 2024/2847) is the European Union's first regulation that directly addresses the cybersecurity of products with digital elements. Before CRA, EU cybersecurity law (NIS2, GDPR) focused on operators and data controllers — not the products themselves. CRA shifts responsibility upstream to manufacturers: any company that designs, develops, or places a product with digital elements on the EU market must ensure that product is secure by design and by default, supported for vulnerabilities throughout its lifecycle, and transparent about known security issues. CRA entered into force on December 10, 2024, with most obligations applying from December 11, 2027. It represents a fundamental change in how software and hardware vendors must approach product security — moving from voluntary best practices to mandatory, auditable requirements backed by significant penalties.

CRA applies to any manufacturer, importer, or distributor that places a "product with digital elements" on the EU market, regardless of where they are headquartered. This includes: (1) Software vendors: enterprise software, operating systems, browsers, productivity tools, and mobile applications. (2) Hardware manufacturers: IoT devices, routers, smart home products, industrial control systems, network equipment. (3) Embedded software developers: firmware for medical devices (once excluded categories are clarified), industrial automation, connected vehicles in non-EASA/automotive-specific scopes. (4) Importers and distributors: companies that import products from non-EU manufacturers bear CRA obligations if the manufacturer has not designated an EU representative. Open source software used commercially may also fall within scope unless it meets the "free and open source" exemption criteria. If you sell any connected product — physical or software — into the EU market after December 11, 2027, CRA compliance is mandatory.

Article 3 of CRA defines a product with digital elements as "any software or hardware product and its remote data processing solutions, including software or hardware components placed on the market separately." This encompasses a broad range of products: (1) Consumer IoT: smart speakers, home security cameras, connected thermostats, fitness trackers. (2) Industrial/Enterprise: SCADA systems, network switches, routers, firewalls, industrial sensors. (3) Software products: operating systems, security software, virtualization platforms, database software, communication tools. (4) Mobile applications that communicate with a backend service. (5) Cloud-connected devices: any hardware or software that communicates with EU users' data or infrastructure. Excluded from CRA scope: medical devices (covered under MDR/IVDR), motor vehicles (UN Regulation No. 155), aviation equipment (EASA regulation), and national security/defense equipment. CRA distinguishes between default-class, important-class (Category I), and critical-class (Category II) products — the latter requiring mandatory third-party conformity assessment.

The Cyber Resilience Act requires manufacturers to prepare and maintain a Software Bill of Materials (SBOM) identifying all software components, including third-party and open-source dependencies. CRA SBOM requirements include: (1) Component identification: Name, version, supplier, and license for each software component. (2) Dependency mapping: Direct and transitive dependencies, helping identify which components are affected by a given CVE. (3) Update tracking: SBOM must be updated when components change, so it always reflects the current released version. (4) Retention: SBOM must be retained for at least 10 years after the product is placed on the market or its support period ends (whichever is later). (5) Availability: SBOM must be available to market surveillance authorities upon request. Manufacturers do not need to publish the SBOM publicly, but it must be accurate, current, and accessible for regulatory audit. The SBOM should follow recognized formats (CycloneDX or SPDX are de facto standards). Inadequate SBOM documentation constitutes a documentation violation penalized at up to €5 million or 1% of global revenue.

CRA introduces mandatory coordinated vulnerability disclosure (CVD) obligations for all manufacturers of products with digital elements: (1) Actively exploited vulnerabilities: Manufacturers must notify ENISA (the EU Cybersecurity Agency) within 24 hours of becoming aware that a vulnerability in their product is being actively exploited in the wild. (2) Full vulnerability report: A complete technical report must follow within 72 hours, covering the vulnerability details, affected product versions, impact assessment, and planned remediation. (3) Coordinated disclosure: Manufacturers must establish and document a policy for responsibly disclosing vulnerabilities found by external security researchers — including a process for receiving reports (e.g., security.txt, bug bounty platform). (4) Remediation obligation: Upon identifying a vulnerability, the manufacturer must develop a fix and push it to users via security updates within a timeframe proportional to severity. (5) User notification: Users must be notified when a security update is available and informed of the vulnerability it addresses. ENISA will maintain a central vulnerability database for CRA-reported issues. Failure to report within the 24-hour window is subject to penalties up to €15 million or 2.5% of global annual turnover.

CRA mandates a two-track incident and vulnerability reporting regime: (1) Actively exploited vulnerability (24-hour early warning to ENISA): When a manufacturer discovers that a vulnerability in their shipped product is being actively exploited — regardless of whether the exploit has caused harm — they must submit an early warning to ENISA within 24 hours. This early warning should include: product identification, vulnerability description, exploitation indicators (IOCs), and affected user population estimate. (2) 72-hour full report: A complete report to ENISA with: technical root cause, confirmed affected versions, remediation plan and timeline, mitigation recommendations for users, and any indicators of compromise for threat intelligence sharing. (3) Severe incident (72-hour report to NCA): Where a security incident in the product or its supply chain poses a significant impact on the availability, integrity, or confidentiality of the product or its users, the manufacturer must also notify the national market surveillance authority (MSA) of the member state where they are established. The reporting obligations under CRA complement (but are distinct from) NIS2 incident reporting — organizations may need to report under both regimes if they are both a manufacturer (CRA) and an operator of critical infrastructure (NIS2).

The Cyber Resilience Act introduces CE marking as the conformity indicator for cybersecurity compliance of products with digital elements. This is analogous to how CE marking already works for physical safety standards (e.g., toys, medical devices, electronics). Under CRA: (1) Self-declaration (default class): Most products can self-declare CRA conformity by completing an internal risk assessment, ensuring all requirements are met, and affixing the CE mark. The manufacturer must prepare technical documentation supporting the self-declaration. (2) Third-party conformity assessment (important class — Category I): Products such as browsers, password managers, VPNs, network devices, microcontrollers, and operating systems designated as "important" under Annex III must undergo third-party assessment by an EU-notified body before affixing the CE mark. (3) Mandatory third-party audit (critical class — Category II): Highly critical products such as hardware security modules, smart cards, industrial safety systems, and critical infrastructure components listed in Annex IV require a European Cybersecurity Certificate or a notified body audit. CE marking under CRA attests that the product meets the essential cybersecurity requirements in Annex I of the regulation. Products without proper CRA-conforming CE marks cannot legally be sold in the EU market after December 11, 2027.

CRA and NIS2 are complementary but distinct EU cybersecurity regulations with different primary targets: (1) NIS2 targets operators: NIS2 applies to organizations operating critical infrastructure and digital services (hospitals, energy companies, banks, cloud providers). It governs how those organizations manage cybersecurity risk in their own operations. (2) CRA targets products: CRA applies to manufacturers and distributors of hardware and software placed on the EU market. It governs the security of the product itself — its design, development, support, and vulnerability management. (3) Overlap in practice: A large enterprise software vendor may be both a CRA-obligated manufacturer (for the products it sells) and a NIS2-obligated important operator (for the cloud services it operates). In this case, both frameworks apply simultaneously. (4) Penalties differ: NIS2 maximum €10M or 2% global revenue; CRA maximum €15M or 2.5%. (5) Key shared themes: Both mandate vulnerability management, incident reporting to EU authorities, and supply chain security consciousness. Organizations operating in both scopes should harmonize their programs rather than run separate compliance workstreams. CRA is often described as the "upstream" complement to NIS2 — ensuring the products operators rely on are themselves secure.

CRA establishes three product classification tiers based on cybersecurity risk: (1) Default class (majority of products): Standard hardware and software products not listed in Annexes III or IV. Examples: generic business applications, simple connected devices, firmware for low-risk IoT. Conformity assessment: self-declaration by manufacturer. (2) Important class — Category I (Annex III): Products with higher inherent cybersecurity risk due to their function or position in critical systems. Examples: browsers, password managers, firewalls, VPNs, network switches, microcontrollers, hardened operating systems, industrial automation software. Conformity assessment: must use either an approved security standard (e.g., EN 18031 series) for self-declaration OR engage a notified body for third-party audit. (3) Critical class — Category II (Annex IV): Products that play a critical role in trust infrastructure or are deeply embedded in critical infrastructure. Examples: hardware security modules (HSMs), smart cards, secure elements, trusted platform modules (TPMs), industrial safety controllers, critical infrastructure network devices. Conformity assessment: mandatory European Cybersecurity Certificate OR full notified body audit. The European Commission can update Annexes III and IV via delegated acts — manufacturers should monitor these updates as classification can change after initial product design.

The Cyber Resilience Act includes an exemption for free and open source software (FOSS) developed or supplied outside of a commercial activity. The specific criteria are: (1) Non-commercial development: Software developed purely as a hobby or community project with no commercial intent at the development stage. (2) Not placed on the market by its developer: If the developer does not distribute the software commercially (e.g., through app stores, direct sales, or bundled with commercial services), and receives no revenue from it, the developer may not be the "manufacturer" for CRA purposes. (3) The importer/distributor becomes responsible: If a commercial entity takes FOSS and places it on the market as part of a product (bundled into a device or SaaS offering), that entity becomes the "manufacturer" for CRA purposes. In practice: (a) Pure hobby projects with no commercial use: exempt. (b) Open core commercial products (Apache-licensed code with paid enterprise features): manufacturer CRA obligations apply. (c) FOSS used as a component in a commercial product: the manufacturer of the final product bears CRA obligations for the whole product including the FOSS component. Major FOSS foundations (Apache, Eclipse, Linux Foundation) are engaging with the European Commission to clarify obligations for foundation-supported projects that underpin widespread commercial use.

The Cyber Resilience Act has a phased compliance timeline: (1) December 10, 2024: CRA entered into force. Manufacturers should have begun gap assessments and compliance planning from this date. (2) September 11, 2026: Notified body obligations take effect. Organizations wishing to act as CRA conformity assessment bodies must be notified by this date. Product manufacturers seeking Category I third-party assessment should begin engaging notified bodies well before this date to secure capacity. (3) December 11, 2027: Full CRA compliance mandatory for all products with digital elements placed on the EU market. This is the hard deadline — all products sold in the EU market must carry CRA-compliant CE marking. (4) What this means for planning (from May 2026): You have approximately 18 months to achieve full compliance. Priority actions: complete product inventory and classification (default/important/critical), conduct cybersecurity risk assessments per Annex I, begin SBOM generation and tooling, establish vulnerability disclosure policy, and engage notified body if your product is Category I/II. Products already on market before December 11, 2027 may continue to be sold until their natural lifecycle end, subject to transition rules — but new product versions or major updates must comply. Do not wait; conformity assessment queues for notified bodies are expected to be heavily loaded from late 2026 onward.

Article 64 of the Cyber Resilience Act establishes three penalty tiers: (1) Tier 1 — up to €15 million or 2.5% of global annual turnover (whichever is higher): Non-compliance with the essential cybersecurity requirements of Annex I (e.g., failure to implement vulnerability management, inadequate security controls, failure to report actively exploited vulnerabilities to ENISA within 24 hours). (2) Tier 2 — up to €10 million or 2% of global annual turnover: Non-compliance with obligations for economic operators other than the fundamental security requirements (e.g., failure to prepare technical documentation, failure to maintain SBOM, failure to maintain declaration of conformity). (3) Tier 3 — up to €5 million or 1% of global annual turnover: Providing incorrect, incomplete, or misleading information to market surveillance authorities or notified bodies. Market surveillance authorities (MSAs) in each EU member state are responsible for enforcement. They can conduct product withdrawals, recall orders, market bans, and financial penalties. CRA penalties are higher than NIS2 penalties — a deliberate signal from the EU that product security failures carry severe consequences.

CRA's application to cloud services and SaaS is nuanced: (1) Pure cloud/SaaS services (no installed component): Initially debated during CRA legislative process. The final text focuses on "products with digital elements" — products placed on the market that have a digital component. A pure web-based SaaS service accessed only via browser, with no installed client, is generally not a "product" in CRA's sense. NIS2 would govern its operational security instead. (2) SaaS with an installed component: If your SaaS requires users to install a client application, agent, or plug-in on their device, that installed component is a "product with digital elements" and falls under CRA. The cloud backend may also be relevant to security obligations. (3) Cloud-connected hardware: Any hardware device that connects to cloud services (IoT, gateways, sensors) must comply with CRA as a product. The cloud service component's security is part of the overall product's security posture. (4) Software-as-a-Service in embedded systems: Software sold to device manufacturers as a component to embed in their products clearly falls under CRA. In practice, most enterprise SaaS vendors should assess whether any part of their offering involves a distributed software component (agent, plug-in, SDK, binary) and, if so, apply CRA obligations to that component and its supply chain.

Embedded software is a primary focus of the Cyber Resilience Act, as it represents one of the highest-risk categories of products with digital elements. CRA obligations for embedded software manufacturers include: (1) Security by design: Embedded software must be designed with a minimal attack surface, using secure boot, firmware integrity verification, and secure update mechanisms. (2) Secure update capability: Devices running the embedded software must support security updates delivered over the air (OTA) or via secure physical interface. Devices that cannot receive security updates are non-compliant. (3) 5-year support window: Manufacturers must provide security patches and vulnerability remediation for at least 5 years (or the expected product lifetime if shorter). Industrial and critical infrastructure products often have 10–20 year lifecycles; CRA requires a plan for that period. (4) Default-secure configuration: Default passwords must be eliminated; devices must require unique credentials at first setup. (5) Encrypted communication: Embedded software that communicates over networks must use current, unbroken encryption protocols. (6) SBOM: Manufacturers of embedded firmware must maintain a complete SBOM for all software components, including third-party libraries and RTOS components. Legacy embedded products already on the market before December 11, 2027 do not need to be recalled — but any significant update or new firmware release after that date must comply.

Market surveillance authorities (MSAs) are the primary enforcement bodies for the Cyber Resilience Act in each EU member state. They operate under the EU Market Surveillance Regulation (2019/1020) with CRA-specific powers: (1) Product inspection: MSAs can inspect products on the market and request technical documentation, SBOM, vulnerability management records, and conformity declarations from manufacturers. (2) Risk assessment: MSAs assess whether a product poses a cybersecurity risk and can order product recalls, withdrawal from market, or market bans if it does. (3) Notification to other MSAs: Under the RAPEX/ICSMS system, MSAs share alerts about non-compliant products across EU member states — a recall in Germany triggers action across the whole EU. (4) Coordinated enforcement: The European Commission facilitates joint MSA enforcement actions against products presenting widespread risk. (5) Penalties: MSAs can levy fines under CRA's penalty framework (up to €15M/2.5% global revenue) and pursue criminal referrals where intentional violations are found. Manufacturers exporting to the EU without an EU-based representative face particular risk — MSAs can target importers and distributors in the EU as responsible parties. Establishing a designated EU representative (EU Rep) is a risk-mitigation measure for non-EU manufacturers.

Article 10 of CRA and Annex I specify that manufacturers must conduct a cybersecurity risk assessment covering the product's entire lifecycle. A compliant CRA risk assessment must address: (1) Threat modelling: Identify realistic threats to the product — unauthorized access, firmware manipulation, supply chain compromise, denial-of-service, data exfiltration. (2) Attack surface analysis: Document all interfaces (network, physical, USB, cloud API) and assess their exposure. (3) Security requirements mapping: Map identified threats to Annex I essential requirements (no known exploitable vulnerabilities, secure configuration, access controls, encryption, secure updates, data minimization, resilience). (4) Component risk: Assess risk contributed by third-party components and open-source dependencies — particularly components with known CVE history. (5) Operational context: Consider the deployment environment. A consumer smart lock in a home has a different risk profile than the same hardware deployed in a hospital access control system. (6) Residual risk acceptance: Document accepted residual risks with justification and any compensating controls or user guidance. (7) Lifecycle review: Risk assessment must be updated upon significant product changes, significant new vulnerabilities disclosed in the product's dependencies, or at periodic intervals (at minimum annually). The risk assessment is a mandatory part of the technical file (Article 31) and must be retained for 10 years.

The Cyber Resilience Act includes several SME-focused accommodations, though core security obligations still apply: (1) Regulatory sandboxes: Article 42 allows member states to establish CRA regulatory sandboxes where SMEs (fewer than 250 employees, turnover under €50M) can test products in a controlled regulatory environment with guidance from market surveillance authorities before market launch. (2) Simplified documentation: For default-class products, self-declaration is allowed — SMEs do not need a notified body for most products. (3) Support programs: The European Commission and member states are directed to develop support measures (standards guides, compliance toolkits, training) specifically for SMEs and start-ups. (4) Microenterprises: Companies with fewer than 10 employees and less than €2M turnover have additional flexibility in how they implement certain procedural requirements, though the product security requirements themselves apply equally. (5) Proportionality: Enforcement authorities are directed to apply penalties proportionally, considering company size, good-faith compliance efforts, and the severity of the violation. However, core obligations — vulnerability management, 5-year support, SBOM, incident reporting — apply to all manufacturers regardless of size. Being an SME does not exempt you from CRA; it means you have more support resources and proportional enforcement, but the same fundamental obligations.

The Cyber Resilience Act has significant extraterritorial impact — similar to GDPR's global reach — because it applies to any product placed on the EU market: (1) Non-EU manufacturers: A US, Chinese, or South Korean manufacturer selling connected products in the EU must comply with CRA. They must either appoint an EU-authorized representative or ensure their EU importer/distributor accepts CRA obligations. (2) Global product design changes: Because EU market access is commercially critical, many global manufacturers will update product security practices globally rather than maintain separate EU-compliant and non-compliant product lines. Analysts call this the "Brussels Effect." (3) Trade negotiations: CRA has become a reference point in EU-US and EU-Asia technology trade discussions, with non-EU governments expressing concern about compliance burdens for their exporters. (4) SBOM and vulnerability disclosure as global standards: CRA's SBOM requirements align with US Executive Order 14028 and CISA guidance. The global convergence of SBOM standards (CycloneDX, SPDX) makes multi-jurisdiction compliance more tractable. (5) Third-country market access: Products CE-marked under CRA may enjoy preferential treatment in future EU trade agreements and mutual recognition arrangements. Manufacturers that invest in CRA compliance early gain a market access advantage in the EU and signal security maturity to enterprise buyers globally.

CRA conformity assessment requirements depend on the product classification: (1) Self-assessment (default class): Manufacturer conducts internal review against Annex I requirements, prepares technical file including risk assessment, SBOM, test results, and vulnerability management documentation, and issues a Declaration of Conformity (DoC). Affixes CE mark. No external auditor required. Risk: if the MSA later audits and finds self-assessment was inadequate, full non-compliance penalties apply. (2) Third-party assessment — Category I (important class, Annex III): Manufacturer can choose either: (a) Demonstrate conformity with a harmonized standard (EN 18031 series, when published) or a European Cybersecurity Certificate at "substantial" level — this allows self-declaration based on standard conformity; OR (b) Engage a CRA-notified body (accredited conformity assessment body designated by an EU member state) for a full conformity assessment. (3) Mandatory third-party audit — Category II (critical class, Annex IV): Manufacturer must use a European Cybersecurity Certificate at "high" assurance level OR engage a CRA-notified body for a comprehensive audit including source code review and penetration testing. Self-assessment is not permitted for Category II. For Category I and II, notified body capacity is limited — manufacturers should begin engagement in early 2026 to secure assessment slots before the 2027 deadline.

The Cyber Resilience Act and AI Act (Regulation (EU) 2024/1689) both apply to AI-enabled products with digital elements, creating overlapping obligations: (1) AI-enabled products: If your product contains an AI component (e.g., an IoT camera with on-device ML inference, or a cybersecurity tool using AI for threat detection), it may simultaneously be: a product with digital elements under CRA (mandatory security, vulnerability management, SBOM), and an AI system under the AI Act (risk classification, conformity assessment, transparency requirements). (2) CRA as cybersecurity baseline for AI products: The AI Act's high-risk AI system category requires "appropriate" cybersecurity measures — CRA's Annex I provides the specific technical baseline. In practice, CRA compliance satisfies the AI Act's cybersecurity requirement for high-risk AI products. (3) Conformity assessment alignment: The European Commission is working on aligning CRA and AI Act conformity assessment processes to avoid duplicate auditing for products within scope of both regulations. (4) CE marking: Both regulations result in CE marking; manufacturers of dual-scope products must satisfy both regulations' requirements before affixing the CE mark. Companies developing AI-integrated products should plan for both regulatory programs concurrently — they share common themes (risk assessment, documentation, vulnerability management) and their implementation workstreams can be meaningfully combined.

Key pitfalls manufacturers must avoid when preparing for CRA: (1) Assuming SaaS is out of scope: If your cloud service has any installed client component (agent, SDK, plug-in), that component is in scope. Audit all product touchpoints before concluding you are exempt. (2) Treating compliance as a one-time project: CRA mandates ongoing vulnerability management for 5 years after market placement. Compliance is a continuous operational program, not a pre-launch checklist. (3) Ignoring SBOM early: Building SBOM capability into existing SDLC tooling takes 6–12 months. Starting late creates a scramble before the 2027 deadline. Adopt CycloneDX or SPDX tooling now. (4) Underestimating notified body demand: For Category I/II products, notified body assessment takes 3–6 months and capacity is limited. Manufacturers who start in mid-2027 will miss the deadline. (5) Default password practices: CRA explicitly prohibits default identical passwords across all devices in a product line. This requires firmware changes and supply chain coordination; do not leave it until last. (6) No vulnerability disclosure channel: Manufacturers without a published vulnerability reporting process (security.txt, CVD policy) are immediately non-compliant from day one. Publish a policy now. (7) Forgetting the 10-year documentation retention: SBOM, risk assessments, and conformity documentation must be retained for 10 years after product end-of-support. Plan your document management accordingly. (8) Conflating CRA with NIS2 incident timelines: CRA's 24-hour window is for actively exploited vulnerabilities reported to ENISA — different from NIS2's 24-hour window for operational incidents reported to national NCAs. Both may apply simultaneously in some scenarios.

A CRA-compliant vulnerability management program must cover the full product lifecycle: (1) Pre-release: Conduct thorough security testing (SAST, DAST, penetration testing, fuzzing) before market launch. Document results in the technical file. (2) Dependency tracking: Maintain an up-to-date SBOM and monitor all components against public CVE databases (NVD, OSV, vendor advisories) continuously. Use automated tooling (Dependabot, Renovate, Grype, Trivy) to detect new CVEs in your dependency chain. (3) Severity triage: Classify each identified vulnerability using CVSS scoring. Critical (CVSS 9.0+) and high (7.0+) vulnerabilities require patches within defined SLAs (recommend: critical within 14 days, high within 30 days, medium within 90 days). (4) Patch development and testing: For embedded/hardware products, patch development must include regression testing and OTA update testing on representative hardware configurations. (5) Update delivery: Provide security updates via a secure, authenticated update mechanism. Users must be able to verify update integrity. (6) User notification: Notify users of available security updates, the vulnerabilities addressed, and recommended update urgency. (7) End-of-life planning: At least 12 months before the end of the support period, notify users and provide clear guidance on migration or continued safe use. (8) Active exploitation: Monitor threat intelligence feeds for evidence of active exploitation of your product's vulnerabilities. ENISA notification within 24 hours of confirmed active exploitation is mandatory. Document all steps, decisions, and timelines — vulnerability management records are a key part of CRA technical documentation subject to MSA audit.