Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (the Cyber Resilience Act)¹ entered into force on 10 December 2024. The Regulation aims to strengthen the EU’s approach to cybersecurity, address cyber resilience at EU level and improve the functioning of the internal market by laying down a uniform legal framework for essential cybersecurity requirements for placing products with digital elements on the EU market, as well as during the lifecycle of a product with digital elements.

The Cyber Resilience Act (CRA) is built upon the EU’s New Legislative Framework (NLF) set out in Regulation (EC) No 765/2008 of the European Parliament and of the Council of 9 July 2008 setting out the requirements for accreditation and market surveillance relating to the marketing of products and repealing Regulation (EEC) No 339/93 and Decision No 768/2008/EC of the European Parliament and of the Council of 9 July 2008 on a common framework for the marketing of products, and repealing Council Decision 93/465/EEC².

Market surveillance and enforcement is carried out by national market surveillance authorities. Products with digital elements that fall within the scope of the CRA are covered by Regulation (EU) 2019/1020 of the European Parliament and of the Council of 20 June 2019 on market surveillance and compliance of products and amending Directive 2004/42/EC and Regulations (EC) No 765/2008 and (EU) No 305/2011. The Commission and the European Union Agency for Cybersecurity (ENISA) support economic operators and Member States in the application of the CRA.

Article 26(1) of the CRA requires the Commission to publish guidance to assist economic operators in applying the Regulation, with a particular focus on facilitating compliance by microenterprises and small and medium-sized enterprises (SMEs). Article 26(2) sets out minimum aspects that should be addressed in the guidance. These include: (i) the scope of the CRA (particularly remote data processing solutions and free and open-source software); (ii) the notion of ‘support periods’; (iii) the interplay between the CRA and other EU legislation; and (iv) the concept of ‘substantial modification’.

On 3 December 2025, the Commission published a series of frequently asked questions (FAQs), which are intended to help economic operators prepare for the implementation of the CRA³.

This guidance is intended to help economic operators comply with the CRA and to support the activities of market surveillance authorities, notifying authorities and notified bodies, with a view to ensuring the harmonised enforcement of the CRA across the Union. This guidance is not intended to cover the CRA in its entire scope, but rather to provide clarifications on the rationale of certain key provisions and how they could be implemented in practice. This guidance concerns the CRA and is not applicable to other EU laws.

Stakeholders were extensively consulted in the preparation of this guidance, including the Expert Group on Cybersecurity of products with digital elements⁴ and through a public consultation held between 3 March and 13 April 2026⁵.

This guidance is not binding for economic operators or other actors subject to the CRA. An authoritative interpretation of the CRA may only be given by the Court of Justice of the European Union. Nevertheless, these guidelines set out the Commission’s interpretation of the CRA, with a view to supporting compliance and contributing to the effective implementation of the Regulation. Furthermore, the guidance contains a number of examples to illustrate the application of specific provisions. However, these examples are not intended to replace a case-by-case assessment, which will always be necessary to account for the specifics of each individual case.

In line with Article 26 of the CRA, the Commission may consider issuing further guidance, including guidance targeted at manufacturers subject to the CRA and other Union harmonisation legislation or to other related Union legal acts. This guidance may, for example, address questions on interplay between the CRA and Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (AI Act), and Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA).

The CRA applies to products with digital elements that are made available on the EU market. The concept of making available on the market is defined in Article 3(22) of the CRA as ‘the supply of a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge’. In accordance with Article 3(21), a product with digital elements is placed on the EU market the first time it is made available.

The latest edition of the ‘Blue Guide on the implementation of EU product rules’ published in 2022 (henceforth, ‘the Blue Guide’)⁶, provides guidance facilitating the understanding of the EU product rules and their uniform application across the different sectorial legal frameworks aligned to the new legislative framework (NLF), such as the CRA. The Blue Guide indicates that the concepts of ‘placing on the market’ and of ‘making available’ are to be understood as referring ‘to each individual product, not to a type of product, and whether it was manufactured as an individual unit or in series’ (Section 2.3).

For more ‘traditional’ products with digital elements covered by the NLF, such as hardware in the form of machinery or radio equipment products with digital elements, the concept of ‘placement on the market’ is well established, and the Blue Guide provides further guidance to clarify when such products are considered to be placed on the market. The ‘summary examples’ contained in the Blue Guide’s Section 2.12 provide further examples of the concept of ‘placing on the market’.

However, given the nature of intangible products with digital elements such as standalone software, further guidance is needed on when such products with digital elements are considered placed on the market. Once the software’s manufacturing phase is complete and the product with digital elements is offered to prospective users in the EU market, its manufacturer can be regarded as having manufactured multiple copies of the same software product with digital elements and having supplied them for distribution or use. In fact, unlike tangible products with digital elements, standalone software is not subject to physical production or stock limitations: each act of making the software available for download or distribution results in a new identical copy being created for the user. As long as this version of the software is not modified in a way that affects compliance with the CRA, the placing on the EU market is to be considered to have occurred at the moment of the first offering for distribution or use. The possibility of subsequent download or distribution of this version of the software product with digital elements is therefore to be regarded as an instance where this software product with digital elements is made available⁷.

Therefore, a standalone software product with digital elements should be considered to have been placed on the market when its manufacturing phase is complete and that software is first supplied for distribution or use on the EU market in the course of a commercial activity. The manufacturer should be considered to have placed on the market multiple copies of the same software product with digital elements at the same time. Therefore, while multiple copies of the same software remain individual products with digital elements, they are considered to be placed on the market at the same time, regardless of when possession or use of each individual copy is transferred to another natural or legal person. At the same time, where the manufacturer makes software available in different variants that differ in their included components, configurations or enabled functionalities (for example, builds for different operating systems or bundles with differing feature sets), those variants cannot be regarded as multiple copies of the same software product with digital elements. Therefore, they should be treated as distinct products with digital elements for the purposes of placing on the market.

Given the iterative nature of software development, it should be further clarified that subsequent iterations of a software product with digital elements are considered as newly placed on the market when those iterations qualify as a ‘substantial modification’ of a software product with digital elements already placed on the market, as indicated in recital 41 of the CRA. Iterations that do not qualify as substantial modifications do not require the manufacturer to perform a new conformity assessment procedure and therefore do not modify that software’s date of placement on the market. For more guidance on the concept of substantial modifications see Section 4 Substantial modifications.

The guidance laid down in points 13, 14 and 15 applies exclusively insofar as the product with digital elements is standalone software. This is not the case, for example, when the software is combined with hardware, as discussed in Section 2.4 Combination of hardware and software forming a product.

Article 3(1) of the CRA defines a product with digital elements as ‘a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately’. Such products with digital elements fall within the scope of the CRA where their intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.

The CRA therefore can cover a range of products with digital elements, including: (i) standalone software, such as apps and computer programs, whether digitally or physically distributed; (ii) hardware with embedded software (e.g. Internet-of-Things devices, laptops, tablets); (iii) standalone hardware (e.g. integrated circuits, motherboards); and (iv) any combination of hardware and software supplied separately but intended to operate together.

Standalone software therefore falls in scope of the CRA where it is placed on the market as a product with digital elements. It is helpful to distinguish between software products with digital elements that are subject to the CRA and the remote provision of services that do not fall in scope of the CRA.

For software to fall within the scope of the CRA, a software product with digital elements must be provided to a user, obtained by that user and operated on, or as part of, an electronic information system on the user’s side. Software that is downloaded, installed or otherwise supplied to the user and that executes on the user’s electronic information system meets these criteria, including for example where it takes the form of a browser extension or an application developed using web technologies but supplied for local execution.

