1.1 The Cyber Resilience Act

1. 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 a product’s lifecycle.

2. 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.⁽²⁾

3. 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.

1.2 Purpose of the guidance

4. 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’.

5. 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.⁽³⁾

6. 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.

7. Stakeholders were extensively consulted in the preparation of this guidance, including the Expert Group on Cybersecurity of Products with Digital Elements⁽⁴⁾ and [via a public consultation].

8. 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. A case-by-case assessment will always be necessary to account for the specifics of each individual case.

9. 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).

2.1 Placing on the market

10. The CRA applies to products with digital elements (or simply ‘products’) 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 is placed on the EU market the first time it is made available.

11. 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).

12. For more ‘traditional’ products covered by the NLF, such as hardware in the form of machinery or radio equipment products, 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’.

13. However, given the nature of intangible products such as standalone software, which is supplied via digital means, further guidance is needed on when such products are considered placed on the market. Once the software’s manufacturing phase is complete and the product is offered to prospective users in the EU market, its manufacturer can be regarded as having manufactured a virtually infinite number of copies of the same software product and having supplied them for distribution or use. In fact, unlike tangible products, software supplied via digital means is not subject to physical production or stock limitations: each act of making the software available for download or remote access 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 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 remote access to this version of the software product is therefore to be regarded as an instance where this software product is made available.

14. Therefore, a standalone software product 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 a virtually infinite number of copies of the same software product at the same time. Therefore, while multiple copies of the same software remain individual products, 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.

15. Given the iterative nature of software development, it should be further clarified that subsequent iterations of a software product are considered as newly placed on the market when those iterations qualify as a ‘substantial modification’ of a software product 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.

16. The guidance laid down in points 13, 14 and 15 applies exclusively insofar as the product is standalone software provided via digital means. This is not the case, for example, where software is provided via physical means (e.g. a USB flash drive), as the USB flash drive with the software on it is the product supplied for distribution, or when the software is combined with hardware, as discussed in 2.2 Combination of hardware and software forming a product.

2.2 Combination of hardware and software forming a product

17. 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 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.⁽⁶⁾

18. The CRA therefore can cover standalone software, such as (i) apps and computer programs; (ii) hardware with embedded software (e.g. Internet-of-Things devices); (iii) standalone hardware (e.g. integrated circuits, motherboards); and (iv) any combination of hardware and software supplied separately but intended to operate together.

19. Whether software forms part of a product 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 to perform its intended functions. Where a hardware device is designed to operate together with specific software in order to perform its functions, the hardware and that software together constitute the product placed on the market. Software that is necessary to operate, configure, control or meaningfully use a device is therefore part of the product, even if it is obtained through a separate channel (e.g. an app store, a download link or another digital channel after the hardware has been placed on the market).

2.3 Source code

