EU Cyber Resilience Act Requirements: A Practical Guide

For decades, the European Union has regulated the safety of physical products from toys to machinery. While largely exempting the software and firmware that increasingly runs them. That asymmetry is about to end.

The Cyber Resilience Act (CRA), formally adopted as Regulation (EU) 2024/2847 on 23 October 2024, establishes the first horizontal, mandatory cybersecurity framework for virtually every product with a digital component sold in the EU market. Its implications extend far beyond Brussels: any manufacturer, anywhere in the world, whose connected product reaches a European buyer will need to comply.

The stakes are significant. Non-compliant products face withdrawal from the EU market, and companies can incur administrative fines reaching €15 million or 2.5 percent of global annual turnover. But the CRA is not merely punitive. It represents a deliberate attempt to shift the burden of cybersecurity from end users (who are poorly equipped to evaluate software risk) back to the manufacturers who design, build, and maintain these products. For IoT device makers, embedded systems developers, and the enterprises that depend on them, understanding the CRA is no longer optional. It is a prerequisite for doing business in Europe.

The CRA is a directly applicable EU regulation that sets out essential cybersecurity requirements for all products with digital elements, a deliberately broad category encompassing hardware and software products that include any form of data connection, whether direct or indirect, logical or physical. The definition sweeps in everything from industrial control systems and network routers to smart home devices, consumer wearables, and standalone software applications.

The regulation addresses what European legislators described as two compounding failures: a low baseline level of cybersecurity across commercial products, reflected in widespread vulnerabilities and inconsistent patch delivery, and an information gap that prevents buyers from making informed security decisions. Prior EU cybersecurity law, including the NIS2 Directive and the EU Cybersecurity Act (Regulation 2019/881), focused on organizations and voluntary certification schemes rather than the products themselves. The CRA fills that gap with binding, product-level obligations.

CRA at a Glance: Key Facts

The situation with EU cyber resilience act implementation timeline can be tricky. Although the CRA entered into force on 10 December 2024, its obligations phase in over a staggered timeline. The first deadline is 11 June 2026, when provisions governing the notification of conformity assessment bodies take effect. This means Member States must have designated the bodies authorized to perform third-party cybersecurity assessments well before full enforcement begins.

The second (and for manufacturers, the more operationally consequential) milestone arrives on 11 September 2026. From that date, manufacturers must report actively exploited vulnerabilities and severe security incidents to the designated CSIRT (Computer Security Incident Response Team) coordinator and to ENISA via a single EU reporting platform. An early warning must be filed within 24 hours of discovery, a detailed vulnerability notification within 72 hours, and a final report no later than 14 days after a corrective measure becomes available.

Full compliance, covering all requirements, assessments, CE marking, and technical documentation, is required by 11 December 2027. That is considered to be the EU cyber resilience act entry into force date. Products placed on the market before that date are subject to the CRA only if they undergo a substantial modification after it, though the vulnerability reporting obligations under Article 14 apply retroactively to all in-scope products.

Products with Digital Elements

The CRA applies to any software or hardware product (and its associated remote data processing solutions) that has a direct or indirect logical or physical data connection to a device or network. This includes standalone software, firmware running on embedded devices, and cloud services that are integral to a product’s core functionality (for instance, the cloud backend of a smart home hub that enables remote device control). Websites and generic cloud infrastructure that do not support a specific product’s functionality are excluded.

Product Classification: Default, Important, and Critical

The EU CRA regulation establishes a tiered classification system that determines which procedures a product must undergo. The majority of products fall into the default category: they may demonstrate compliance through an internal self-assessment (based on Module A). Products classified as “important” are divided into two classes. Class I includes identity management systems, standalone browsers, VPN products, network management systems, SIEM platforms, operating systems, routers and modems, smart home devices with security functionalities, connected toys with interactive features, and microprocessors or FPGAs with security-related capabilities. Class II (carrying higher risk) covers hypervisors and container runtimes, firewalls, intrusion detection and prevention systems, and tamper-resistant microprocessors and microcontrollers. Class II products always require third-party conformity assessment. A separate Annex IV designates critical products (hardware security modules, smart meter gateways, and smartcards) which may be subject to mandatory European cybersecurity certification.

What Is Excluded from the CRA?