By contrast, software that executes remotely and is merely accessed by the user is not, on that basis alone, a product with digital elements. Recitals 11 and 12 of the CRA, in fact, draw this distinction, by explaining that processing or storage at a distance is subject to the CRA only to the extent that it is necessary for a product with digital elements to perform its functions (i.e. through the concept of remote data processing as defined in Article 3(2)), and not themselves as products with digital elements. This is typically the case for web applications, including progressive web apps, where they are accessed exclusively through a web browser. The same applies to websites: whilst websites may, to a limited extent, technically run and execute on the user’s device, it follows from recital 12 of the CRA that websites are not themselves to be considered as products with digital elements, and fall within the scope of the CRA only where they support the functionality of a product with digital elements, i.e. to the extent that they qualify as remote data processing (as further explained in Section 8 and notably 8.1.2 Would the absence of such data processing prevent the product with digital elements from performing one of its functions?).

It is also useful to clarify whether source code can constitute a software product with digital elements. The CRA defines software as ‘the part of an electronic information system which consists of computer code’ (Article 3(4)). Computer code can take the form of (i) machine code, which is the set of instructions directly executed by a computer’s processor, written in binary format; or (ii) source code, i.e. the set of instructions and statements written in a programming language, which must be compiled or interpreted to be executed by a computer. The definition of software laid down in the CRA covers both.

A separate question is whether a given supply of computer code amounts to placing a product with digital elements on the EU market, which requires a supply in the course of a commercial activity. This may often not be the case for source code. For example, a natural or legal person that shares free and open-source computer code on publicly accessible repositories is generally not considered to be placing that code on the EU market for the purposes of the CRA (as discussed in more detail in Section 3 Free and open-source software). Unfinished code shared during the design and development phase of a product with digital elements (e.g. for testing or review) is also not considered to be placed on the market for the purposes of the CRA, as its manufacturing phase is not completed. Similarly, sample or demo code provided as part of tutorials or training materials is also not considered placed on the market for the purposes of the CRA⁸.

On the other hand, where a manufacturer provides its customers with computer code as a product with digital elements, that code is considered to be placed on the market, regardless of whether it is machine code or source code⁹.

Whether software forms part of a product with digital elements should be determined not by how or when that software is delivered to the user, but by whether, in light of the product’s intended purpose and reasonably foreseeable use, the software is necessary for the product with digital elements to perform its intended functions. Where a hardware product with digital elements is designed to work together with a specific software provided by the same manufacturer in order to perform its functions, the hardware and that software together constitute the product with digital elements. Software that is necessary to operate, configure, control or use a product with digital elements in accordance with its intended purpose is therefore part of the product with digital elements, even if it is obtained through a separate channel (e.g. an app store, a download link or another digital channel after the hardware product with digital elements has been placed on the market). Its placing on the market thus occurs at the same point in time as units of the hardware products with digital elements are placed on the market.

Article 2(1) states that the CRA ‘applies to products with digital elements made available on the market, the intended purpose or reasonably foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network’. The scope of the CRA is therefore anchored not in the mere presence of electronics, but in the capacity of a product with digital elements to exchange digital information.

While the terms ‘logical connection’ and ‘physical connection’ are defined in Article 3, the CRA does not define ‘data connection’ or ‘digital data’. It is therefore useful to set out an interpretation of what a data connection is, in order to clarify the boundary of the CRA’s scope. This boundary is particularly important to distinguish products with digital elements that merely use electrical signals from those that participate in digital communication and are therefore exposed to cybersecurity risks.

At its most basic level, a data connection involves transmitting information in binary form, i.e. as a sequence of 0s and 1s. Simply switching an output on and off (i.e. 0/1) does not by itself constitute a data connection if those states are not intended to represent data or are not read by a digital input. For a data connection to exist, the binary states must be deliberately encoded as information by a source and must be capable of being decoded as information at the destination. In other words, there must be a sender that deliberately generates digital symbols according to a defined scheme, and a receiver capable of interpreting those symbols as data. Where electrical or electronic signals are used solely to trigger or power a function, without conveying digitally encoded information, no data connection exists for the purposes of the CRA and therefore the product with digital elements does not fall within the scope of Article 2(1).

Products with digital elements within the scope of the CRA may consist not only of single devices or software components, but also of complex systems, including systems composed of multiple hardware and software elements that operate together to perform a certain function. Where such a system is placed on the market as a single product with digital elements, it constitutes a product with digital elements within the meaning of the CRA.

Such complex systems are often characterised by long design and development cycles, with contracts that may have been signed before the CRA applies, extended operational lifetimes and a high degree of technical and organisational complexity. Such systems, to be placed on the market after the CRA enters into application, may rely on components placed on the market before the CRA entered into application, on established architectures or on widely used interoperability standards, including standards referred to in other EU legislation or sector-specific frameworks. As a result, certain technical characteristics of those systems may be difficult or disproportionate to modify without affecting their intended purpose, safety, reliability or interoperability with existing infrastructure.

These characteristics do not in themselves exclude complex systems from the CRA’s scope. Rather, they illustrate the application of the CRA’s risk-based approach, which allows compliance to be demonstrated in different ways depending on the characteristics and constraints of the product with digital elements, in accordance with Article 13(3) of the CRA. Those characteristics form part of its intended purpose and operating context and are therefore relevant when assessing compliance with the essential cybersecurity requirements (the ‘essential requirements’). In particular, recital 55 explicitly recognises that certain essential requirements may not be fully compatible with the nature of a product with digital elements. For example, this may be the case where compliance would undermine mandatory interoperability requirements or the system’s proper functioning.

Accordingly, manufacturers are required to address cybersecurity risks on the basis of the cybersecurity risk assessment referred to in Article 13(2). As also explained in recital 55, in some cases, specific essential requirements are not applicable or cannot be fulfilled via the implementation of state-of-the-art security measures due to, for example, the system’s intended purpose, which requires the product with digital elements to interact with existing dependencies or to follow certain interoperability requirements. In such cases, manufacturers should identify and document those specific constraints, assess the associated risks, and implement appropriate alternative or compensatory risk-mitigation measures, so as to not undermine the security of the product with digital elements. For these purposes, both the technical documentation referred to in Article 31 and the information and instructions to the user referred to in Annex II play a key role in transparently describing the identified constraints, the associated cybersecurity risks and the risk-mitigation measures implemented. In accordance with the obligation to keep the risk assessment updated during the support period, manufacturers should also periodically reassess whether such constraints continue to exist. Where such constraints can be lifted or reduced over time, manufacturers should update the product with digital elements accordingly so that it can move towards an appropriate level of cybersecurity¹⁰.

In some cases, a manufacturer will place on the market, after the CRA enters into application on 11 December 2027, units of a product with digital elements manufactured in accordance with a type or model designed and developed before the date of application of the CRA. In such cases, compliance with this Regulation does not necessarily require that those units of the product with digital elements be redesigned. The manufacturer is required to carry out a cybersecurity risk assessment in accordance with Article 13(2) of the CRA in order to determine, on the basis of the intended purpose and reasonably foreseeable use of the product with digital elements, which of the essential requirements set out in Part I of Annex I are applicable to that product with digital elements, and how those requirements are implemented.

Where the outcome of that risk assessment demonstrates that the product with digital elements already incorporates appropriate and effective security measures addressing the relevant risks, the manufacturer may rely on those existing measures to demonstrate compliance with the CRA. The CRA does not in itself impose an obligation to introduce new security features or to redesign the product with digital elements where this is not necessary to address the identified risks.

Nevertheless, the manufacturer remains subject to the obligations laid down in the CRA. These include making sure, before the product with digital elements is placed on the market, that the applicable conformity assessment procedure has been carried out, the EU declaration of conformity has been drawn up and the CE marking affixed. Compliance with those requirements is independent of whether the design of the product with digital elements required modification as a result of the risk assessment. For products with digital elements designed before the date of application of the CRA, but placed on the market after that date, when it is not possible for the manufacturer to demonstrate how the risk assessment has been taken into account during the design and development phase of the product with digital elements, the obligation of Article 13(2) should be understood as requiring manufacturers to perform a cybersecurity risk assessment and demonstrate on that basis that the product with digital elements incorporates adequate security measures with a view to minimising cybersecurity risks, preventing incidents and minimising their impact, including in relation to the health and safety of users.