20. It is also useful to clarify what constitutes a software product. The CRA defines software as ‘the part of an electronic information system which consists of computer code’ (Article 3(4)). Computer code can generally mean either (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.

21. Whether computer code is uncompiled, compiled or interpreted is not relevant to determining whether such software is within the scope of the CRA. The CRA applies to products when they are made available on the EU market in the course of a commercial activity. A natural or legal person that shares free and open source computer code on publicly accessible repositories is not considered to be placing that code on the EU market (for more guidance on the topic, see Section 3 Free and open-source software). Unfinished code shared during a product’s design and development phase (e.g. for testing or review) is also not considered to be placed on the market, 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.⁽⁷⁾

22. On the other hand, where a manufacturer provides its customers with computer code as part of its commercial activity, that code is considered to be placed on the market, regardless of whether it is machine code or source code.⁽⁸⁾

2.4 Data connection

23. 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 definition of ‘product with digital elements’ ultimately relies on the definition of electronic information system, i.e. ‘a system, including electrical or electronic equipment, capable of processing, storing or transmitting digital data’ (Article 3(7)). The scope of the CRA is therefore anchored not in the mere presence of electronics, but in a product’s capacity to exchange digital information.

24. 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 that merely use electrical signals from those that participate in digital communication and are therefore exposed to cybersecurity risks.

25. 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.

2.5 Complex systems

26. Products within the meaning 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, it constitutes a product for the purposes of the CRA.

27. 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 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.

28. 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 product’s characteristics and constraints, in accordance with Article 13(3) of the CRA. Those characteristics form part of the product’s intended purpose and operating context and are therefore relevant when assessing compliance with the essential cybersecurity requirements. In particular, recital 55 explicitly recognises that certain essential requirements may not be fully compatible with the nature of a product. For example, this may be the case where compliance would undermine mandatory interoperability requirements or the system’s proper functioning.

29. 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 cybersecurity 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 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 product’s security. 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 constrains can be lifted or reduced over time, manufacturers should update the product accordingly so that it can move towards state-of-the-art cybersecurity.

2.6 Products designed before the CRA entered into application

30. In some cases, a manufacturer will place on the market a product 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 the product 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 whether the product, on the basis of its intended purpose and reasonably foreseeable use, meets the essential cybersecurity requirements set out in Part I of Annex I.

31. Where the outcome of that risk assessment demonstrates that the product 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 where this is not necessary to address the identified risks.

32. Nevertheless, the manufacturer remains subject to the obligations laid down in the CRA. These include making sure, before the product 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 product design required modification as a result of the risk assessment. For products designed prior to the application of the CRA, 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, 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 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.

33. Accordingly, products 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 achieves an appropriate level of cybersecurity in light of its intended purpose and reasonably foreseeable use and complies with the cybersecurity essential requirements.

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

35. However, the application of such requirements needs to be interpreted in light of the cybersecurity risk assessment and the risk profile of the product. Particularly in the case of products designed before the CRA applied and subject to the conformity assessment procedures of Article 32(1), where the risk assessment demonstrates that the product 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. This would not be necessary as it would not be contributing to increasing the security of the product 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 product families, as further discussed in 7.4 Re-use of risk assessments and conformity documentation for product families.

36. 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).

3.1 Determining if free and open-source software is under one’s responsibility

44. The CRA places key responsibilities on economic operators that supply products in the EU market. It defines the manufacturer as the natural or legal person that supplies a product 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 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.

45. 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.

46. 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 responsibility; responsibility lies with those who publish and control the FOSS.

3.2 Determining if free and open-source software is placed on the EU market

47. Once it is established that 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.

3.3 Open-source software stewards

66. 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).

67. 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.

68. 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 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.

69. 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 3.2.1 Charging a price.

70. 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.

71. 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 deemed 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.⁽¹²⁾

3.4 Contributors and downstream uses

80. As already mentioned in 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).

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

82. Similarly, the mere fact that manufacturers integrate FOSS components into their own (monetised) products has no impact on the status of that FOSS component under the CRA. Whether the CRA applies to that FOSS component depends solely on whether the entity that publishes it places it on the market.

83. 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 with the person maintaining those components, in accordance with Article 13(6). For more guidance on this topic, see 9.2.1 Reporting upstream and sharing security fixes.

3.5 Illustrative scenarios

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

4.1 Physical repairs

88. 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’.

89. Operations of refurbishment, maintenance or repair which result in physical modifications of products 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 product’s compliance 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.

90. 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. It only does so if the performance change or the way the repaired product operates (i) affects the product’s compliance with the essential requirements or (ii) results in a change to the intended purpose that was not covered by the original risk assessment.

4.2 Spare parts

91. 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 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.

92. Accordingly, where a spare part is identical to a component already included in a product 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.

93. By contrast, where a spare part is not identical to the original component, that spare part constitutes a product in its own right and is therefore subject to the CRA. In such cases, compliance with the essential cybersecurity requirements must be assessed in light of the spare part’s intended purpose. Of particular relevance is the spare part’s function of ensuring compatibility or interoperability with an existing product, including where that product is a product 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 product’s security. As also discussed in 2.5 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.

94. As explained in 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.

4.3 Software updates as substantial modifications

95. Software development is iterative in nature, with software products 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 who make changes to their own products determine whether those changes amount to a substantial modification.

96. As stated above, Article 3(30) of the CRA establishes that a change qualifies as a substantial modification where it:

97. Recital 39 further indicates that a product 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 original risk assessment.

98. Where a product introduces new functionalities 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 original risk assessment. In such circumstances, the change would generally qualify as a substantial modification.

