Skip to main content

EU Commission’s guidance on the Cyber Resilience Act are out : what businesses need to know

1. INTRODUCTION

After years of legislative debate and a phased implementation timeline, the Cyber Resilience Act (Regulation (EU) 2024/2847, hereinafter "CRA") has been fully in force since December 2024. The CRA introduces horizontal, binding cybersecurity requirements for products with digital elements placed on the EU market. This marks a landmark shift in how economic operators (manufacturers, importers, distributors…) must approach cybersecurity throughout the entire product lifecycle. The reporting obligations will apply from 11 September 2026, and the main obligations will apply from 11 December 2027.

To assist economic operators and market surveillance authorities in navigating this complex framework and to support timely implementation, the European Commission published on 27 July 2026 a dedicated guidance, providing clarification on key concepts, scope delineations, and compliance obligations (hereinafter "Guidance"). The guidance is not binding for economic operators or other actors subject to the CRA. Nevertheless, they set out the Commission’s interpretation of the CRA with a view to supporting compliance and contributing to the effective implementation of the Regulation.

This ezine summarises the most important takeaways from the Guidance.

2. SCOPE

The CRA is applicable to products with digital elements that are made available on the European market.

A "product with digital elements" is defined broadly as software or hardware and its remote data processing solutions, including components placed on the market separately, and falls within the CRA's scope where its intended purpose or reasonably foreseeable use includes a direct or indirect data connection to a device or network. 

The Guidance clarifies several practical boundaries:

  • Software that runs on a user's device, including browser extensions and locally installed web apps, is a “product with digital elements”. Remote-only software, such as most websites and web applications, is generally outside the scope unless it supports an in-scope product via remote data processing.
  • A standalone software product is considered "placed on the market" once its manufacturing phase is complete and it is first supplied for distribution or use in the EU during a commercial activity. All copies of that same version are treated as placed on the market simultaneously, regardless of when individual users obtain them.
  • Later software iterations only trigger a new placement on the market where they constitute a "substantial modification". Routine updates that do not meet that threshold leave the original placement date unchanged.

  • Where hardware is designed to work together with specific software from the same manufacturer to perform its intended function, the hardware and software together form a single product with digital elements, even if the software is obtained through a separate channel, such as an app store.

  • The CRA's data connection requirement is not triggered by the mere presence of electronics: a genuine "data connection" requires digitally encoded information to be deliberately generated by a sender and capable of being decoded by a receiver. Signals used solely to trigger or power a function, without conveying encoded information, fall outside scope. In other words, if the product can send, receive or exchange data with another device or network, it falls within the scope of the CRA.
  • Complex products made up of different hardware and software components can still be treated as a single product with digital elements under the CRA. If legacy technology, long development cycles, or compatibility requirements make it difficult to meet certain cybersecurity requirements, manufacturers must document those limitations, assess the resulting risks, and take appropriate mitigating measures. The existence of such constraints does not remove the product from the CRA's scope.

3. FOSS (Free and Open-Source Software)

The Guidance clarifies that FOSS is generally subject to manufacturer obligations only when it is made available in the course of a commercial activity. Simply publishing or sharing open-source code does not, by itself, constitute placing software on the market. Individual contributors are generally not responsible for CRA compliance. Legal entities supporting non-commercial FOSS may qualify as open-source software stewards and be subject only to the limited obligations of Article 24 applicable to these stewards. Manufacturers that incorporate third-party FOSS into commercial products remain fully responsible for ensuring compliance with the CRA, including vulnerability management and due diligence requirements.

4. SUPPORT PERIOD AND SUBSTANTIAL MODIFICATIONS

Manufacturers must set a support period that reflects the product’s expected lifespan and ensure vulnerabilities are addressed throughout that period. The CRA’s five-year minimum is only a safeguard, not a default. Longer-lived products require longer support. Each substantially modified software version must have its own support period unless the modification does not affect the factors determining the product’s expected lifespan. Manufacturers may restrict vulnerability remediation to the latest version if users can upgrade free of charge, without incurring additional costs such as mandatory hardware purchases.

5. IMPORTANT AND CRITICAL PRODUCTS WITH DIGITAL ELEMENTS

Under the CRA, products classified as "important" or "critical" face stricter conformity assessment requirements. Classification is based on the product's core functionality, meaning the features essential to its intended purpose, rather than on ancillary features or embedded components. Manufacturers cannot avoid stricter requirements by misrepresenting a product's capabilities. While some lower-risk important products (class I) may rely on self-assessment, higher-risk important products (class II) and critical products generally require an independent third-party conformity assessment.

6. RISK ASSESSMENT, DUE DILIGENCE AND COMPONENT INTEGRATION

The Guidance distinguishes between the cybersecurity risk assessment of the product itself and the due diligence obligation relating to integrated third-party components. It emphasises that residual cybersecurity risks cannot be justified solely by cost, commercial considerations or a manufacturer's risk appetite, nor shifted to users or third parties. The Guidance also allows manufacturers to rely on a single risk assessment, technical file, conformity assessment and declaration of conformity for product families that share the same architecture, security design and risk profile, provided differences between variants do not affect their cybersecurity characteristics.

7. PRODUCTS DESIGNED BEFORE THE CRA APPLIES

The Guidance confirms that products designed before the CRA becomes applicable on 11 December 2027 do not automatically require redesign. Manufacturers must still perform a cybersecurity risk assessment and may rely on existing security measures where these adequately address identified risks. However, they remain subject to all other CRA obligations, including conformity assessment, preparation of an EU declaration of conformity and CE marking before the product is placed on the market.

8. WHAT NOW?

With reporting obligations starting 11 September 2026 and full compliance required by 11 December 2027, businesses should act now: identify which products fall within the CRA's scope, determine their risk classification, and address any gaps in existing risk assessments and documentation.

Authors