Accordingly, products with digital elements designed before the CRA entered into application might be placed on the market under the CRA without redesign, provided that the manufacturer can demonstrate, through the cybersecurity risk assessment and the technical documentation, that the product with digital elements achieves an appropriate level of cybersecurity in light of its intended purpose and reasonably foreseeable use and complies with the cybersecurity essential requirements.

Furthermore, it is helpful to clarify the application of conformity assessment obligations for manufacturers of products with digital elements that are placed on the market after the CRA enters into application, but manufactured in accordance with a type or model designed and developed before that date. In accordance with Article 13(12), the manufacturer is required to demonstrate via the relevant conformity assessment procedure that its product with digital elements is in conformity with the applicable essential requirements and to include evidence to that effect in the product’s technical documentation (point 6 of Annex VII).

However, the application of such requirements needs to be interpreted in light of the cybersecurity risk assessment and the cybersecurity risk profile of the product with digital elements. Particularly in the case of products with digital elements designed before the date of application of the CRA (but placed on the market after that date) and subject to the conformity assessment procedures of Article 32(1), where the risk assessment demonstrates that the product with digital elements already incorporates appropriate and effective security measures addressing that product’s risks, the obligation to provide evidence as part of the conformity assessment procedure should not be understood as requiring the manufacturer to provide test results covering the original design and development phases of such products with digital elements. This would not be necessary as it would not be contributing to increasing the security of the product with digital elements itself. Where tests may nonetheless be necessary, manufacturers are not expected to provide evidence of tests carried out on all product variants, but can group such tests across families of products with digital elements, as further discussed in Section 7.4 Reuse of risk assessments and conformity documentation for families of products with digital elements.

Nonetheless, the manufacturer should provide evidence of how it complies with the vulnerability handling processes laid down in Part II of Annex I, it should keep its risk assessment updated in line with Article 13(3), as well as fulfil all other obligations laid down in the CRA, including by providing users with information and instructions in accordance with Article 13(18).

The CRA places key responsibilities on economic operators that supply products with digital elements in the EU market. It defines the manufacturer as the natural or legal person that supplies a product with digital elements under its name or trademark, and that does so in the course of a commercial activity (thereby placing it on the market). Similarly, an importer is the natural or legal person established in the EU that supplies the product with digital elements of a person established outside of the EU, and that does so in the course of a commercial activity (thereby placing it on the market). The obligations of stewards apply to the legal person that supplies a FOSS intended for commercial activities¹², but does not place it on the market within the meaning of the CRA.

Therefore, to determine whether a natural or legal person is placing FOSS on the EU market, first it needs to be clarified whether that natural or legal person is actually supplying the FOSS. To correctly establish the applicable obligations under the CRA, it is essential to determine whether the natural or legal person is indeed performing the action of supplying a FOSS. In fact, as recalled in recital 18, the CRA does not apply to natural or legal persons who contribute source code to products with digital elements qualifying as FOSS that are not under their responsibility.

Given the specificities of the development of FOSS, which often involves multiple contributors, decentralised collaboration models and a separation between contribution and decision-making, it is useful to clarify that FOSS is considered to be 'under the responsibility' of natural or legal persons who publish it and exercise primary control over its development, releases, and distribution decisions (often referred to as ‘maintainers’). Persons who contribute source code but do not control releases, roadmaps, or governance decisions are considered ‘contributors’; in such cases, the FOSS is not under their responsibility, even though they contributed code to it. The mere existence of technical permissions, such as commit access, is not sufficient to establish that the FOSS is under that person’s responsibility; responsibility lies with those who publish and control the FOSS.

Once it is established that a FOSS is under the responsibility of a natural or legal person, it needs to be established whether that person supplies it in the course of a commercial activity, thereby constituting a placement on the market.

The CRA introduces the novel legal category of ‘open-source software steward’ in light of ‘the importance for cybersecurity of many products with digital elements qualifying as free and open-source software that are published, but not made available on the market within the meaning of the [CRA]’ (recital 19 of the CRA).

In some cases, a FOSS is published but not made available on the market within the meaning of the CRA by a legal person who ‘has the purpose or objective of systematically providing support on a sustained basis for the development of [FOSS] […] intended for commercial activities, and that ensures the viability of those products’ (Article 3(14) of the CRA). In such cases, that legal person is subject to the obligations of stewards.

A steward is defined as ‘a legal person, other than a manufacturer’ because a manufacturer, by definition, is the natural or legal person who places products with digital elements on the market (‘markets them’) under its own name or trademark. A legal person can be a steward only to products with digital elements qualifying as FOSS that are published, but not made available on the market within the meaning of the CRA. The concept of steward, therefore, applies to specific instances of FOSS that ‘are ultimately intended for commercial activities, such as for integration into commercial services or into monetised products with digital elements’ (recital 19 of the CRA¹³) but not made available on the market within the meaning of the CRA, and for which the legal person publishing that FOSS ensures systematic support.

Being a steward for one specific FOSS does not mean that that legal person is necessarily also a steward for other FOSS that it publishes. Similarly, being a manufacturer for one specific FOSS does not mean that the legal person may not be a steward for other FOSS. This includes providing ‘community’ versions of the same FOSS, as described in Section 3.2.1 Charging a price.

A legal person may therefore simultaneously be a steward for one specific FOSS (where the steward systematically provides support on a sustained basis and ensures the software’s viability) and a manufacturer for another specific FOSS (where it places it on the market). In other words, the same legal entity can be required to fulfil different roles for different FOSS projects.

For each specific FOSS that it publishes, the legal person will need to ascertain whether that FOSS is considered to be placed on the market within the meaning of the CRA. If so, that makes the legal entity the software’s manufacturer. If the FOSS is not considered to be placed on the market, the legal person may be the steward to it, if the software is intended for commercial activities and if the legal person is sustaining it in line with the definition of steward¹⁴.

As already mentioned in Section 3.1 Determining if free and open-source software is under one’s responsibility, the CRA clarifies that it does not apply ‘to natural or legal persons who contribute with source code to products with digital elements qualifying as free and open-source software that are not under their responsibility’ (recital 18).

Manufacturers of products with digital elements that integrate FOSS components into their own products with digital elements also do not become responsible for such components’ individual compliance with the CRA, even where the manufacturers contribute source code to their maintenance.

Similarly, the mere fact that manufacturers integrate FOSS components into their own (monetised) products with digital elements has no impact on the status of that FOSS component under the CRA. Maintainers of FOSS components that are not placed on the market do not bear obligations in relation to other entities that may integrate such components into their products with digital elements. Whether the CRA applies to a given FOSS component depends solely on whether the natural or legal person that publishes it places it on the market.

Nonetheless, manufacturers of products with digital elements that integrate FOSS components are required to comply with the CRA for their own products with digital elements. They also have a due diligence obligation, in accordance with Article 13(5), towards the FOSS components that they integrate. In addition, they are required to report vulnerabilities in integrated components and share security fixes in accordance with Article 13(6). For more guidance on this topic, see Section 9.2.1 Reporting upstream and sharing security fixes.

The examples listed below are completely hypothetical and only meant to illustrate different cases as explained in the sections above.

As stated in recital 42 of the CRA, ‘where a product with digital elements is subject to ‘refurbishment’, ‘maintenance’ and ‘repair’ as defined in Article 2, points (18), (19) and (20), of Regulation (EU) 2024/1781 of the European Parliament and of the Council, this does not necessarily lead to a substantial modification of the product, for instance if the intended purpose and functionalities are not changed and the level of risk remains unaffected. However, an upgrade of a product with digital elements by the manufacturer might lead to changes in the design and development of that product and might therefore affect its intended purpose and compliance with the requirements set out in this Regulation’. This is consistent with Section 2.1 of the Blue Guide, which recalls that ‘a product subject to important changes or overhaul after it has been put into service must be considered as a new product if: i) its original performance, purpose or type is modified, without this being foreseen in the initial risk assessment; ii) the nature of the hazard has changed or the level of risk has increased in relation to the relevant Union harmonisation legislation; and iii) the product is made available (or put into service if the applicable legislation also covers putting into service within its scope). This has to be assessed on a case-by-case basis and, in particular, in view of the objective of the legislation and the type of products covered by the legislation in question’.