99. At the same time, however, it is possible that a manufacturer progressively introduces new functionalities already included in its original risk assessment. 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. Updates of this nature should therefore not be regarded as substantial modifications.

100. Conversely, even limited or seemingly minor new functionalities may introduce significant cybersecurity risks, if such risks were not included in the original risk assessment and may 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 effect on the product’s cybersecurity risk profile.

101. 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. A security update that does not modify the product’s intended purpose and does not introduce new cybersecurity risks should therefore not be considered a substantial modification. 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.

102. By contrast, a security update may qualify as a substantial modification where, notwithstanding its security objective, the update results in the product’s intended purpose being modified beyond what was originally foreseen or introduces cybersecurity risks not foreseen in the original risk assessment.

103. As stated in point 98 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:

104. 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 original risk assessment remain valid and effective. It is therefore likely that the update does not qualify as a substantial modification.

105. 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 product’s cybersecurity risks and determine whether the essential requirements continue to be met, including whether the update introduces new or increased risks not foreseen in the original risk assessment.

106. 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 87. 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 Annex I, Part II of 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).

4.4 Consequences of a substantial modification

107. Where a product modification qualifies as a substantial modification, the modified product is to be treated as a new product 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.

108. In such cases, the natural or legal person who carries out the substantial modification, or has the modification carried out, is to be regarded as the modified product’s manufacturer, irrespective of whether that person was involved in the original design or placing on the market of the product. Where the substantial modification is carried out by the original manufacturer, including in the context of iterative development of software products, that manufacturer remains the manufacturer for the purposes of the CRA. However, the substantially modified product is to be considered as newly placed on the market.

109. In accordance with Section 2.1 of the Blue Guide, ‘the technical documentation has to be updated in as much as the modification has an impact on the requirements of the applicable legislation. It is not necessary to repeat tests and produce new documentation in relation to aspects not impacted by the modification. It is up to the natural or legal person who carries out changes or has changes carried out to the product to demonstrate that not all elements of the technical documentation need to be updated. The natural or legal person who carries out changes or has changes carried out to the product shall be responsible for the conformity of the modified product and draw a declaration of conformity, even if they use existing tests and technical documentation’.

110. Therefore, the natural or legal person placing the substantially modified product on the market may re-use existing documentation and tests for aspects of the product that are not impacted by the substantial modification. Particularly where the manufacturer places substantially modified versions of the same product on the market, the conformity assessment procedure should focus on the substantially modified parts of the product with digital elements. Similarly, where a third-party conformity assessment is performed, the conformity assessment body should focus its assessment on the substantially modified parts. For unchanged parts of the product, it may re-use existing documentation and test results.

111. In accordance with Article 69(2) of the CRA, products that were placed on the market before 11 December 2027 are subject to the Regulation only if, from that date, they undergo a substantial modification.

112. For products that were placed on the market before 11 December 2027, manufacturers who did not apply the CRA at the time of initial placement on the market must be able to demonstrate upon request of a market surveillance authority that subsequent updates do not constitute a substantial modification. Carrying out a cybersecurity risk assessment that covers the elements of Article 13(2), including documented demonstration of compliance with the essential cybersecurity requirements should make it easier to establish that a software update does not affect the intended purpose, the cybersecurity risk profile or the compliance of the product, and therefore does not amount to a substantial modification within the meaning of Article 69(2).

113. Where the update constitutes a substantial modification, the manufacturer is required to comply with the CRA in its entirety before placing the substantially modified product on the market, as well as for the duration of the product’s support period.

6.1 Core functionality

124. A product’s core functionality refers to the product’s main features and technical capabilities, without which it would not be able to meet its intended purpose. It can be ascertained in light of the product’s specific context and conditions of use, as specified in the information the manufacturer supplies in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation.

125. A product’s functionality is rarely restricted exclusively to its core functionality, as products 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. However, the fact that a product performs functions other than or additional to those detailed in the technical descriptions of important or critical products does not in itself prevent the product from having one such core functionality.

126. A product 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 would not qualify as an important or critical product. As stated explicitly in Article 7(1) of the CRA for important products (and applying the same logic for critical products), the mere integration of an important or critical product does not in itself render the product an important or critical product.