Several product categories fall outside the CRA’s scope because they are already regulated under sector-specific regimes that address cybersecurity. Medical devices covered by Regulation (EU) 2017/745 and in vitro diagnostics under Regulation (EU) 2017/746 are exempt, as are motor vehicles governed by Regulation (EU) 2019/2144 and aviation products certified under Regulation (EU) 2018/1139. Products developed exclusively for national security or defense purposes and those designed to process classified information are also excluded. Spare parts manufactured to identical specifications as the components they replace are exempt as well.

Security by Design and by Default

Annex I of the regulation lays out the cybersecurity requirements that products must satisfy at the point of market placement. Products must be designed and produced to ensure an appropriate level of cybersecurity based on their risk profile. They must ship without known exploitable vulnerabilities, in a secure-by-default configuration that the user can reset. They must protect against unauthorized access through authentication and access management, safeguard the confidentiality and integrity of stored and transmitted data using state-of-the-art encryption, minimize data processing to what is strictly necessary for the intended purpose, and limit their attack surface by design. Resilience against denial-of-service attacks and the ability to record security-relevant internal activity are also mandated.

Vulnerability Handling and Incident Reporting

The CRA imposes lifecycle-long vulnerability management obligations. Manufacturers must identify, document, and remediate vulnerabilities without delay, apply regular security testing, and maintain a coordinated vulnerability disclosure policy. When a fix is available, manufacturers must publicly disclose the vulnerability alongside clear remediation guidance. Actively exploited vulnerabilities trigger the staged notification obligations described above: early warning within 24 hours, detailed notification within 72 hours, and a final report within 14 days of the corrective measure.

SBOM Obligations

Under Part II of Annex I, manufacturers must identify and document all components contained in their products, including by drawing up a Software Bill of Materials (SBOM) in a commonly used, machine-readable format. The SBOM must cover at least the top-level dependencies of the product. While manufacturers are not obliged to make the SBOM public, market surveillance authorities may request it as part of compliance checks, and ENISA may use aggregated, anonymized SBOM data to conduct Union-wide dependency assessments. Particularly to map reliance on free and open-source software components.

Automatic Security Updates and OTA Requirements

Consumer-facing products must support automatic security updates enabled by default, with a clear opt-out mechanism. Manufacturers must also ensure that security updates can be delivered separately from functionality updates where technically feasible, so users are not forced to accept new features simply to receive critical patches. Each security update issued during the support period must remain available for a minimum of ten years or the remainder of the support period, whichever is longer.

Firmware and Embedded Software Compliance

For IoT manufacturers, the CRA reshapes the entire product development lifecycle. Firmware and embedded software must be developed under a documented cybersecurity risk assessment that is maintained and updated throughout the support phase. This assessment must analyze risks based on the intended purpose, foreseeable use, and operational environment of the product, and it must explicitly indicate which essential requirements from Annex I apply and how they have been implemented. Manufacturers integrating third-party components (including open-source libraries)bear a due diligence obligation to verify that those components do not compromise the cybersecurity of the final product.

Product Lifecycle and Support Period

The support period, during which the manufacturer must handle vulnerabilities effectively, must be no less than five years, unless the product’s expected use period is shorter. For hardware components like microprocessors, network devices, or industrial control systems that remain in service for a decade or more, manufacturers must set correspondingly longer support timeline. The dedicated Administrative Cooperation Group (ADCO) established by the CRA will publish statistics on average periods by product category and may recommend enforcement focus on categories where such timeframes appear inadequate.

CE Marking for Cybersecurity

Products that pass their required conformity assessment must bear the CE marking. The visible indicator that they meet the CRA’s cybersecurity requirements, enabling them to move freely within the internal market. For default-category products, an internal self-assessment suffices. For Important Class I products, self-assessment is permitted only if the manufacturer has applied harmonized standards, common specifications, or a recognized European cybersecurity certification scheme; otherwise, a third-party assessment is mandatory. For Important Class II and Critical products, third-party involvement is always required.

Healthcare IoT and Medical Devices

Medical devices placed on the EU market already subject to Regulation (EU) 2017/745 or 2017/746 are explicitly excluded from the CRA. However, a significant grey zone exists for health-adjacent connected products: personal wearable health monitors, wellness trackers, and remote patient monitoring peripherals that do not qualify as medical devices under existing EU regulation. Such products are expressly within the CRA’s scope. Annex III classifies personal wearable products intended for health monitoring, where the medical device regulations do not apply, as Important Class I products, requiring a heightened conformity assessment pathway.

Industrial IoT and Manufacturing