Operations of refurbishment, maintenance or repair which result in physical modifications of products with digital elements already placed on the market do not necessarily amount to substantial modifications. A case-by-case assessment should therefore be performed, to ascertain whether such physical modification affects the compliance of the product with digital elements with the essential requirements of Part I of Annex I, or results in a change to the product’s intended purpose covered by the cybersecurity risk assessment.

Replacing defective parts or worn items by parts that perform better (e.g. because of technical progress or because the old part is no longer produced) does not in itself trigger a substantial modification of the repaired product with digital elements. It only does so if the performance change or the way the repaired product with digital elements operates (i) affects its compliance with the essential requirements or (ii) results in a change to the intended purpose that was not covered by the risk assessment.

Article 2(6) of the CRA establishes that spare parts intended to replace identical components and manufactured according to the same specifications as those components are not subject to the CRA. Recital 29 further states that the exemption covers both spare parts for products with digital elements made available before the CRA entered into application, and spare parts that have already undergone a conformity assessment procedure as laid down in the Regulation.

The exemption in Article 2(6) of the CRA should be understood as applying only where the spare part is specifically supplied to repair or extend the durability of a product with digital elements already placed on the market (before or after 11 December 2027). Where a product with digital elements is supplied as a standalone product, without any connection to the maintenance or repair of a pre-existing product with digital elements, it is placed on the market within the meaning of the CRA and should not be considered a spare part falling within the scope of Article 2(6). The maintenance or repair purpose should be apparent from the context of the supply, for example through identification of the product with digital elements or product family in the order or commercial offer, or through supply via after-sales or service channels. Supporting evidence to that effect should also be kept available to market surveillance authorities. The fact that a product with digital elements could technically be used to replace a component is not, in itself, sufficient to bring it within the scope of the exemption in the absence of such elements.

Accordingly, where a spare part is identical to a component already included in a product with digital elements either placed on the market before the CRA’s date of application or that has been placed on the market in compliance with the CRA, that spare part is not itself subject to the CRA.

The assessment of whether a spare part should be considered identical to a component should focus on its functional role in the product with digital elements and the characteristics that may be relevant to cybersecurity. While a case-by-case assessment is always needed, differences that do not affect the security characteristics or the cybersecurity risk profile of the component do not, in themselves, prevent that spare part from falling within the scope of Article 2(6) of the CRA.

By contrast, differences in characteristics relevant to the cybersecurity of the component, such as algorithms, protocols, cryptographic mechanisms, access control features or other security-relevant characteristics, may mean that the new part cannot be considered identical to the component it is intended to replace.

Where a spare part is not identical to the original component, that spare part constitutes a product with digital elements in its own right and is therefore subject to the CRA. In such cases, compliance with the essential requirements must be assessed in light of the replacement component’s intended purpose. Of particular relevance is the replacement component’s function of ensuring compatibility or interoperability with an existing product with digital elements, including where that product is a product with digital elements placed on the market before the CRA entered into application. Where certain essential requirements cannot reasonably be met due to that intended purpose or technical constraints, the manufacturer must reflect this in the cybersecurity risk assessment and implement appropriate alternative or compensatory risk-mitigation measures, in order not to undermine the security of the product with digital elements. As also discussed in Section 2.6 Complex systems, both the technical documentation and the information and instructions to the user play a key role in transparently describing the identified constraints, the associated cybersecurity risks and the risk-mitigation measures implemented. As explained in Section 4.1 Physical repairs, replacing defective parts or worn items by parts that perform better does not in itself trigger a substantial modification of the repaired product with digital elements.

The exemption for spare parts applies regardless of whether the spare part replaces a component within a product with digital elements or whether it replaces a complete product with digital elements that itself forms part of a larger product, including where that larger product with digital elements is composed of several integrated components, provided that the replacement part is specifically supplied as a spare part, as explained in the preceding paragraphs.

Software development is iterative in nature, with software products with digital elements already placed on the market being frequently and continuously updated. In this context, it is useful to provide more guidance to ascertain when software is to be considered substantially modified. Such guidance is intended in particular to help manufacturers of software products with digital elements who make changes to their own products determine whether those changes amount to a substantial modification.

Recital 39 indicates that a product with digital elements is substantially modified where a change alters the level of cybersecurity risk, and where such altered or additional risk has not been considered by the manufacturer in its risk assessment and, consequently, in its implementation of the essential requirements. A manufacturer should therefore assess, on a case-by-case basis, whether a software update introduces new or increased cybersecurity risks, and whether such risks were already addressed in its risk assessment.

Where a manufacturer introduces new functionalities in a product with digital elements that result in a change to the product’s intended purpose as a whole, it is likely that the manufacturer did not consider such changes in its risk assessment. In such circumstances, the change would generally qualify as a substantial modification.

At the same time, however, it is possible that a manufacturer progressively introduces new functionalities already included in its risk assessment or that do not, in themselves, alter the cybersecurity risk profile of the product with digital elements. This may be the case, for example, where the manufacturer has anticipated the development of those functionalities, has already described and assessed the associated risks, and has implemented appropriate mitigation measures to ensure continued compliance with the essential requirements. This may also be the case where the new functionalities do not implement changes that introduce new or increased risks. Updates of this nature should therefore not be regarded as substantial modifications, as they do not increase the cybersecurity risk and consequently do not change the implementation of the essential requirements.

Conversely, even limited or seemingly minor new functionalities may introduce significant cybersecurity risks that impact compliance with the essential requirements. The assessment of substantial modification should therefore not be based on the scale or complexity of the change, but on its potential adverse impact on the cybersecurity risk profile of the product with digital elements and consequently the implementation of the essential requirements.

In line with recital 39 of the CRA, security updates are generally not to be regarded as substantial modifications, as their primary purpose is to reduce the level of cybersecurity risk associated with the product with digital elements. A security update that does not modify that product’s intended purpose and does not introduce new cybersecurity risks should therefore not be considered a substantial modification, even where that update may introduce significant technical changes. This includes where certain functionalities are modified or constrained solely for the purpose of mitigating identified vulnerabilities and ensuring continued compliance with the essential requirements.

By contrast, a security update may qualify as a substantial modification where, notwithstanding its security objective, the update results in the intended purpose of the product with digital elements being modified beyond what was originally foreseen or introduces new or increased cybersecurity risks. This may be the case, for example, where an update materially changes that product’s boundaries or dependency structure in a way not foreseen in the risk assessment, e.g. by materially altering data flows, or adding new externally reachable interfaces.

As stated in point 104 above, whether a software update constitutes a substantial modification should be assessed on a case-by-case basis. When performing this assessment, manufacturers may consider, in a non-exhaustive manner, whether the software update:

a. introduces new threat vectors, such as additional interfaces, communication channels, execution environments, or external dependencies through which threats could materialise;

b. enables new attack scenarios, including for example new ways in which unauthorised access, manipulation, interference or misuse of the product with digital elements, or of data processed by it, could plausibly occur;

c. changes the likelihood of previously identified attack scenarios, for example by lowering the effort or expertise required to exploit them, increasing exposure to untrusted actors, or weakening existing safeguards;

d. changes the potential impact of previously identified attack scenarios, including for example the scope of affected data or functions, the severity of operational, safety or economic consequences, or the ability to detect, contain or recover from an incident.

In some cases, a software update does not introduce new threat vectors, does not enable new attack scenarios, and does not materially alter the likelihood or impact of previously identified attack scenarios. This may indicate that the update does not introduce new or increased cybersecurity risks, provided that the assumptions and mitigation measures relied upon in the risk assessment remain valid and effective. It is therefore likely that the update does not qualify as a substantial modification.