127. Some products may be similar to an important or critical product category, or belong to the same general product, yet their core functionality substantially exceeds or substantially falls short of the core functionality of that category. Partial similarities in domain, purpose or deployment context are not sufficient grounds to conclude that two products share the same core functionality. In such circumstances, the assessment should focus on the product’s features and technical capabilities, as reflected in its intended purpose, rather than on vague product groupings or partially overlapping functionalities.

A security orchestration, automation and response (SOAR) software often has the ability to perform the functions of products with digital elements in the category of ‘security information and event management (SIEM) systems’, i.e. collect data from multiple sources, analyse and correlate that data and present it as actionable information for security-related purposes. However, the software’s core functionality substantially exceeds that of a SIEM, including services such as incident response. Therefore, SOAR software is generally not considered to have the core functionality of SIEM systems.

Certain log collection and visualisation tools have the ability to ingest log data and present basic dashboards showing system events. While these tools can support security monitoring activities, their core functionality falls short of that of SIEM systems, as they do not perform data correlation, nor do they provide actionable security insights. Therefore, such tools are generally not to be considered to have the core functionality of SIEM systems.

128. A product 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 their product’s intended purpose 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.

129. A manufacturer may not misrepresent its product’s core functionality in such a way as to escape the conformity assessment regime applicable to important or critical products, e.g. by overly emphasising or downplaying the role of certain functionalities, so that the product 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.

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

6.2 Conformity assessment for important and critical products

131. Once the manufacturer has determined its product’s core functionality, it needs to perform one of the applicable conformity assessment procedures. The manufacturer needs to ensure that the product as a whole undergoes the conformity assessment procedure, in order to demonstrate that it meets the essential cybersecurity requirements, considering, as appropriate, the security of the components or functionalities integrated into it.

132. A third-party conformity assessment procedure is mandatory for important products 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, whereby a notified body checks compliance with the essential cybersecurity requirements of the product as a whole.⁽¹⁸⁾ By contrast, important products 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 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’.

133. Therefore, for an important product 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 risks related to the product’s core functionality.

134. The product’s scope may be broader than the scope foreseen by the relevant harmonised standard, and such additional functions may present different or additional cybersecurity risks. When using a harmonised standard, the manufacturer is always required to carry out a risk assessment and to check whether that standard covers all risks associated with the product. Where the standard does not cover all risks, the manufacturer should ensure via other means that its product is in compliance with the essential cybersecurity requirements.

135. Therefore, if the manufacturer of a product of important class I has applied a relevant harmonised standard that covers the 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 are addressed. Hence, where there is a gap between the coverage of the harmonised standard and the scope of the product as a whole, the manufacturer still needs to document which additional measures it has put in place to treat those risks.

An antivirus software has the core functionality of software that searches for, removes, or quarantines malicious software, as described in Annex I, point 4 to Implementing Regulation (EU) 2025/2392. That product also includes additional features, namely a disk-cleaning function and an anti-tracking function protecting the user when navigating on the web. The manufacturer carries out a risk assessment covering the product in its entirety, including the antivirus’s core functionality, the disk-cleaning and the anti-tracking functions. It applies a harmonised standard covering the antivirus’s core functionality, and additional measures to deal with risks stemming from additional functions. The manufacturer is allowed to make use of the internal control procedure for its conformity assessment, covering the product as a whole, including the disk-cleaning and the anti-tracking functions.

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

6.3 Implications for presumption of conformity

137. Article 27(1) of the CRA establishes that products 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 cybersecurity requirements of the CRA covered by those standards or parts thereof.⁽¹⁹⁾ Article 27(5) extends the same presumption of conformity to products 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 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).⁽²⁰⁾

138. Therefore, where the manufacturer has applied a harmonised standard whose references have been published in the OJEU, and which addresses all the relevant cybersecurity risks associated with its product, it benefits from a presumption of conformity. This could be the case, for example, where the referenced harmonised standard covers the full scope of an important product of class I and there are no additional functionalities that present cybersecurity risks.

139. In the cases discussed in points 136 and 137, the manufacturer is allowed to use the internal control procedure because the harmonised standard covers the product’s core functionality. However, the products 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. The product may therefore not benefit from a presumption of conformity, which only covers the parts of the product whose risks are covered by the harmonised standard.