Industrial environments present particular challenges. Products with digital elements used in operational technology (OT) settings (PLCs, industrial gateways, SCADA components) are squarely within scope. The CRA’s automatic update requirements include a carve-out for products deployed in professional ICT networks and critical or industrial environments where automatic updates could cause operational interference. However, manufacturers must still provide timely security updates and notify users of available patches regardless of whether the update mechanism is automatic. The intersection of the CRA with IEC 62443, the primary international standard for industrial automation and control systems security, offers a practical alignment path: manufacturers who already conform to IEC 62443 will find significant overlap with the CRA’s essential requirements, though the CRA’s SBOM, incident reporting, and CE marking obligations are additional.

The CRA operates alongside, rather than replacing, the EU’s other cybersecurity instruments. The NIS2 Directive (Directive 2022/2555) establishes risk management and incident reporting requirements for essential and important entities (organizations, not products). NIS2-regulated entities are expected to use CRA-compliant products as part of their supply chain security obligations, creating a pull-through demand effect. The EU Cybersecurity Act (Regulation 2019/881) provides a voluntary certification framework for ICT products, processes, and services. CRA-compliant products certified under an EU cybersecurity certification scheme benefit from a presumption of conformity, and certification at the “substantial” assurance level eliminates the need for a separate third-party CRA assessment. In sum, the NIS2 Directive governs the behavior of organizations, the EU Cybersecurity Act provides voluntary certification, and the CRA mandates product-level compliance, together forming a layered regulatory architecture.

The CRA’s penalty regime is calibrated to the severity of the infringement. Failure to meet the cybersecurity requirements in Annex I, or the obligations under Articles 13 and 14 (manufacturer obligations and reporting duties), can attract fines of up to €15 million or 2.5 percent of global annual turnover, whichever is higher. Breaches of other obligations (such as those governing importers, distributors, conformity assessment, or technical documentation) carry fines of up to €10 million or 2 percent of turnover. Supplying incorrect or misleading information to authorities can result in fines of up to €5 million or 1 percent of turnover. Micro and small enterprises are exempt from fines for missing the 24-hour early warning deadline, and open-source software stewards are exempt from administrative fines entirely.

The treatment of open-source software was one of the CRA’s most debated provisions during its legislative passage. The final regulation draws a clear line: free and open-source software that is not monetized by its developers and is not supplied in the course of a commercial activity falls outside the CRA’s scope. Contributors who provide source code to open-source projects are not liable under the regulation. However, if a manufacturer integrates open-source components into a commercial product, the manufacturer bears the due diligence and vulnerability handling obligations for those components. A new category of “open-source software stewards”, organizations that provide sustained development support to open-source projects intended for commercial integration, is subject to a lighter-touch regime: they must document a cybersecurity policy and report vulnerabilities, but they do not bear the full manufacturer obligations and cannot affix CE marking.

Step 1: Conduct a product scope assessment.

Determine which of your products qualify as products with digital elements and whether they fall into the default, Important (Class I or II), or Critical category. This classification dictates the conformity assessment pathway.

Step 2: Perform a cybersecurity gap analysis.

Map your current security posture against the requirements in Annex I. Identify gaps in secure-by-default configurations, encryption practices, access controls, update mechanisms, and vulnerability handling processes.

Step 3: Implement security by design in development.

Integrate cybersecurity risk assessments into your product planning, design, and development workflow. The CRA requires documented risk assessments that are maintained throughout the support period, not a one-time exercise.

Step 4: Build vulnerability management processes.

Establish a coordinated vulnerability disclosure policy, set up the reporting infrastructure needed to meet the 24-hour early warning and 72-hour notification deadlines, and create a process to distribute security updates promptly and free of charge.

Step 5: Prepare technical documentation and SBOM.

Compile the technical documentation set required by Annex VII, including your cybersecurity risk assessment, system architecture descriptions, SBOM in a machine-readable format, and the EU declaration of conformity.

The EU Cyber Resilience Act represents the most ambitious attempt by any jurisdiction to regulate the cybersecurity of commercial digital products at a horizontal level. Its phased timeline, with vulnerability reporting obligations beginning in September 2026 and full compliance due by December 2027, gives manufacturers a narrow but navigable window to prepare. For IoT and embedded systems companies, the priority actions are clear: classify your product portfolio, gap-assess your security posture against the Annex I requirements, build SBOM generation and vulnerability handling capabilities, and prepare for third-party conformity assessment where required. The CRA will reshape the competitive landscape for connected products in Europe, and companies that treat compliance as a strategic investment rather than a regulatory burden will be best positioned to thrive.