Conversely, a software update may introduce new threat vectors, enable new attack scenarios, or materially alter the likelihood or impact of existing attack scenarios. In such cases, the manufacturer should reassess the cybersecurity risks of the product with digital elements and determine whether the essential requirements continue to be met, including whether the update introduces new or increased risks not foreseen in the risk assessment.

Whether a software update qualifies as a substantial modification is relevant when determining whether certain obligations under the CRA apply, as set out in point 91. However, irrespective of that qualification, manufacturers remain responsible for ensuring the security of software updates and of their product with digital elements during its support period, in accordance with the vulnerability handling requirements set out in Part II of Annex I to the CRA. Furthermore, regardless of whether software updates qualify as substantial modifications or not, manufacturers are required to keep the risk assessment and the technical documentation accurate, complete and continuously up to date, in accordance with Articles 13(7) and 31(2).

The consequences of a substantial modification carried out by an actor other than the original manufacturer of a product with digital elements already placed on the market are addressed in Articles 21 and 22 of the CRA. Article 21 concerns importers and distributors, while Article 22 concerns any natural or legal person other than the manufacturer, importer or distributor.

Where the substantial modification is carried out by the original manufacturer of the product with digital elements, the consequences derive from the generally established concept of substantial modification referred to in recital 41 of the CRA and are further elaborated in Section 2.1 of the Blue Guide. That section states that a product that has been subject to significant changes or an overhaul after being placed on the market is to be considered a new product where its original performance, purpose or type has been modified, the nature of the hazard has changed or the level of risk has increased, and the product with digital elements is made available on the market.

The generally established consequence is therefore that, where a modification of a product with digital elements qualifies as a substantial modification and the modified product with digital elements is made available on the market, it is to be treated as a new product with digital elements for the purposes of the CRA. As a result, the act of making the substantially modified product available on the market constitutes a new placing on the market. This applies whether the substantial modification is carried out by the original manufacturer or by another person. In order to ensure that the CRA is applied in a uniform and proportionate manner across the different categories of actor that may carry out a substantial modification, the following subsections address the resulting obligations of the person carrying out the substantial modification when the substantially modified product with digital elements is placed on the market. The consequences for the support period of the product with digital elements are addressed in Section 5 Support period.

As set out in Section 4.4 Consequences of a substantial modification, where a modification of a product with digital elements qualifies as a substantial modification and the modified product with digital elements is made available on the market, it is to be treated as a new product for the purposes of the CRA, and the act of making the substantially modified product with digital elements available on the market constitutes a new placing on the market. It is therefore useful to clarify the effect that this new placing on the market has on the support period of the substantially modified product with digital elements.

The support period of a substantially modified product with digital elements should be determined by reference to that product’s expected use time, in light of the criteria set out in Article 13(8) of the CRA. A substantial modification should therefore require a reassessment against those criteria, but does not automatically result in the support period being reset, or even extended. The relevant question is whether the substantial modification affects the factors that originally determined that product’s expected use time and, therefore, the original support period.

Where the substantial modification does not affect those factors, the criteria set out in Article 13(8) continue to indicate the same expected use time as originally determined, and the support period of the modified product with digital elements should align with the remaining expected use time of the product as originally placed on the market. This will typically be the case where the expected use time was determined primarily by factors that the modification does not alter, such as the physical durability of hardware components, where the substantial modification concerns only software functionality or back-end services.

Where the substantial modification affects the factors that originally determined the expected use time of the product with digital elements, the manufacturer should recalculate the support period to reflect the new expected use time, applying the Article 13(8) criteria accordingly. This may be the case, for example, of revitalising hardware modifications that extend that product’s operational life, or of a substantial reprogramming or rewrite of that product’s core software that materially changes its expected use time²⁰.

The core functionality of a product with digital elements refers to that product’s main features and technical capabilities, without which it would not be able to meet its intended purpose. It can be assessed in light of that product’s specific context and conditions of use, taking into account, among others, the information the manufacturer supplies in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation.

The functionality of a product with digital elements is rarely restricted exclusively to its core functionality, as products with digital elements often – if not always – perform additional functions that do not contribute to the product’s core functionality. This may also include incorporating components that have themselves the functionality of another important or critical product with digital elements. However, the fact that a product with digital elements performs functions other than or additional to those detailed in the technical descriptions of important or critical products with digital elements does not in itself prevent the product from having one such core functionality.

A product with digital elements may have the ability to perform the functions of an important or critical product category, but nonetheless have a core functionality different from that of such a product category. In those cases, that product with digital elements would not qualify as an important or critical product with digital elements. As stated explicitly in Article 7(1) of the CRA for important products with digital elements (and applying the same logic for critical products with digital elements), the mere integration of an important or critical product with digital elements does not in itself render the product with digital elements an important or critical product with digital elements.

Some products with digital elements may be similar to an important or critical product category, or belong to the same general product family, yet their core functionality may substantially exceed or fall substantially short of the core functionality of that category. This is not the case where a product with digital elements includes additional functionalities that merely complement or enhance the core functionality, which itself corresponds to that of an important or critical product category; in such cases, the product with digital elements retains the core functionality of that category and is classified accordingly. This assessment should be based on that product’s main features and technical capabilities, considered objectively in light of its intended purpose, and not on the way in which the product with digital elements is described or marketed, where that description does not reflect the product's actual technical characteristics.

A manufacturer may not misrepresent the core functionality of its product with digital elements in such a way as to escape the conformity assessment regime applicable to important or critical products with digital elements, e.g. by overly emphasising or downplaying the role of certain functionalities, so that the product substantially exceeds or falls short of a given core functionality. This would be the case, for example, where there are clear inconsistencies between promotional materials, instructions for use, and technical documentation.

A product with digital elements may not have more than one core functionality for the purposes of determining the applicable conformity assessment regime. In accordance with Annex VII of the CRA, as part of a product’s technical documentation, manufacturers are required to describe the intended purpose of their product with digital elements and the conformity assessment procedure they have followed. The product’s core functionality should therefore be clearly identified. This enables the correct identification of the applicable conformity assessment regime and allows market surveillance authorities to supervise and check that the Regulation is being applied correctly.

Some products with digital elements are placed on the market as single products with digital elements but are composed of distinct modules with separate functionalities. Where a manufacturer also makes those modules available on the market separately, such as in the case where they are offered for separate purchase, licensing or subscription, those modules constitute standalone products with digital elements in their own right. As such, they are to be classified on the basis of their respective core functionalities (and therefore subject to the appropriate conformity assessment regime on the basis of each module’s core functionality). This is without prejudice to modules supplied solely as components of an integrated product with digital elements and not made available separately; in such cases, the core functionality is determined at the level of the integrated product with digital elements.

Non-compliance with the obligations set out in Article 32 of the CRA may trigger administrative fines in accordance with Article 64(3).

Once the manufacturer has determined the core functionality of its product with digital elements, it needs to perform one of the applicable conformity assessment procedures. The manufacturer needs to ensure that the product with digital elements as a whole meets the essential requirements, considering, as appropriate, the security of the components or functionalities integrated into it.

A more stringent conformity assessment procedure, with the involvement of a thirdparty (based on module B+C, module H or cybersecurity certification schemes) is mandatory for important products with digital elements of class II (with the exception of those qualifying as free and open-source software, in accordance with Article 32(5)) and for critical products with digital elements²⁴. By contrast, important products with digital elements of class I (with the exception of those qualifying as free and open-source software, in accordance with Article 32(5)) are required to undergo a third-party conformity assessment procedure only if the manufacturer has not applied or has applied only in part relevant harmonised standards the references of which have been published in the Official Journal of the European Union (henceforth, ‘harmonised standards’), common specifications or European cybersecurity certification schemes at assurance level at least ‘substantial’ ²⁵.

Therefore, for an important product with digital elements of class I to be eligible for the internal control procedure, (i) all the applicable requirements of a relevant harmonised standard need to be applied; and (ii) the standard’s scope needs to cover at least all the cybersecurity risks associated to that product’s core functionality.