An antivirus software has the core functionality of software that searches for, removes, or quarantines malicious software, and that core functionality is covered by the harmonised standard. That product also includes additional functionalities, namely a disk cleaning function and an anti-tracking functionality protecting the user when navigating on the web, which are not covered by the harmonised standard. If the harmonised standard is applied, the manufacturer is allowed to make use of the internal control procedure for its conformity assessment. It will benefit from a presumption of conformity for the product’s core functionality, but not for the additional functionalities.

In the same scenario as the previous example, the harmonised standard has now been updated to also cover one of the additional functionalities, namely the disk-cleaning function, but not the other (i.e. the anti-tracking function). If the harmonised standard is applied, the manufacturer is allowed to make use of the internal control procedure for its conformity assessment. It will benefit from a presumption of conformity for the product’s core functionality and for the disk-cleaning function, but not for the anti-tracking function.

7.1 On the evaluation and treatment of cybersecurity risks

140. 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. Manufacturers also need to implement appropriate measures to address those risks, in accordance with the essential requirements of Annex I.

141. 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 is assessed against a regulatory threshold: the product placed on the market needs to ensure an appropriate level of cybersecurity based on the risks, taking into account its intended purpose and reasonably foreseeable use.

142. Accordingly, the manufacturer’s internal risk tolerance, commercial strategy or cost considerations are not relevant in determining whether the essential cybersecurity requirements are met. 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 to meet the essential requirements of Part I of Annex I, in light of the product’s intended purpose, reasonably foreseeable use and conditions of use, including, where relevant, the operational environment and the assets to be protected, taking into account the length of time the product is expected to be in use.

143. 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 may only be placed on the market where the residual risks, once appropriate measures have been taken, have been sufficiently addressed to meet the essential cybersecurity requirements, taking into account the product’s intended purpose and reasonably foreseeable use.

144. In accordance with Article 13(3), where cybersecurity risks are identified, manufacturers are required to address them through appropriate measures implemented 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 product’s intended purpose and reasonably foreseeable use more precisely, in order to ensure compliance with the essential cybersecurity requirements.

145. The CRA does not provide for the transfer of cybersecurity risk or responsibility to users or third parties. The obligation to place a secure product on the market and to demonstrate conformity with the essential cybersecurity requirements remains with the manufacturer.

146. Nonetheless, information and instructions provided to users may be used to support the product’s secure deployment and operation, including where the manufacturer has chosen to restrict the intended purpose of the product to trusted environments, and to inform users of residual risks. Such information cannot be used to compensate for shortcomings in product design or to justify leaving cybersecurity risks unaddressed where those risks are incompatible with the essential requirements.

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

7.2 On designing, developing and producing products in such a way that they ensure an appropriate level of cybersecurity based on the risks

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

149. This essential requirement is aimed at also addressing additional cybersecurity risks that may have been identified by the cybersecurity risk assessment and 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.

150. Accordingly, where all relevant cybersecurity risks related to a product 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 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.

7.3 Risk assessment and due diligence in relation to external dependencies and integrated components

151. 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 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 remains secure, including where it relies on remote data processing solutions, cloud-based services, networks, or third-party software or hardware components.

152. The cybersecurity risk assessment concerns the identification and management of relevant risks that may affect the product, including risks that originate outside the product itself, such as external networks, environmental factors, or other external aspects which might affect the product 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 itself. This will involve implementing the appropriate essential cybersecurity requirements set out in Part I of Annex I, including where necessary providing information and instructions to users on integration or deployment risks.

153. For example, a manufacturer may identify a risk that unauthorised persons may gain access to back-end systems while the product is in operation and attempt to send malicious commands to the product. In such cases, the CRA requires the manufacturer to address that risk 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 that a remote service may become unavailable due to power outages or failures of the infrastructure, the CRA may require product-level mitigations such as ensuring that the outage does not cause the product to enter into insecure states. In such cases, the CRA regulates how the product responds to those risks; it does not impose obligations on how the back-end infrastructure is organised, staffed or operated.

154. Due diligence relates to elements that form part of the product 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 product’s compliance with the essential cybersecurity requirements. This can only be achieved by determining what the product 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.

155. The manufacturer has to identify as part of its cybersecurity risk assessment what those requirements should be. For example, if the risk assessment shows that the product 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 functional tests on those components to ensure stated aims are met. While due diligence is a separate legal obligation, it supports and underpins the manufacturer’s ability to demonstrate compliance with the essential cybersecurity requirements for the product as a whole.

156. When assessing the risks to the product 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 to ensure that the essential requirements are implemented within the product itself. Components that are physically or logically inside the product but supplied by a third party must also be considered as part of the risk assessment. However, for compliance purposes these are treated as external inputs whose external properties must be verified upon integration through due diligence, as they cannot be re-designed or re-developed by the manufacturer.

157. The same logic applies during the development and integration of components. Where the manufacturer develops functionalities itself, it must directly implement the essential cybersecurity 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 as a whole to comply. In both cases, the objective remains the same: that the product, as placed on the market, achieves an adequate level of cybersecurity as required by the CRA, taking into account the risks identified in the cybersecurity risk assessment.

7.4 Re-use of risk assessments and conformity documentation for product families

158. Manufacturers may place on the market products that are similar, for example different variants, models or configurations of the same product family. Where such products 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 for the purposes of risk assessment and conformity assessment.

159. 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, as long as it clearly identifies the product variants to which it applies.

160. The decisive factor is whether the differences between the variants are relevant to cybersecurity. Variations that do not affect the product’s cybersecurity properties, such as differences in physical housing, 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 exposure to threats or the implementation of essential cybersecurity requirements, for example through different communication interfaces, different software stacks, different update mechanisms or different remote connectivity. In such cases, those differences must be reflected in the risk assessment and, where necessary, in the conformity assessment and technical documentation.

161. Manufacturers remain responsible for ensuring that the risk assessment and the related documentation accurately reflect the products 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 do not present differences with regards to their cybersecurity properties.

8.1 What is considered a remote data processing solution for a product with digital elements?

168. 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 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.

8.1.3 Has the software been designed and developed by the manufacturer, or under its responsibility?

179. The definition of ‘remote data processing’ of Article 3(2) of the CRA further specifies that the software of such data processing at a distance needs to be designed and developed by the manufacturer, or under its responsibility. Remote data processing entirely developed and designed by the manufacturer (in-house) would naturally qualify as RDPS. This would also be the case if manufacturers rely on an external service provider for the development and design of a solution (i.e. ‘under its responsibility’). The phrase ‘under the responsibility of the manufacturer’ refers to remote processing solutions that are tailor-made for the manufacturer. These are cases where the manufacturer is not merely licensing an existing product or service that a service provider offers to its customers or slightly modified versions thereof. ‘[U]nder the responsibility of the manufacturer’ entails that the software is built solely on behalf of the manufacturer, based on designs and specifications provided by it. In other words, these are situations where the technology developed by the service provider is owned, not licensed, by the manufacturer.

180. In understanding RDPS, the notion of ‘who operates the solution’ is not a decisive factor, as the CRA definition only refers to the design and development of the RDPS. This is consistent with the CRA approach whereby requirements and obligations are on manufacturers, and not on the operation of the product. If manufacturers design and develop solutions, which are then operated by a third party, they remain responsible for compliance with the CRA’s essential requirements for the product that they place on the market.

181. It is necessary to differentiate between the cases where design and development are done by manufacturers (or under their responsibility) and cases of reliance on third-party solutions not designed and developed by manufacturers (or under their responsibility). As an example, it is helpful to consider the most common cloud service models that provide different degrees of user control and that are also cited in recital 12 of the CRA, namely Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS).

182. In the case of a third-party IaaS solution, the manufacturer does not manage or control the underlying physical and virtual resources (such as the underlying hardware and the cloud service provider’s hypervisor), but is able to deploy and run arbitrary software using such resources, such as operating systems and applications. Such software is designed and developed by the manufacturer, or under its responsibility, and may therefore qualify as RDPS (if it fulfils the other elements of the definition).⁽²³⁾