The scope of the product with digital elements may be broader than the scope foreseen by the relevant harmonised standard, and such additional functions may present different or additional cybersecurity risks. The manufacturer is always required to carry out a risk assessment pursuant to Article 13(2) and should consequently check whether implementing a harmonised standard covers all risks associated with the product with digital elements. Where implementing the standard does not cover all risks, the manufacturer should ensure via other means that its product with digital elements is in compliance with the essential requirements.

Therefore, if the manufacturer of an important product with digital elements of class I has applied a relevant harmonised standard that covers the risks associated to that product’s core functionality, it can decide to make use of the internal control procedure to demonstrate its product’s conformity. As part of its conformity assessment activities, the manufacturer will still be required to demonstrate that all risks applicable to its product with digital elements are addressed. Hence, where there is a gap between the coverage of the harmonised standard and the scope of the product with digital elements as a whole, the manufacturer still needs to document which additional measures it has put in place to treat those risks.

This is also the case where the product with digital elements integrates an additional function that is itself that of another important or critical product with digital elements. In fact, it is the core functionality of the product with digital elements as a whole, and not the functionality of the integrated components taken in isolation, that determines whether the product with digital elements belongs to the important or critical product category (and therefore the applicable conformity assessment regime). For example, if a product with digital elements has the core functionality of an important product with digital elements of class I, that product as a whole is subject to the conformity assessment regime applicable to important products with digital elements of class I, even though it integrates a component that is itself a critical product with digital elements. In these cases, where the manufacturer applies a harmonised standard covering the risks associated to that product’s core functionality, it is allowed to make use of the internal control procedure.

Article 27(1) of the CRA establishes that products with digital elements and processes put in place by the manufacturer which are in conformity with harmonised standards or parts thereof, the references of which have been published in the Official Journal of the European Union (OJEU), are presumed to be in conformity with the essential requirements of the CRA covered by those standards or parts thereof ²⁶. Article 27(5) extends the same presumption of conformity to products with digital elements and processes put in place by the manufacturer which are in conformity with common specifications adopted by the Commission via implementing acts, and Article 27(8) establishes the presumption of conformity for products with digital elements and processes put in place by the manufacturer for which an EU statement of conformity or certificate has been issued under a European cybersecurity certification scheme adopted pursuant to Regulation (EU) 2019/881, if this has been specified via delegated acts in accordance with Article 27(9) ²⁷.

Therefore, where the manufacturer has applied a harmonised standard whose references have been published in the OJEU, it benefits from a presumption of conformity for the risks covered by that standard. This could be the case, for example, where the referenced harmonised standard addresses all the risks associated with the core functionality of a product with digital elements and there are no additional functionalities that present cybersecurity risks. For instance, it is expected that the harmonised standard for routers will address at least the risks associated with the core functionality of these products with digital elements. If such a product does not contain any additional functionalities or if these additional functionalities do not present risks unaddressed by the standard, the product with digital elements can benefit from presumption of conformity.

In the cases discussed in points 151 and 152, the manufacturer is allowed to use the internal control procedure because the harmonised standard covers the risks associated with the core functionality of the product with digital elements. However, the products with digital elements described in those examples may be broader than the scope of the harmonised standards, and additional functionalities may present cybersecurity risks that are not addressed by such harmonised standard. Those products with digital elements may therefore not benefit from presumption of conformity for those additional functionalities.

The cybersecurity risk assessment provided for in Article 13(2) of the CRA requires manufacturers to identify relevant risks and assess their potential impact on the product with digital elements. Manufacturers also need to implement appropriate measures to address those risks, in accordance with the essential requirements of Annex I.

In organisational risk management, risks are commonly evaluated against acceptance criteria derived from the organisation’s internal objectives or risk appetite. By contrast, under the CRA, residual cybersecurity risk should be assessed in light of the requirement that the product with digital elements placed on the market ensures an appropriate level of cybersecurity based on the risks, taking into account its intended purpose and reasonably foreseeable use.

Accordingly, the manufacturer’s internal risk tolerance, commercial strategy or mere cost considerations are not relevant in determining whether risks have been addressed. For the purposes of Articles 13(2) and (3), manufacturers must be in a position to determine whether identified cybersecurity risks have been sufficiently addressed through the implementation of the essential requirements of Part I of Annex I, in light of the intended purpose, reasonably foreseeable use and conditions of use, including, where relevant, the operational environment (for example the intended users of the product with digital elements) and the assets to be protected, taking into account the length of time the product with digital elements is expected to be in use.

Residual cybersecurity risk is an inherent outcome of risk assessment and risk treatment. It is recognised that cybersecurity risks cannot, in practice, be entirely eliminated. However, the existence of residual risk does not imply that any risk may be accepted at the manufacturer’s discretion. A product with digital elements may only be placed on the market where the residual risks, once appropriate measures have been taken, have been sufficiently addressed through the implementation of the essential requirements, taking into account the intended purpose and reasonably foreseeable use of the product with digital elements.

In accordance with Article 13(3), where cybersecurity risks are identified, manufacturers are required to address them through appropriate measures, including at product level. Depending on the circumstances, this may involve for example reducing the attack surface, implementing technical safeguards, limiting or adapting functionality, or defining the intended purpose of the product with digital elements more precisely. Manufacturers may also take steps to shape the reasonably foreseeable use of the product with digital elements, for instance through risk communication, user guidance, or user interface design, in order to steer user behaviour toward secure use patterns.

The CRA does not provide for the transfer of cybersecurity risk or responsibility to users or third parties to compensate for shortcomings in product design or to justify leaving cybersecurity risks unaddressed. The obligation to place a secure product with digital elements on the market and to demonstrate conformity with the essential requirements remains with the manufacturer.

Information and instructions provided to users may be used to support the secure deployment and operation of the product with digital elements, including where the manufacturer has chosen to restrict the intended purpose of that product to trusted environments, and to inform users of residual risks, in a manner that is appropriate to the nature of the product with digital elements and its intended users.

Where the cybersecurity risk assessment identifies risks that cannot be adequately addressed through appropriate measures, compliance with the CRA may require changes to the design, functionality or intended purpose of the product with digital elements. Considerations relating solely to cost or commercial feasibility do not constitute sufficient grounds for leaving such risks untreated where this would prevent the product with digital elements from meeting the essential requirements.

The essential cybersecurity requirement referred to in point (1) of Part I of Annex I to the CRA provides that products with digital elements are designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks.

This essential requirement is aimed at addressing all cybersecurity risks that have been identified as part of the cybersecurity risk assessment. Particularly, this includes cybersecurity risks that are not otherwise adequately addressed as part of the implementation of the essential requirements of Part I of Annex I other than point (1). This essential requirement is different from the legal obligation to carry out a cybersecurity risk assessment, which is to be carried out pursuant to Article 13(2).

Where all relevant cybersecurity risks related to a product with digital elements are treated by implementing adequate measures to address the applicable essential requirements other than point (1), the essential requirement referred to in point (1) of Part I of Annex I is deemed to be fulfilled. Conversely, where the cybersecurity risk assessment identifies additional risks not fully addressed by such measures, manufacturers are required to implement appropriate measures on the product with digital elements to address those risks, so that they comply with the essential requirement referred to in point (1) of Part I of Annex I. In practice, in most cases, compliance with the other essential requirements is expected to result in compliance with this requirement.

The CRA establishes two distinct but complementary obligations for manufacturers in relation to cybersecurity risk management. First, Article 13(2) requires manufacturers to carry out a cybersecurity risk assessment for the product with digital elements itself. Second, Article 13(5) imposes the obligation to exercise due diligence with respect to integrated components. Together, these two obligations are designed to ensure that the product with digital elements remains secure, including where it relies on remote data processing solutions, remote services, or third-party software or hardware components.

The cybersecurity risk assessment concerns the identification and management of relevant risks that may affect the product with digital elements, including risks that originate outside the product itself, such as external networks, environmental factors, or other external aspects which might affect the product with digital elements or on which the product relies. For such external risks, the CRA does not require manufacturers to control or govern the external environment. Rather, manufacturers are required to identify such risks and to mitigate them through the design and development of the product with digital elements itself. This will involve implementing the appropriate essential requirements set out in Part I of Annex I and, where necessary, providing information and instructions to users on integration or deployment risks.

For example, a manufacturer may identify a risk that unauthorised persons may gain access to back-end systems that are not part of the product with digital elements itself while the product is in operation, and attempt to send malicious commands to the product with digital elements. Such back-end systems, where they are not designed and developed by the manufacturer or under its responsibility, or where they do not support one of the functions of the product with digital elements, do not constitute remote data processing solutions and therefore fall outside the scope of the product with digital elements for the purposes of the CRA. Nonetheless, the CRA requires the manufacturer to address the risk they may pose through product-level measures, such as by requiring cryptographic authentication of remote commands, verifying the integrity of configuration changes, or generating security-relevant logs or alerts when abnormal behaviour is detected. Similarly, where a manufacturer identifies a risk resulting from such an external service becoming unavailable, for example due to power outages or failures of the infrastructure, the CRA may require product-level mitigation measures against such cybersecurity risks, e.g. ensuring that the outage does not cause the product with digital elements to enter into insecure states. In such cases, the CRA regulates how the product with digital elements responds to those external risks; it does not impose obligations on how the back-end infrastructure is organised, staffed or operated, nor does it treat that infrastructure as part of the product with digital elements.

Due diligence relates to elements that form part of the product with digital elements itself, in particular integrated software or hardware components provided by a third party. Manufacturers are required to take appropriate measures to ensure that such components do not undermine the compliance of the product with digital elements with the essential requirements. This can only be achieved by determining what the product with digital elements requires from its components in order to meet its cybersecurity objectives, and verifying, in a risk-based manner, that those components are in line with the product’s needs, as also indicated in recital 34.

In alignment with its cybersecurity risk assessment, the manufacturer has to identify the requirements that the integrated component should satisfy. For example, if the product with digital elements relies on cryptographic functions, update mechanisms or secure communications provided by a component, the manufacturer must, as part of its due diligence, identify those needs and verify that the component satisfies them. Evidence for this purpose may consist of documentation obtained from the component manufacturer, such as technical specifications, security documentation or relevant conformity or assurance documentation. Where appropriate, the manufacturer may also carry out tests to verify that those components adequately perform the relevant functions. While due diligence is a separate legal obligation, it supports and underpins the manufacturer’s ability to demonstrate compliance with the essential requirements for the product with digital elements as a whole.

When assessing the risks to the product with digital elements as a whole, elements outside of the product, such as environmental elements, external infrastructure, other systems or networks, must be considered in the cybersecurity risk assessment and, where relevant, addressed through product-level measures to ensure compliance of the product with digital elements with the essential requirements. Components that are physically or logically integrated into the product with digital elements but sourced from a third party must also be considered as part of the risk assessment. However, for compliance purposes, the manufacturer should treat those as externally supplied components whose properties are verified through due diligence upon integration, as the manufacturer may not have redesigned or redeveloped them.

The same logic applies during the development and integration of components. Where the manufacturer develops functionalities itself, it must directly implement the essential requirements. Where the manufacturer integrates components developed by others, it must ensure through due diligence, that those components can be used in a way that enables the product with digital elements as a whole to comply. In both cases, the objective remains the same: that the product with digital elements, as placed on the market, achieves an appropriate level of cybersecurity as required by the CRA, taking into account the risks identified in the cybersecurity risk assessment.

Manufacturers may place on the market products with digital elements that are similar, for example different variants, models or configurations of the same product family. Where such products with digital elements share the same architecture, security-relevant design and intended purpose, and are exposed to the same cybersecurity risks, the CRA does not require manufacturers to treat each variant as an entirely separate product with digital elements for the purposes of risk assessment and conformity assessment.

In such cases, provided that all variants concerned are adequately covered in terms of relevant risks and essential requirements, manufacturers may rely on: (i) a single cybersecurity risk assessment carried out in accordance with Article 13(2) of the CRA; (ii) a single set of technical documentation; and (iii) a single conformity assessment procedure. This also allows a single EU declaration of conformity to be issued for the group of products with digital elements, as long as it clearly identifies the product variants to which it applies.

The decisive factor is whether the differences between the variants are relevant to cybersecurity. Variations that do not affect the cybersecurity properties of the product with digital elements, such as differences in colour, form factor, memory size, or other non-security-relevant characteristics, do not require separate risk assessments or conformity assessments. Conversely, in some cases variants may differ in ways that affect the implementation of essential requirements, for example through different communication interfaces, software stacks, update mechanisms or remote connectivity. In such cases, those differences must be reflected in the risk assessment and, where necessary, in the conformity assessment and technical documentation.

Manufacturers remain responsible for ensuring that the risk assessment and the related documentation accurately reflect the products with digital elements placed on the market. Where a new variant introduces new cybersecurity risks or changes the way essential requirements are implemented, the existing risk assessment and conformity documentation must be updated accordingly. Reliance on a single conformity assessment is only possible to the extent that the products with digital elements do not present differences with regards to their cybersecurity properties.

The definition of remote data processing laid down in Article 3(2), thus, relies on three elements: (i) whether data processing is ‘at a distance’; (ii) whether the absence of such data processing would prevent the product with digital elements from performing one of its functions; and (iii) whether the software is designed and developed by the manufacturer, or under its responsibility. The next three subsections address each of these elements in more detail.

The CRA follows a risk-based approach, which is enshrined in Article 13(2) and (3), as well as in the first essential requirement of Part I of Annex I, whereby ‘products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks’. Consequently, a risk-based approach should be considered when applying the CRA requirements to the RDPS and the treatment of risks stemming from third-party services integrated into the product with digital elements.

First, manufacturers should (i) indicate in the technical documentation that their product with digital elements has RDPS or relies on third-party remote solutions and (ii) describe such solutions. If the same RDPS supports several products with digital elements, the RDPS needs to be declared in each product’s technical documentation. The documentation concerning RDPS serving several products with digital elements may be re-used from one product conformity assessment to another.

As indicated in recital 11, the RDPS that are part of the product with digital elements and therefore subject to the product’s conformity assessment should be limited to those software modules that are responsible for the functionality of the product with digital elements, and to the interfaces those modules use with external services. Further back-end systems that carry out subsequent processing, and with which the product with digital elements does not directly interact, are not considered RDPS.

Nonetheless, those back-end systems remain external dependencies that must be assessed as part of the cybersecurity risk assessment and mitigated through product-level measures. In fact, the risk assessment performed by the manufacturer should consider: (i) risks related to RDPS; (ii) risks related to reliance on third-party remote solutions (similar to third-party components); and (iii) risks related to the product environment (e.g. underlying hardware). Manufacturers should implement security controls on the product with digital elements itself to mitigate those risks.

Furthermore, as part of the conformity assessment and/or the fulfilment of due diligence obligations related to third-party remote services, the following non-exhaustive list of assurance artefacts can be re-used in support of the manufacturer’s assessment:

1. a.

   evidence of fulfilment of obligations under Commission Implementing Regulation (EU) 2024/2690;

2. b.

   evidence of fulfilment of obligations under Regulation (EU) 2022/2554 (DORA);

3. c.

   statement of conformity or certificate obtained under a European cybersecurity certification scheme (adopted under Regulation (EU) 2019/881 ─ the Cybersecurity Act);

4. d.

   evidence of conformity with ISO/IEC 27017:2015 or ISO/IEC 27001:2022.