183. In the case of a third-party PaaS solution, the manufacturer deploys its own (created or acquired) application using programming languages and execution environments provided by the cloud service provider and integrates the application into its product. The manufacturer has control over the application and possibly over configuration settings for the execution environment. The application is therefore designed and developed by the manufacturer, or under its responsibility, and may therefore qualify as RDPS (if it fulfils the other elements of the definition).

184. In the case of a third-party SaaS solution, the SaaS provider offers the manufacturer a fully developed application to be integrated into the manufacturer’s product. The manufacturer has limited ability to manage user-specific application configuration settings. The application is therefore not designed and developed by the manufacturer, or under its responsibility.

185. Nonetheless, where certain elements do not qualify as RDPS (e.g. the hypervisor in the case of a third-party IaaS infrastructure, the operating system in the case of a third-party PaaS solution, or the third-party SaaS application), such solutions should be considered similar to third-party components as they are integrated in the product, hence they might compromise its security. The manufacturer is required to identify and assess risks linked to the integration of those components and to address them by implementing the essential requirements on the product itself. Additionally, the manufacturer is expected to exercise a similar obligation to the obligation to perform due diligence referred to in Article 13(5) related to the security of these components.

186. Therefore, it can be summarised that:

a. For data processing to qualify as RDPS, the answer to the questions posed in 8.1.2 Would the absence of such data processing prevent the product from performing one of its functions? and 8.1.3 Has the software been designed and developed by the manufacturer, or under its responsibility? needs to be affirmative.

b. Manufacturers should treat the third-party solution as a component if the answer to the question in 8.1.2 Would the absence of such data processing prevent the product from performing one of itsfunctions? is affirmative but the answer to the question in 8.1.3 Has the software been designed and developed by the manufacturer, or under its responsibility?is negative. As part of the risk assessment, manufacturers should assess the risks stemming from the integration of such solution and mitigate them accordingly. Additionally, manufacturers should exercise due diligence.

c. If the answer to the question in 8.1.2 Would the absence of such data processing prevent the product from performing one of itsfunctions? is negative, manufacturers should assess the risks stemming from the existence of such data processing as part of their risk assessment.

8.2 Practical and technical implications of remote data processing solutions and reliance on third-party solutions

187. 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.

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

189. It appears appropriate to delineate the part of the system that would be within the scope of the conformity assessment. Segregation of systems and data may make it easier to identify relevant parts of the RDPS. CRA requirements should only apply to those parts of the system where data intended for the provision of product functions is stored or processed. For instance, when a banking application interacts with the financial entity’s environment, the intent of the CRA is not to cover the entire entity’s environment but only those parts of the system that directly interact with the product, i.e. where the data processing and storage necessary for the product to perform one of its functions takes place. More information on this use case may be found in 8.3.1 Banking application. In all cases, the underlying hardware infrastructure should be considered outside the scope of the product. However, relevant risks should be assessed as part of the risks assessment.

190. Second, the risk assessment performed by the manufacturer should consider: (i) risks related to RDPS; (ii) and risks related to reliance on third-party cloud solutions (similar to third party components), (iii) risks related to the product environment (e.g. underlying hardware). Manufacturers should implement security controls on the product itself to mitigate those risks.

191. Third, as part of the conformity assessment and/or the fulfilment of due diligence obligations related to third-party cloud services, the following-elements can be re-used in support of the manufacturer’s assessment:

192. Finally, in their interactions with third-party cloud service providers, manufacturers need to implement the most appropriate security measures based on their risk assessment. Those mitigation measures should include security controls implemented at product level 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 cloud services providers should not qualify as a substantial modification of the product, 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 could 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.

8.3 Use cases for remote data processing solutions

In order to provide additional practical guidance for manufacturers, this section introduces a series of fictional use cases, describing archetypal products that rely on remote data processing and illustrating whether such processing qualifies as remote data processing solutions within the meaning of the CRA.

8.3.1 Banking application

A financial entity places a banking application on the market. The app’s back-end systems - support, among others, authentication, authorisation, account management, and payments. The financial entity uses a hybrid strategy relying on in-house infrastructure as well as third-party cloud solutions to support the app’s functionalities. These include:

Self-hosted servers to support financial transactions:

• The customer initiates a transfer via the mobile app.
• The request is submitted to the banking application programming interface (API) layer, which has been developed by the financial entity and self-hosted; the API authenticates the customer’s identity by querying the account management system and submits a request to the ledger system.
• The account management system and ledger system, which are also self-hosted but are logically segregated from the banking API layer, are used to record the transaction.
• The ledger system returns the transaction status to the banking API layer, which ultimately presents the result to the customer.

Implications for RDPS:

• The banking API layer is necessary for the app to perform its functions (i.e. supporting financial transactions). It is designed and developed under the responsibility of the manufacturer. As the answer to both questions presented in earlier sections is affirmative, the banking API is to be considered a RDPS. It must therefore be included in the cybersecurity risk assessment and in the implementation of the essential cybersecurity requirements for the product as a whole.
• The account management system and the ledger system do not qualify as RDPS for the banking application. Although they are part of the financial entity’s environment, they do not interact directly with the app and do not support one of its functions. They therefore fall outside the definition of RDPS for the purposes of the CRA. However, those systems remain external dependencies that may give rise to significant cybersecurity risks for the product. For example, compromise of the ledger system could allow an attacker to influence transaction results that are subsequently displayed in the application. The manufacturer is therefore required to identify and assess those risks as part of the cybersecurity risk assessment and to mitigate them through product-level measures, such as strong authentication of backend interfaces, integrity protection of transaction data, secure communication channels and verification of responses received by the app.

Third-party SaaS for customer support:

• The financial entity integrates into its app a customer support chat solution developed and operated by a third party provider; the third party provider has written the chat server code, built the user interface and operates the infrastructure where the chat is deployed (i.e. SaaS model).
• When the customer initiates a request for support, the app connects the customer to the third-party service to establish a chat session and handle the messaging flow, without providing the third party with access to core banking systems.

Implications for RDPS:

• The support chat solution is necessary for the product to perform one of its functions, but is not designed and developed by the financial entity, or under its responsibility; it therefore is not a RDPS. However, it should be treated like a third-party component. The reliance on that third-party service may create cybersecurity risks for the banking application, for example if an attacker were to use the chat channel to impersonate the bank or to deliver malicious content to users. The financial entity must take those risks into account in its cybersecurity risk assessment and mitigate them through product-level measures, such as isolating the chat function from core banking features, controlling data flows and validating content. Due diligence on the SaaS should also be exercised.

Reliance on third-party PaaS for transaction notifications:

• The banking app provides real-time notifications when money moves in or out of an account.
• This function relies on a cloud service provider’s PaaS, which provides the execution environment and underlying physical and virtual infrastructure; the financial entity has itself developed and deploys the application code responsible for the notification logic and message generation, on top of the cloud service provider’s PaaS.

Implications for RDPS:

• The application code responsible for the notification is necessary for the app to perform its function (i.e. pushing transaction notifications). It is designed and developed under the responsibility of the manufacturer. It therefore is to be considered a RDPS.
• The functions provided by the third-party PaaS provider are not designed or developed by the manufacturer or under its responsibility; they are therefore not to be considered RDPS. Nonetheless, the financial entity should treat the PaaS like a component. The use of that PaaS may still give rise to cybersecurity risks, such as unauthorised access to the notification service or disruption of message delivery. Those risks must be identified in the cybersecurity risk assessment and mitigated through product-level measures, such as strong authentication of the service, integrity protection of messages and resilience against service outages. Due diligence on the PaaS provider should also be exercised.

9.1 On reporting obligations

193. 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 that it becomes aware of; and (ii) any severe incident having an impact on the security of the product that it becomes aware of. 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 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.

194. Manufacturers that 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.

195. 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. 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 is being actively exploited; or (ii) a severe incident has occurred and has led to the security of its product being compromised.

196. 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 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. 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.

197. Furthermore, the structure of the reporting obligations requires manufacturers to update their notifications progressively, as their internal investigations advances 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.

198. After becoming aware of an actively exploited vulnerability or a severe incident, manufacturers are 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.

199. 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 product’s nature, 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 used in sensitive or essential environments, where public disclosure of technical details could itself increase cybersecurity risks or facilitate further exploitation.

200. 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 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 product’s nature and the interests of the users concerned.

9.2 On vulnerability handling

9.3 Interplay with other legislation