Finally, in their interactions with third-party remote service providers, manufacturers need to implement the most appropriate security measures based on their risk assessment (and, where appropriate, supported by the provider’s shared responsibility model). Those mitigation measures should include security controls for their products with digital elements and the verification of security measures provided by the third-party providers themselves (due diligence). A tool to mitigate such risks can be to embed security guarantees in their service level agreements (SLAs) with third-party providers, including assurances that providers adequately handle vulnerabilities. A major change in the solutions provided by the third-party remote services providers should not qualify as a substantial modification of the product with digital elements, as these elements are not under the manufacturer’s responsibility. However, as part of their due diligence obligations and to correctly mitigate risks stemming from the use of third-party providers, manufacturers are encouraged to ensure that their third-party cloud service providers keep them adequately informed about changes they implement on their solutions. Based on such information, manufacturers may need to revise their risk assessment. The updated risk assessment should consider whether the third-party service providers still provide sufficient guarantees in terms of cybersecurity and whether the product-level security controls are still adequate. In some cases, manufacturers may need to modify such controls or change third-party service providers.

Under Article 14(1) and (3) of the CRA, a manufacturer is required to notify simultaneously to the CSIRT designated as coordinator and to ENISA of (i) any actively exploited vulnerability contained in its product with digital elements that it becomes aware of; and (ii) any severe incident having an impact on the security of the product with digital elements that it becomes aware of.

In accordance with Article 69(3) and 71(2), second sentence, the obligation to comply with Article 14 applies from 11 September 2026 to all products with digital elements that fall within the scope of the CRA, including products with digital elements placed on the market before 11 December 2027. Furthermore, unlike the vulnerability handling obligations, which continue only for the length of a product’s support period, the reporting obligations continue to apply after a product with digital elements is no longer supported. Where a product with digital elements was placed on the market before 11 December 2027, or where its support period has ended, the manufacturer is not required to comply with the vulnerability handling obligations set out in Part II of Annex I.

It should be recalled that the obligation to notify such events applies once the manufacturer becomes aware that a vulnerability is being actively exploited or that a severe incident has occurred and has led to the security of its product with digital elements being compromised. Therefore, guidance on when a manufacturer is deemed to have become aware should help manufacturers determine the moment when the applicable reporting deadlines start.

Manufacturers may be subject to comparable reporting obligations under different EU acts. To ensure the concept of ‘becoming aware’ is interpreted consistently and to facilitate manufacturers’ compliance with those obligations, this guidance is aligned with recital 31 of Commission Implementing Regulation (EU) 2024/2690 and Section II(A) of the Guidelines 9/2022 on personal data breach notification under the GDPR.

In some cases, a manufacturer will detect a suspicious event, or a third party, such as an individual, a customer, an entity, an authority, a media organisation or other source will bring a potential incident or vulnerability to its attention. In such cases, the manufacturer should assess the suspicious event immediately to determine whether it constitutes an actively exploited vulnerability or a severe incident having an impact on the security of the product with digital elements. The manufacturer is therefore to be regarded as having become aware when, after such an initial assessment, it has a reasonable degree of certainty that: (i) a vulnerability contained in its product with digital elements is being actively exploited; or (ii) a severe incident has occurred and has led to the security of its product with digital elements being compromised.

Therefore, the point in time at which a manufacturer can be considered to be aware will depend on the circumstances of the specific actively exploited vulnerability or severe incident. In some cases, it will be relatively clear from the outset that a vulnerability is being actively exploited or that a severe incident is impacting the security of a product with digital elements. In others, it may take some time to establish whether a product with digital elements is affected by a vulnerability and whether that vulnerability is being exploited by a malicious actor, or whether an incident is impacting the security of a product with digital elements. However, the emphasis should be on prompt action to carry out the initial assessment to determine whether such conditions are indeed met, particularly where the vulnerability may pose a significant risk, and if so, to take remedial action and notify in accordance with the CRA.

Furthermore, the structure of the reporting obligations requires manufacturers to update their notifications progressively, as their internal investigations advance and their knowledge of the actively exploited vulnerability or incident becomes more detailed. In particular, manufacturers are required to submit an early warning notification containing limited information without undue delay and in any event within 24 hours of becoming aware. Additional information is subsequently required as part of the notification to be submitted without undue delay and in any event within 72 hours of becoming aware (‘72-hour notification’). The complete report needs to be submitted within 14 days after a corrective or mitigating measure is available for actively exploited vulnerabilities, or within one month after the 72-hour notification for severe incidents.

As also recalled in Section 3.3.1 Sustained support and ensuring viability of FOSS, open-source software stewards are also required to report actively exploited vulnerabilities in accordance with Article 24(3)³⁰. That obligation applies upon becoming aware of an actively exploited vulnerability, and not merely where a vulnerability exists in the codebase of a FOSS for which that entity is a steward. In practice, because FOSS components are typically integrated downstream into other products with digital elements, a steward is likely to become aware of active exploitation via reports from third parties, which identify exploitation in FOSS components as integrated into other products with digital elements. This may be the case, for example, where a manufacturer of a product with digital elements detects active exploitation in a FOSS component integrated into its own product and reports it to that component’s steward; or when a user or a security researcher finds evidence of exploitation of a FOSS component integrated in a product with digital elements and reports that active exploitation to the component’s steward.

It should also be clarified that, because the obligation to report actively exploited vulnerabilities applies when the manufacturer becomes aware of active exploitation, the manufacturer is not required to report vulnerabilities of whose active exploitation it had already become aware before 11 September 2026 (the date on which the reporting obligation starts to apply). The CRA, therefore, does not require the retroactive reporting of such vulnerabilities. By contrast, the obligation does apply where the manufacturer was aware of a vulnerability before 11 September 2026 but was not, at that time, aware of any active exploitation of it (either because none had yet occurred or because the manufacturer had not become aware of it). If, after 11 September 2026, active exploitation subsequently occurs or the manufacturer becomes aware of it, the vulnerability is deemed an actively exploited one subject to the reporting obligation.

Similarly, a manufacturer is only required to report actively exploited vulnerabilities contained in their product with digital elements. Where a product with digital elements contains an actively exploited vulnerability originating from a third-party component, the manufacturer of the product with digital elements is required to notify that actively exploited vulnerability. However, if a manufacturer is aware that a third-party component contains a vulnerability, but that vulnerability either (i) cannot be exploited in its product with digital elements (e.g. because the vulnerable code is not reachable) or (ii) has not been exploited in its product with digital elements, that vulnerability does not qualify as an actively exploited vulnerability contained in its product with digital elements, and therefore it is not subject to mandatory reporting for that manufacturer. That manufacturer can still notify that vulnerability on a voluntary basis, in accordance with Article 15 of the CRA. It is also required to comply with the vulnerability handling requirements of Part II of Annex I to the CRA, as well as to report the vulnerability to the person or entity manufacturing or maintaining the component, in accordance with Article 13(6), and as further explained in Section 9.2.1 Reporting upstream and sharing security fixes.

After becoming aware of an actively exploited vulnerability or a severe incident, manufacturers are also required, in accordance with Article 14(8), to inform impacted users and, where appropriate, all users. Where they fail to do so in a timely manner, the CSIRTs that received the notification may provide such information to users when this is considered proportionate and necessary to prevent or mitigate the impact of that vulnerability or incident.

In line with the CRA’s risk-based approach, the obligation to inform users laid down in Article 14(8) is to be applied in a risk-based and proportionate manner. In particular, the provision of information about an actively exploited vulnerability or a severe incident does not imply that such information must be made public or disclosed indiscriminately. Where appropriate, and in light of the nature of the product with digital elements, the affected users and the vulnerability or incident’s potential impact, manufacturers may limit the disclosure of detailed information to the relevant users or customers concerned. This is particularly the case for products with digital elements used in sensitive or essential environments, where public disclosure of technical details could itself increase cybersecurity risks or facilitate further exploitation.

Once the vulnerability has been adequately addressed or mitigated, broader disclosure may be appropriate. This would be the case, for example, where disclosure contributes to raising general awareness or enables users to verify that their products with digital elements are no longer affected. In such cases, the level of detail and the timing of any broader disclosure should remain proportionate and take into account the residual risks of exploitation, the nature of the product with digital elements and the interests of the users concerned. Furthermore, point (4) of Part II of Annex I requires manufacturers to publicly disclose information about fixed vulnerabilities once a security update has been made available.