CRA-Navigator

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

Example 3: a mobile application that a user downloads from an app store and installs on their smartphone is supplied to the user and executes on the user’s device and is therefore a product with digital elements. Where it is placed on the market in the course of a commercial activity, it may fall within the scope of the CRA.

Example 4: a desktop application built using web technologies but packaged for local installation is supplied to the user and executes on the user's device, and is therefore a product with digital elements. Where it is placed on the market in the course of a commercial activity, it may fall within the scope of the CRA.

Example 5: a web application accessed by the user exclusively through a web browser is not a product with digital elements. Unless it supports the functionality of a product with digital elements, it does not fall within the scope of the CRA. By contrast, an application supplied to the user as a locally installed client that executes on the user's device is a product with digital elements. Where it is placed on the market in the course of a commercial activity, it may fall within the scope of the CRA. If that client relies, in order to perform one or more of its functions, on data processing at a distance which meets the definition of remote data processing, that data processing at a distance is also part of the product with digital elements.

Example 6: a website that merely presents information to its visitors and does not support the functionality of a product with digital elements is not itself a product with digital elements. It therefore does not fall within the scope of the CRA.

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.

Example 8: A network printer is placed on the market as a hardware product with digital elements, while the software drivers required to send print jobs, configure the device and manage its operation are made available for download from the manufacturer’s website. Although the printer and the drivers are supplied through different channels, they together constitute a single product with digital elements, because the printer cannot fulfil its intended purpose without the drivers.

Example 9: A fitness wearable is placed on the market to measure a user’s heart rate and activity, while a smartphone application provided by the manufacturer is required to display the measurements, show history and allow configuration of the device. Although the application is downloaded separately through an app store, the wearable and the application together constitute a single product with digital elements, because they are designed and intended to operate together to deliver the functionality of the product with digital elements.

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

Example 10: A manufacturer places on the market a product with digital elements that communicates with external systems using a network protocol. As part of the application of the essential requirements, the manufacturer determines, on the basis of the cybersecurity risk assessment, that the use of a secure communication protocol is necessary to ensure the confidentiality and integrity of data exchanged by the product with digital elements. However, its intended purpose includes interoperability with existing systems that only support an older or less secure protocol. In such cases, the manufacturer may implement that protocol where this is necessary to achieve interoperability, provided that the associated cybersecurity risks are identified and mitigated through other means. Where it is technically feasible for the product with digital elements to support both the secure protocol and the less secure protocol, the manufacturer is expected to implement the secure protocol and to enable its use by default. The less secure protocol would be allowed only where required for interoperability.

Example 11: A manufacturer of an industrial automation system purchases some microcontrollers before the CRA enters into application. The manufacturer undertakes the cybersecurity risk assessment for its industrial automation system to be placed on the market after the CRA enters into application. On the basis of that cybersecurity risk assessment, the manufacturer does not identify specific cybersecurity risks associated with using one of those microcontrollers. The manufacturer integrates it into its industrial automation system and ensures that the product with digital elements as a whole (the industrial automation system) meets the essential requirements.

Fn. 10 It should be noted that the considerations laid down in this paragraph may be applicable, as appropriate, to all products with digital elements in scope of the CRA, and not just ‘complex systems’.

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’. In this light, the manufacturer must consider the product with digital elements as a whole, including its remote data processing solutions (RDPS). For instance, when demonstrating that the product with digital elements complies with the essential requirements laid out in Annex I, RDPS must be taken into account, starting with the risk assessment (Article 13(2)). The same is valid when considering lifecycle obligations, such as reporting of actively exploited vulnerabilities and severe incidents (Article 14).

The purpose of this guidance is to provide further support to manufacturers in determining whether their product with digital elements has RDPS as defined in the CRA and how to fulfil their compliance obligations in this regard. After an initial analysis of the definitions and recitals laid down in the CRA, this guidance will provide questions to guide manufacturers in clarifying if their product with digital elements includes RDPS (see Section 8.1 What is considered a remote data processing solution for a product with digital elements? ). Subsequently, it will elaborate on the technical implications of RDPS and how to assess compliance with the CRA (see Section 8.2 Practical and technical implications of remote data processing solutions and reliance on third-party solutions ).

In fact, Article 3(2) defines the concept of ‘remote data processing’ as ‘data processing at a distance for which the software is designed and developed by the manufacturer, or under the responsibility of the manufacturer, and the absence of which would prevent the product with digital elements from performing one of its functions’. RDPS is therefore defined as the software elements (‘the part of an electronic information system which consists of computer code’, as defined in Article 3(4)) of data processing at a distance. It is not meant to include, as part of the scope of the product with digital elements, the hardware that remote data processing may rely upon.

Recitals 11 and 12 give further explanations on how this concept should be interpreted. Recital 11 clarifies that the goal of covering remote data processing solution is that ‘products are adequately secured in their entirety by their manufacturers, irrespective of whether data is processed or stored locally on the user’s device or remotely by the manufacturer’. It also states that ‘requirements concerning the remote data processing solutions falling within the scope of this Regulation do therefore not entail technical, operational or organisational measures aiming to manage the risks posed to the security of a manufacturer’s network and information systems as a whole.’

Therefore, it results from recital 11 that the intent is not for the CRA requirements to cover the whole IT infrastructure of an organisation, but only software components that allow for the execution of the data processing solution. For example, internal systems relating to the manufacturer’s own human resources, payrolls, customer relationship management, continuous integration/continuous delivery (CI/CD) pipelines, the distribution of security updates to edge locations, should not be considered as RDPS. Likewise, systems linked to auditing and testing activities, such as penetration testing, threat hunting and red teaming are outside the scope of a product with digital elements as covered by the CRA. It is important to note that while applying effective and regular tests and reviews of the security of the product with digital elements is an essential requirement laid down in point (3) of Part II of Annex I to the CRA, this does not mean that such activities are to be considered RDPS for the product with digital elements.

Recital 12 focuses on cloud services and elaborates on the circumstances under which cloud services might be considered RDPS. The recital concludes by recalling that cloud computing services and cloud service models fall within the scope of Directive (EU) 2022/2555 (NIS 2) 28 , which establishes cybersecurity risk-management requirements for cloud computing service providers. Those requirements are further specified by Commission Implementing Regulation (EU) 2024/2690 29 .

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 notion of ‘at a distance’ referred to in Article 3(2) is relevant but not sufficient to determine whether a product with digital elements includes RDPS. Furthermore, given the variety of solutions that might fall under this concept, it is not possible to provide an exhaustive definition of ‘at a distance’. A case-by-case assessment by the manufacturer is needed.

Recital 11 of the CRA mentions data processed or stored ‘remotely by the manufacturer’ as opposed to data processed or stored ‘locally on the user’s device’. Remote data processing typically takes place outside the user environment of a product with digital elements or an organisation’s operational environment (for a professional user). This, however, does not prevent processing from also taking place close to the device (‘at the edge’). The transmission of data may be wired (e.g. ethernet cable) or wireless (e.g. Wi-Fi, Bluetooth). Cloud computing, including edge computing, is a typical example of data processing taking place ‘at a distance’. For instance, in the case of a cloud-based function accessed by the user from a mobile application, part of the data processing takes place on the cloud, outside of the user’s environment.

It is important to note that RDPS are not necessarily operated on third-party cloud infrastructure. Remote data processing running on local servers on the manufacturer’s premises can also constitute RDPS. In other words, a solution run on- premises and on a private cloud is just as likely to qualify as RDPS as a solution run on a public cloud and off-premises.

The two decisive and cumulative questions that determine whether data processing is covered by CRA as remote data processing solution are set out below, in Sections 8.1.2 and 8.2 . If both questions are answered in the affirmative, the remote data processing qualifies as RDPS.

Fn. 28 Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union, amending Regulation (EU) No 910/2014 and Directive (EU) 2018/1972, and repealing Directive (EU) 2016/1148 (NIS 2 Directive), OJ L 333, 27.12.2022, p. 80, ELI: http://data.europa.eu/eli/dir/2022/2555/2022-12-27 . 29 Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 laying down rules for the application of Directive (EU) 2022/2555 as regards technical and methodological requirements of cybersecurity risk-management measures and further specification of the cases in which an incident is considered to be significant with regard to DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online market places, of online search engines and of social networking services platforms, and trust service providers, OJ L, 2024/2690, 18.10.2024, ELI: http://data.europa.eu/eli/reg_impl/2024/2690/oj .

As laid down in the definition of ‘remote data processing’ included in Article 3(2), for data processing at a distance to qualify as an RDPS, its absence would need to prevent the product with digital elements from performing one of its functions. The notion of ‘functions’ included in this definition is not limited to the ‘core functionality’ or ‘intended purpose’ of the product with digital elements, as the CRA does not impose such a limitation. The functions within the scope of the CRA are both functions that directly fulfil the intended purpose of the product with digital elements as experienced by users and functions that support the product’s overall performance.

Examples of functions where data processing at a distance may happen and that would prevent a product with digital elements from performing one of its functions would include: (i) sending commands to a device; (ii) synchronising files; (iii) onboarding the user; (iv) configuration (personalisation of the product with digital elements); (v) automated distribution of updates, including feature update and security patching; (vi) identity and access management.

In some cases, the user can use a function both remotely and manually (e.g. switching a light bulb with an app or manually). Having this option does not exclude qualification as RDPS of the data processing associated with the remote performance of the function. Performing this function remotely is also considered part of the functions the product with digital elements offers.

By contrast, where the absence of a certain data processing does not prevent the product with digital elements from performing one of its functions, such processing is not considered as an RDPS within the meaning of the CRA. This includes, for example, remote analysis of telemetry data collected purely for statistical purposes or future product development.

Nevertheless, even when data processing does not support a function of a product with digital elements, manufacturers may need to consider if those remote components introduce risks to the product with digital elements as part of their cybersecurity risk assessment (e.g. in light of the product’s operational environment), and mitigate such risks accordingly (e.g. through product-level mitigations).

Websites are a specific case that deserves further clarification, as also explained in Section 2.1 Placing on the market . Websites are not within the scope of RDPS if they do not support a function of a product with digital elements, as explained in recital 11 of the CRA. It is not sufficient for a website to contain information about a product with digital elements to be considered within the scope of RDPS, even if the product redirects to such website. For example, redirecting users to an external webpage that provides information and instructions to users is not an RDPS. By contrast, a website may be within the scope of RDPS if it enables or supports a function of a product with digital elements. For example, an authentication portal that issues credentials or tokens required for the product with digital elements to operate would be considered RDPS (provided that the other criteria of the definition are also met).

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 with digital elements 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 by or on behalf of the manufacturer, based on designs and specifications provided by it.

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 with digital elements. 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 with digital elements that they place on the market.

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

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

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 with digital elements. 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).

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 with digital elements. 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.

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) but are integrated into the product with digital elements in a manner that affects its security, such solutions should be considered similar to third-party components. The manufacturer is required to identify and assess risks linked to the integration of those elements and to address them by implementing the essential requirements on the product with digital elements itself. This can, where relevant, be supported by the security functions made available by the cloud service provider through its shared responsibility model, where the manufacturer uses or configures those functions to address the identified risks. 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, in a manner that is proportionate to the risk that the remote solution poses to the security of the product with digital elements.

Therefore, it can be summarised that:

a. For data processing to qualify as RDPS, the answer to both questions posed in

Sections 8.1.2 Would the absence of such data processing prevent the product with digital elements 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. If the answer to the question in Section 8.1.2 Would the absence of such data processing prevent the product with digital elements from performing one of its functions? is negative, manufacturers should assess the risks stemming from the existence of such data processing as part of their risk assessment.

c. If the answer to the question in Section 8.1.2 Would the absence of such data processing prevent the product with digital elements from performing one of its functions? 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, manufacturers should treat the third-party solution as a component. 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.

Figure 9: Stylised flowchart to determine if a product with digital elements contains RDPS

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:

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

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

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

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.

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

A financial entity places a mobile 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 remote solutions to support the app’s functionalities. These include:

Self-hosted infrastructure developed by the financial entity:

• The customer opens the mobile banking application and is authenticated through the banking interface, a self-hosted solution developed by the financial entity that receives the app’s requests and returns the corresponding responses. The banking interface verifies the customer’s identity by querying the account management system and grants access to the application.
• The customer initiates a transfer via the app. The app transmits the instruction to the banking interface, which submits a corresponding request to the ledger system.
• The account-management system and ledger system, both self-hosted but logically segregated from the banking interface, record the transaction.
• The ledger system returns the transaction status to the banking interface, which presents the result to the customer.

Implications for RDPS:

• The banking interface is necessary for the app to perform its functions, namely authenticating the customer, submitting the customer's instructions, including payment and transfer instructions, and returning the resulting status. The banking interface is designed and developed under the responsibility of the manufacturer. As the answer to both questions presented in earlier sections is affirmative, the banking interface is to be considered an RDPS. It must therefore be included in the cybersecurity risk assessment and in the implementation of the essential requirements for the product with digital elements as a whole. The subsequent processing of an instruction once submitted, in particular the recording of the transaction in the account-management and ledger systems, settlement and clearing, is carried out by systems with which the app does not interact directly and does not, on that basis, constitute an RDPS.
• The account-management system and the ledger system do not qualify as RDPS for the banking application. The app does not interact directly with them (interacting instead with the banking interface, which in turn relies upon them). Although their availability may be necessary for a function to be completed, the CRA covers only those parts of the system that interact directly with the product with digital elements. 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 with digital elements. 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 back-end interfaces, integrity protection of transaction data, secure communication channels and verification of responses received by the app.

Figure 10: Stylised representation of a banking app relying on RDPS

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 with digital elements to perform one of its functions, but is not designed and developed by the financial entity, or under its responsibility; it therefore is not an 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.

A smart thermostat enables users to control the temperature of their homes via a mobile application. The mobile application and the smart thermostat rely on remote data processing to exchange data (e.g. request to increase the temperature) and store data (e.g. user preferences). These functions were developed and designed under the responsibility of the manufacturer but run on an underlying physical and virtual infrastructure provided by a third party (third-party IaaS).

As the smart thermostat would not be able to perform its smart functionalities without this remote data processing, its absence would prevent the product with digital elements from performing one or more of its functions. Additionally, the software was developed and designed under the responsibility of the smart thermostat manufacturer. Therefore, the remote data processing qualifies as RDPS as defined in the CRA.

For the purpose of CRA compliance, the manufacturer of the smart thermostat needs to document the RDPS as well as the reliance on the third-party IaaS in the technical documentation of the product with digital elements, including details of the contracted service. The manufacturer needs to consider those elements in the risk assessment, which includes the intended purpose and reasonably foreseeable use of the product with digital elements. The manufacturer implements the CRA’s essential requirements based on the risks on the RDPS. For the third-party IaaS, the manufacturer needs to ensure that the security measures provided by the third-party provider are appropriate and/or take relevant measures vis-à-vis the infrastructure. For the former, the manufacturer could, for example, ask for evidence that NIS 2 obligations have been met.

The manufacturer of an e-Reader software uses a third-party SaaS storage service to store electronic books purchased by customers and enable them to access their books. The absence of this storage service would prevent the product with digital elements from performing one of its functions, but the third-party SaaS storage service is not developed by or under the responsibility of the manufacturer; the SaaS provider makes it available to customers for any use case.

The SaaS storage service does not meet the definition of RDPS. However, the e-Reader manufacturer relies on that external service for the functioning of its product with digital elements and must therefore take the associated risks into account in its cybersecurity risk assessment. The e-Reader manufacturer should treat the SaaS like a component. The manufacturer must implement appropriate product-level security measures, such as secure authentication, encryption and integrity protection of communications with the storage service. Due diligence when selecting and integrating the SaaS provider will also support the manufacturer’s obligations, so that the product with digital elements as a whole can comply with the essential requirements.

An industrial robot has the task of picking up parts. The robot sends information collected via cameras to a remote service designed and developed by the manufacturer. This service runs on an underlying physical and virtual infrastructure provided by a third-party service provider (third- party IaaS). The cloud service calculates the position of a part based on the camera feeds and sends commands back to the robot to pick up the parts.

The absence of this data processing would prevent the industrial robot from picking up parts, hence from performing one of its functions. Furthermore, the software running on top of the infrastructure has been designed and developed by the manufacturer. The software designed and developed by the manufacturer meets the definition of RDPS.

The manufacturer of the industrial robot needs to document the RDPS as well as the reliance on the third-party IaaS in the technical documentation of the product with digital elements (including details of the contracted service). The manufacturer also needs to consider those elements in the risk assessment, which includes the intended purpose and reasonably foreseeable use of the product with digital elements. The manufacturer implements the CRA’s essential requirements on the product with digital elements, including its RDPS, on the basis of the risks. Due diligence when selecting the IaaS provider will also support the manufacturer’s obligations. For example, the manufacturer could ask for evidence that NIS 2 obligations have been met.

A smartphone relies on a 5G network to provide internet connection, phone calls and messages to its users (mobile connectivity). The cellular network is developed and designed by telecommunication operators. The network comprises small cells and cell towers, and other network equipment.

The product with digital elements should be able to connect to a network correctly; this is one of its functions. However, whether that network is in operation or not is not relevant to ascertain if the product with digital elements is working correctly. The network is only a communication channel and is not necessary for the product with digital elements to perform its function of ‘connecting to a network correctly’. Likewise, an ethernet cable, a router or Wi-Fi signal is not considered data processing whose absence would prevent the product with digital elements from performing one of its functions, but rather an enabler of communication/connectivity.

Consequently, the cellular network does not meet the definition of RDPS. The network should not be considered like a third-party component, as there is no software integrated into the product with digital elements, the product instead merely relying on this network. As such, it is not necessary for the manufacturer to exercise due diligence obligations towards the network provider.

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)). C omputer 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.

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 13 ) 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 14 .

Where a legal person publishing a FOSS is a not-for-profit organisation ‘set up in such a way that ensures that all earnings after costs are used to achieve not-for-profit objectives’ (recital 18 of the CRA), the FOSS it publishes is not considered to be placed on the market. Where that legal person meets the definition of ‘steward’, it is subject to the corresponding obligations (Article 24 of the CRA).

Example 24: A legal person publishes a free and open-source browser that is directly monetised via search engine partnerships, but all its earnings after costs are used for not-for-profit objectives. The browser is not considered to be placed on the market within the meaning of the CRA. The legal person publishing it is subject to the obligations applicable to stewards.

In some cases, a FOSS is published by a clearly identifiable natural or legal person, but that FOSS is ‘intended for integration by other manufacturers into their own products with digital elements’. In such cases, that FOSS is not considered to be placed on the EU market, unless it is also monetised by the person that publishes it (i.e. the original manufacturer), in line with previous sections of this guidance.

Where that FOSS is not placed on the market, the legal person publishing it would be subject to the obligations of stewards, if it provides support on a sustained basis, in line with the definition of ‘steward’.

Example 25: A legal person publishes a FOSS library for building user interfaces. It does not monetise the supply of that library, but integrates it into one of its products with digital elements (which is in turn placed on the market). The library is not considered placed on the market within the meaning of the CRA, but it is intended for integration into products with digital elements. The legal person that publishes it is its steward.

Example 26: A legal person places an operating system on the market, and also publishes FOSS libraries to serve as reference implementations for users of that operating system. The legal person does not monetise the FOSS libraries, which are intended for integration into other products with digital elements. The legal person that publishes them is a steward to those FOSS libraries.

Recital 19 explains that the provision of sustained support to the development of a product with digital elements may include (but is not limited to): (i) the hosting and managing of software development collaboration platforms; (ii) hosting source code or software; (iii) governing or managing products with digital elements qualifying as FOSS; and (iv) steering the development of such products with digital elements.

This may be the case, for example, for a legal entity that develops FOSS for integration into its own products with digital elements and then publishes it without placing it on the market. This is also discussed in Section 3.2.7 Integration by other manufacturers . In this case, the legal entity is not a manufacturer of the software, but may be a steward to it. Additionally, as also explained in previous sections, a legal entity that publishes a free (or community) version and a monetised version of the same FOSS, is deemed a steward to the free (or community) version, and a manufacturer to the monetised version.

Similarly, a legal entity that monetises a FOSS but is a not-for-profit entity whose earnings after costs are used to achieve not-for-profit objectives (and therefore its FOSS is not placed on the market within the meaning of the CRA, as discussed in Section 3.2.6 Not-for-profit entities ) is a steward to the FOSS it publishes .

Furthermore, certain foundations offer collaboration platforms with various forms of governance that enable manufacturers to contribute regularly to the development of FOSS and/or that are regularly financed by manufacturers. Such foundations are to be considered stewards in relation to specific FOSS which are intended for commercial activities and for which the foundation offers sustained support. However, as explained in Section 3.3 Open-source software stewards , such a foundation may not be subject to any obligations under the CRA for other specific FOSS that it hosts, in cases where it does not provide systematic support for a specific FOSS, it does not ensure its viability, and/or that specific software is not intended for commercial activities.

The type of ‘sustained support’ that foundations and similar organisations provide to specific FOSS projects can vary greatly. For example, certain legal entities only provide non-technical support, such as managing the branding of projects, laying down governance rules, organising community events or collecting donations. Other entities also provide the underlying IT infrastructure necessary to run the project, such as hosting source code repositories, providing version control systems, or generating signing keys. Others go further in the type of support they provide by actively contributing engineering resources to the project, for example by employing developers, coordinating development work, reviewing or merging code, managing releases, or handling vulnerability reports and security patches. While all legal entities that qualify as stewards under the CRA are required to comply with the obligations in Article 24(1) and (2), how far the obligations laid down in Article 14(1), (3) and (8) apply to those legal entities varies depending on the type of support they provide, in accordance with Article 24(3).

Where an entity ceases to provide systematic support on a sustained basis for a specific FOSS, it may no longer meet the definition of steward and may therefore no longer be subject to the corresponding obligations. In such cases, that entity is encouraged to communicate clearly the change in its status for that specific FOSS.

In certain situations, an entity that was a steward to a specific project may decide to monetise that project directly, thereby placing the product with digital elements on the market and triggering the manufacturer’s obligations under the CRA. In such circumstances, that entity qualifies as the manufacturer of the product with digital elements from the date on which it places it on the market (but not in respect of earlier versions for which it acted as a steward).

Fn. 13 This notion is also contained in the formulation ‘intended for commercial activities’ included in the definition of ‘open-source software steward’ set out in Article 3(14) of the CRA. 14 The legal person may also not be subject to any obligations under the CRA, in cases where: (i) a specific FOSS is not placed on the market within the meaning of the CRA; and (ii) the legal entity does not meet the definition of steward in relation to that specific FOSS.

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’) 6 , 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 7 .

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.

Example 1: On 1 January 2028, company A first supplies for distribution via its website version 1.0.0 of its software X. On the same day, customer 1 purchases a copy of version 1.0.0 of software X. On 15 January 2028, customer 2 purchases a copy of version 1.0.0 of software X. Both copies of version 1.0.0 of software X are placed on the market on 1 January 2028.

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 .

Example 2: On 1 January 2028, company A first supplies for distribution via its website version 1.0.0 of software X. On the same day, customer 1 purchases a copy of version 1.0.0 of software X. On 15 January 2028, company A issues an updated version 1.0.1 of software X that does not constitute a substantial modification. On 30 January 2028, customer 2 purchases a copy of version 1.0.1 of software X. Both copies of version 1.0.0 and 1.0.1 of software X are considered to be placed on the market on 1 January 2028.

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 .

Fn. 6 Commission notice - The ‘Blue Guide’ on the implementation of EU product rules 2022 (Text with EEA relevance) 2022/C 247/01, OJ C 247, 29.6.2022, pp. 1–152.

Fn. 7 In accordance with Article 13(11), manufacturers may maintain public software archives enhancing user access to historical versions. In such cases, users shall be informed clearly and in an easily accessible manner about risks associated with using unsupported software.

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

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

Example 7: Company A licences source code to company B for a customisable internal platform, and provides that source code in a text file. Even if that source code requires further adaptation and compilation by company B before being used, company A is placing that source code on the market and is therefore subject to the CRA. Company A is not responsible for the compliance with the CRA of company B’s subsequent adaptations and compilation of that code.

Fn. 8 It should also be recalled that Article 4(3) allows manufacturers to make available on the market unfinished software which does not comply with the Regulation, such as alpha versions, beta versions or release candidates, provided that the unfinished software is made available only for the time necessary to test it and gather feedback. 9 On the other hand, it should be noted that for the purposes of product liability law, computer code itself does not constitute a product and therefore manufacturers that place such code on the market cannot be held liable under Directive (EU) 2024/2853 (the Product Liability Directive). Recital 13 of that Directive states that ‘information is not, however, to be considered a product, and product liability rules should therefore not apply to the content of digital files, such as media files or e-books or the mere source code of software’. This does not preclude that manufacturers may be liable under national tort law .

Article 3(30) of the CRA defines a ‘substantial modification’ as a change to the product with digital elements following its placing on the market, which (i) affects the compliance of the product with digital elements with the essential requirements set out in Part I of Annex I; or (ii) results in a modification to the intended purpose for which the product with digital elements has been assessed.

The notion of substantial modification is relevant for ascertaining CRA obligations in a number of cases, including the following:

a. in accordance with Article 21, an importer or distributor that carries out a substantial modification of a product with digital elements already placed on the market is considered to be its manufacturer;

b. in accordance with Article 22, any natural or legal person that carries out a substantial modification of a product with digital elements and makes it available on the market is considered to be its manufacturer;

c. in accordance with Article 69(2), any natural or legal person that carries out a substantial modification after 11 December 2027 of a product with digital elements placed on the market before 11 December 2027 and places it on the market is considered to be its manufacturer;

d. for manufacturers of products with digital elements placed on the market after 11

December 2027, in order to determine whether a product with digital elements is required to undergo a new conformity assessment procedure due to changes made after that date, particularly in light of the iterative nature of software development.

Therefore, it is important to provide guidance to help economic operators understand when hardware or software modifications qualify as substantial modifications.

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.

Example 35: The manufacturer of a computer server performs a repair operation, switching out a defective RAM with a new, better performing one. The server’s compliance with the essential requirements is not affected. The server performs better, but its new performance remains within the server’s intended use as considered in the cybersecurity risk assessment. The computer server is not considered to be substantially modified.

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.

Example 40: A manufacturer places on the market a dashboard that collects data from machines and displays trends and alerts, without having the ability to control such machines. The manufacturer subsequently develops a new version of that dashboard, introducing functionalities that enable it to control the machines, including by adjusting operating parameters and restarting machines following fault conditions. As a result of these changes, the dashboard’s intended purpose has evolved beyond what was envisaged in the risk assessment, shifting from a situational awareness tool to a product with digital elements intended to exercise operational control over other devices. The dashboard has therefore been substantially modified.

Example 41: A manufacturer places on the market a consumer software application intended to organise and display personal data, such as emails, messages, or documents, and to support basic search and filtering functions. The manufacturer subsequently introduces an update that enables the application to automatically analyse user content in order to generate behavioural profiles and make automated decisions affecting the prioritisation, suppression, or recommendation of content without user intervention. As a result of this change, the software’s intended purpose shifts from a user-controlled information management tool to an automated decision-making system, which was not envisaged in the risk assessment. The application has therefore been substantially modified.

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.

Example 42: A messaging application is initially released with functionality limited to one-to-one messaging. The manufacturer’s risk assessment covers the later introduction of group messaging, including for example the increased complexity of message routing. In a subsequent update, the manufacturer adds a group chat functionality together with administrator controls and moderation tools that were already foreseen and assessed in the original design. The update implements functionalities that fall within the scope of the original intended purpose and risk assessment. The messaging application has therefore not been substantially modified.

Example 43: A production monitoring system is placed on the market with read-only dashboards enabled, while automated control features are present in the system architecture but remain disabled. The manufacturer’s risk assessment explicitly covers the future activation of automated control loops, including the cybersecurity risks associated with closed-loop control, as well as safeguards such as operator override mechanisms and fail-safe states. In a later update, the manufacturer enables the automated control features and activates the safeguards as originally assessed. The production monitoring system has therefore not been substantially modified.

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.

Example 44: A manufacturer introduces an update to a software application adding a ‘remember me’ or persistent login feature that stores authentication tokens locally to improve user convenience. Although the functionality is limited in scope, it introduces new risks related to token theft, unauthorised access, and session hijacking that were not considered in the risk assessment. The update therefore affects compliance with the essential requirements. The software application has been substantially modified.

Example 45: A manufacturer adds a new logging and diagnostics feature to an existing software product with digital elements, enabling detailed system logs to be exported for troubleshooting purposes. While the functionality appears minor, it results in the collection and storage of sensitive operational data in an unencrypted format, introducing risks of data exposure that were not previously assessed or mitigated. The change may therefore have a significant impact on the cybersecurity risk profile of the product with digital elements. The software product with digital elements has been substantially modified.

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.

Example 46: A manufacturer deploys a security update to address a vulnerability in the codebase of a product with digital elements by correcting an input validation error that could lead to a buffer overflow, or by fixing a logic flaw allowing authentication bypass through improper session token validation. The update modifies the internal implementation of the software without affecting that product’s intended purpose or introducing new exposure. Such an update is intended exclusively to reduce the cybersecurity risk. The security update should not be considered a substantial modification.

Example 47: A manufacturer introduces a security update that strengthens existing security configurations, such as tightening firewall rules, disabling unused network ports, changing default administrator password policies, or making multi-factor authentication mandatory where such functionality was already available or foreseen. Although the update may affect how users configure or access the product with digital elements, it does not alter its intended purpose and serves solely to enhance its security posture. The security update should not be considered a substantial modification.

Example 48: A manufacturer places on the market a software product with digital elements that secures communications using a configurable encryption framework supporting multiple cryptographic algorithms and key sizes, as described in the product’s technical documentation and risk assessment. The risk assessment covers all the cryptographic options provided in the product with digital elements and anticipates the future deprecation of certain algorithms. The risk assessment also includes mitigation measures, such as cryptographic agility, internal key management, and compatibility testing. In response to emerging cryptographic guidance, the manufacturer deploys a security update that disables a deprecated algorithm and activates a stronger, already supported alternative, without introducing new external dependencies or altering data flows. As the update implements a security measure that was foreseen and assessed as part of the original design, and it does not introduce new cybersecurity risks, the security update should not be considered a substantial modification.

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.

Example 49: A manufacturer places on the market a software product with digital elements intended to provide local file encryption for data stored on a user’s device, enabling users to encrypt and decrypt files on demand. Following the discovery of a vulnerability in the encryption workflow, the manufacturer deploys a security update that removes local encryption functionality and instead requires all files to be uploaded to, stored in, and processed by a remote encryption service operated by the manufacturer. As a result of this change, the product with digital elements no longer performs local encryption as originally intended, instead functioning as a remote encryption and data processing service. Although the update is introduced for security reasons, it fundamentally alters that product’s intended purpose in a manner not foreseen in the risk assessment and therefore qualifies as a substantial modification.

Example 50: A manufacturer places on the market a software product with digital elements that relies on an established encryption protocol and an internally managed key lifecycle to secure communications between components of the product with digital elements. In response to newly identified cryptographic weaknesses, the manufacturer introduces a security update that replaces the existing encryption mechanism with a different protocol requiring the use of an external key management service operated by a third party. As a result of this change, the dependencies and data flows of the product with digital elements are materially altered, introducing new external interfaces and reliance on third-party services not considered in the risk assessment. Although the update is security-driven, it introduces new cybersecurity risks, and therefore qualifies as a substantial modification.

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 .

In accordance with Articles 21 and 22, where a substantial modification of a product with digital elements already placed on the market is carried out by a natural or legal person other than the manufacturer of the product with digital elements, the person who carries out the substantial modification and makes the modified product with digital elements available on the market is to be regarded as the manufacturer of the modified product with digital elements, irrespective of whether that person was involved in the original design or placing on the market of that product.

Article 22 further clarifies that the person carrying out the modification is subject to the obligations laid down in Articles 13 and 14 only in respect of the part of the product with digital elements affected by the substantial modification, where that modification does not have an impact on the cybersecurity of the product with digital elements as a whole.

Where a substantial modification affects compliance with the essential requirements but does not negatively affect the cybersecurity of the product with digital elements as a whole, the person carrying out the modification is subject to Articles 13 (including the obligation to ensure compliance with the essential requirements and to carry out a conformity assessment procedure) and 14 (reporting obligations) only in relation to the part of the product with digital elements that has been substantially modified 16 . Furthermore, the original manufacturer’s obligations under the CRA continue to apply to the original product with digital elements placed on the market, ensuring continuity in vulnerability handling and compliance for the unchanged parts.

A case of substantial modification should not be confused with cases of integration, in which a person assembles components (including, where appropriate, by modifying them) into a new product with digital elements that they themselves place on the market. In such cases, the integrator is not modifying a product with digital elements already placed on the market by another manufacturer; rather, it is placing a new product with digital elements of its own on the market. The integrator is the manufacturer of that new product with digital elements for the purposes of the CRA and is required to comply with the Regulation in its entirety in respect of the product with digital elements as a whole. Where the manufacturer integrates components that are subject to the CRA, it may rely on the compliance activities of the components’ manufacturers to facilitate its own compliance with the CRA.

Example 51: A company purchases off-the-shelf microcontroller modules and connectivity components from third-party suppliers, develops proprietary firmware and a sensor package, and assembles them into a connected agricultural monitoring product with digital elements that it places on the market under its own name. Although the company has modified the underlying microcontroller modules and combined them with other components, it is not substantially modifying a product with digital elements already placed on the market; rather, it is placing a new product with digital elements on the market. The company is the manufacturer of the agricultural monitor for the purposes of the CRA and is required to comply with the Regulation in respect of the agricultural monitor as a whole.

Where a substantial modification carried out by a person other than the original manufacturer negatively affects the cybersecurity of the product with digital elements as a whole, for example because the modification is no longer targeted or limited to a specific component or subsystem, the modified product with digital elements made available on the market should be treated as a new product with digital elements subject to the CRA in its entirety. In such cases, that product’s overall cybersecurity risk profile has changed, and the modification cannot be assessed without considering the product with digital elements as a whole. The person carrying out the modification is subject to the obligations of a manufacturer laid down in Articles 13 and 14 in respect of the modified product with digital elements as a whole.

Fn. 16 In line with Section 2.1 of the Blue Guide, ‘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’.

Where the substantial modification is carried out by the original manufacturer, including in the context of iterative development of software products with digital elements, that manufacturer remains the manufacturer for the purposes of the CRA. However, the substantially modified product with digital elements is to be considered as newly placed on the market.

In accordance with Section 2.1 of the Blue Guide, the original manufacturer placing the substantially modified product with digital elements on the market may reuse existing documentation and tests for aspects of the product with digital elements that are not impacted by the substantial modification. Particularly where the manufacturer places substantially modified versions of the same product with digital elements 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 with digital elements, it may reuse existing documentation and test results.

It is therefore useful to (i) clarify what FOSS is; (ii) when it is deemed to fall under the responsibility of a natural or legal person; and (iii) to provide examples to help stakeholders understand when the distribution of FOSS constitutes a placement on the market. Where FOSS is not placed on the market, it falls outside the scope of the CRA, unless the entity publishing it is a legal person that meets the definition of ‘open- source software steward’ (henceforth, ‘steward’) under Article 3(14). In that case, it is subject only to the obligations laid down in Article 24.

Article 3(48) defines FOSS as ‘software the source code of which is openly shared and which is made available under a free and open-source licence which provides for all rights to make it freely accessible, usable, modifiable and redistributable’. While this guidance does not identify specific free and open-source licences that are compatible with the definition laid down in Article 3(48), it follows from the wording of that provision that only software that cumulatively fulfils two conditions qualifies as FOSS for the purposes of the CRA: (i) the software must be made available under a free and open-source licence granting the full set of rights referred to in Article 3(48); and (ii) its source code must be openly shared.

The requirement that the licence provide for the software to be ‘freely accessible, usable, modifiable and redistributable’ reflects the traditional understanding of FOSS, namely that users must be able to access the source code, use it without undue restriction, modify it and redistribute original or modified versions. Access to the source code is therefore a necessary precondition for the exercise of the other rights: without access to the source code, it is not practically possible to modify or meaningfully reuse the software.

However, Article 3(48) goes beyond referring only to the licence terms, as it expressly requires that the source code ‘is openly shared’. The notion of ‘openly shared’ indicates that the source code must be made publicly available (either ‘upstream’ or ‘downstream’), and not merely provided on a restricted or conditional basis. Accordingly, software distributed under a free and open-source licence but whose source code is only shared (or allowed to be shared) with paying customers or a limited group of users is not to be considered FOSS within the meaning of Article 3(48). For the purposes of the CRA, only software whose source code is publicly available and licensed under a free and open-source licence granting the full set of rights referred to in Article 3(48) should therefore be considered to qualify as FOSS.

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 12 , 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.

Example 13: An individual developer or an employee of a company submits a ‘pull’ or ‘merge’ request containing a security patch or a new feature to a FOSS project. The project’s maintainers review, accept and merge the code into the main repository, subsequently including it in a new release. In this scenario, the person who submitted the pull request is a ‘contributor’ and is not subject to the CRA. Although that person contributed source code, they do not exercise primary control over the development, releases or distribution decisions.

Fn. 12 This is a necessary but not sufficient condition for a legal person to qualify as an open-source software steward, as the definition set out in Article 3(14) lays down additional conditions for a legal person to qualify as steward.

As recalled in Section 2.1 Placing on the market , the CRA applies to products with digital elements that are made available on the EU market in the course of a commercial activity for the first time (i.e. ‘placed on the market’), as well as to any subsequent instance that constitutes making that same product with digital elements available on the market. The Blue Guide (Section 2.2) clarifies that ‘commercial activity’ is to be understood as providing goods, in return for payment or free of charge, in a business-related context and can only be appreciated on a case- by-case basis, taking into account the regularity of the supplies, the characteristics of the product, the intentions of the supplier, etc.

Supply in the course of a commercial activity is characterised by a range of circumstances, amply documented in the Blue Guide and recalled in recital 15 of the CRA. These can include directly charging a price, as well as ‘charging a price for technical support services where this does not serve only the recuperation of actual costs, by an intention to monetise, for instance by providing a software platform through which the manufacturer monetises other services, by requiring as a condition for use the processing of personal data for reasons other than exclusively for improving the security, compatibility or interoperability of the software, or by accepting donations exceeding the costs associated with the design, development and provision of a product with digital elements’ (recital 15) 11 .

The CRA, however, recognises the specificities in the different ways of developing and publishing ‘free and open-source software’ (FOSS) and offers some guidance to help identify whether a FOSS is a product with digital elements placed on the market (i.e. in the course of a commercial activity) within the meaning of the CRA. As explained in recital 18, ‘the mere circumstances under which the product with digital elements has been developed, or how the development has been financed, should […] not be taken into account when determining the commercial or non-commercial nature of that activity’. More specifically, ‘to ensure that there is a clear distinction between the development and supply phases, the provision of products with digital elements qualifying as free and open-source software that are not monetised by their manufacturers should not be considered to be a commercial activity’.

Fn. 11 It should also be recalled that, while often products with digital elements are monetised (also) via the processing of personal data, protection of personal data is a fundamental right and therefore personal data cannot be considered as a commodity, as indicated in recital 24 of Directive 2019/770 of the European Parliament and of the Council of 20 May 2019 on certain aspects concerning contracts for the supply of digital content and digital services, OJ L 136, 22.5.2019, pp. 1–27, ELI: http://data.europa.eu/eli/dir/2019/770/oj .

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.

Where the natural or legal person that supplies a FOSS charges a price for the software itself (e.g. by charging a price for the pre-compiled binaries), that person is placing a product with digital elements on the market. The person that places a FOSS on the market is therefore a manufacturer under the CRA.

Often, manufacturers of FOSS supply versions for free of that software (often called ‘community’ versions), whose codebase is (almost) identical to the paid version. Those products with digital elements, however, are different products: the paid version is monetised in some way (e.g. either by charging a price or via other means as discussed in this section) and therefore considered to be placed on the market, triggering the manufacturer’s obligations. The version provided for free (or community version) is not monetised and therefore is not considered to be placed on the market for the purposes of the CRA. This is also the case where the paid version is an ‘enhanced’ commercial version, which extends the codebase of the version provided for free, or incorporates that version into a broader product with digital elements (e.g. as in the case of the ‘open-core’ model).

If the person supplying the community version is a legal person, that legal person is also subject to the obligations on stewards for the version it supplies for free (the community version). If the entity is a natural person, the version provided for free (the community version) is not within the scope of the CRA.

A natural or legal person publishing a FOSS may also be placing it on the market (i.e. supplying it in the course of a commercial activity) where it provides the software through which it monetises other products with digital elements or services, or where it requires as a condition for use the processing of personal data for reasons other than exclusively for improving the security, compatibility or interoperability of the software.

Example 14: A natural or legal person publishes a free and open-source marketplace application. The application is available free of charge and enables users to purchase goods or services through it. The app allows the person that published it to monetise other products with digital elements and services offered through it (e.g. through advertisements, commission fees or subscription fees). Therefore, the application is considered placed on the market in the course of a commercial activity.

Example 15: A natural or legal person publishes a free and open-source VPN. The application is available free of charge, but it enables users to pay to access additional servers or dedicated IP addresses. That application allows that person to monetise other services offered through it, therefore it is considered placed on the market in the course of a commercial activity.

Example 16: A natural or legal person publishes a free and open-source fitness tracking application. The application is available free of charge, but its use is conditional upon the processing of users’ personal data for purposes such as targeted advertising or analytics unrelated to the security, compatibility or interoperability of the software. By requiring such data processing as a condition for use, the application is therefore considered placed on the market in the course of a commercial activity.

The mere fact that a natural or legal person publishing a FOSS also offers paid support services related to it does not, as such, mean that the product with digital elements is supplied in the course of a commercial activity. Support services may include activities such as consultancy, training or professional services related to the use, documentation, configuration and deployment of the software by a customer.

The decisive factor is whether access to the FOSS itself (i.e. the provision of the product with digital elements), including its maintenance, is conditioned on remuneration, rather than the mere offering of professional services around a freely available product with digital elements, as indicated in recital 18 of the CRA (‘the provision of products with digital elements qualifying as free and open-source software that are not monetised by their manufacturers should not be considered to be a commercial activity’). Where the FOSS can be downloaded and installed freely, and users can optionally choose to purchase professional services separately, that FOSS is not considered to be placed on the market.

By contrast, in some cases access to a specific version of the product with digital elements including certain benefits such as technical assistance or performance optimisation, is conditioned on remuneration. In such cases, that provision constitutes a monetised provision of a product with digital elements supplied in the course of a commercial activity and is therefore considered placed on the market. This includes cases where a paid edition or enterprise version is made available under a commercial agreement, irrespective of whether functionally equivalent software is also available free of charge under a free and open-source licence.

Example 17: A natural or legal person publishes a free and open-source operating system, offering a paid version of that operating system which includes support services, such as technical assistance or performance optimisation. The paid version of the operating system is considered placed on the market in the course of a commercial activity.

Example 18: A natural or legal person publishes a free and open-source command line tool. The tool is freely accessible and anyone can download and install it. That natural or legal person separately offers professional services, such as optional consultancy services to train users and support them in installing and using the tool. That FOSS is not considered placed on the market within the meaning of the CRA.

Particularly in the case of natural persons publishing FOSS, offering technical assistance directly bundled with access to the product with digital elements would still not qualify as a commercial activity if, as indicated by recital 15 of the CRA, the price charged serves only the recuperation of actual costs. Such actual costs include a variety of costs related to that software’s design, development and maintenance, including the person’s reasonable living expenses. Therefore, a natural person publishing a FOSS and offering technical assistance to cover their costs and obtain fair remuneration is not to be considered, on that basis alone, as placing that software on the EU market.

A natural or legal person offering technical assistance related to a FOSS not under its responsibility is not considered to be placing that software on the market, unless that person substantially modifies the FOSS, in accordance with Article 22, as part of their delivery of such assistance.

Example 19: A service provider does not publish a FOSS, but helps a customer install it on the customer’s on-premises server. It does so without performing a substantial modification of that FOSS. The service provider is therefore not considered to be placing the FOSS on the market.

Natural or legal persons publishing FOSS projects routinely include ways for users of that software to voluntarily donate money to thank the project’s publisher(s) and also to ensure that the project remains actively maintained.

As indicated in recital 15 of the CRA ‘accepting donations without the intention of making a profit should not be considered to be a commercial activity’. The mere fact of including a link to a donation platform or similar tools to collect donations should not be viewed as an intention to make a profit, even where the amount collected via donations exceeds the mere costs associated with the design, development and provision of a product with digital elements. This includes reasonable compensation for the contributors hired by a legal person, and/or a natural person’s reasonable living expenses. Donations, by their very nature, fluctuate over time, and therefore a degree of flexibility is to be exercised when assessing whether a FOSS monetised exclusively through donations is considered to be placed on the market. A FOSS supported only through donations is therefore unlikely to be considered to be placed on the market within the meaning of the CRA.

Example 20: A natural or legal person publishes a FOSS tool in a public online repository, allowing anyone to download, use, modify and redistribute it under a free and open-source licence. The publisher invites users to make voluntary donations via a donation platform to support the project’s continued development and maintenance. Access to the software, its source code and its updates is not conditional on making a donation. That FOSS is not considered to be supplied in the course of a commercial activity and is not considered to be placed on the market within the meaning of the CRA.

Nonetheless, there are instances where a FOSS supported through donations may be considered to be placed on the market. This is the case where, based on an overall assessment of the circumstances, the donations are de facto equivalent to charging a price to access the product with digital elements or certain of its functionalities. This may be the case, in particular, where access to the FOSS, to essential functionalities or to updates is conditioned in practice on making a donation, or where donations are associated with contractual benefits or exclusive advantages that go beyond community perks.

Example 21: A natural or legal person publishes a software product with digital elements under a free and open-source licence, but provides downloadable releases and security updates only to users who make a donation. Users who do not make a donation do not have access to the software’s current version. In this case, the donations are de facto a condition for access to the product with digital elements and therefore amount to charging a price. That FOSS is therefore considered to be placed on the market within the meaning of the CRA.

Example 22: A natural or legal person makes the source code of a FOSS publicly available, but provides pre-compiled binaries, regular updates and guaranteed security fixes only to donors. In this case, the donations are linked to access to essential aspects of the product with digital elements and constitute remuneration for that product’s supply. That FOSS is therefore considered to be placed on the market in the course of a commercial activity.

The mere fact that a third party has paid for, sponsored or otherwise financed the development of a FOSS does not in itself determine whether that FOSS is placed on the market. It is common practice in the FOSS ecosystem for individual developers, foundations or communities to receive funding from companies, public bodies or other sponsors in order to work on specific features, fix bugs or maintain critical components. This funding may take many forms, including grants, bug bounties, sponsorships, service contracts or paid development work.

As already recalled, recital 18 of the CRA, clarifies that the mere circumstances under which the product with digital elements has been developed, or how the development has been financed, should not be taken into account when determining the commercial nature of that activity.

Therefore, where the FOSS is openly shared and made freely available for all to access, use, modify and redistribute, the fact that a commercial entity may have paid for that project should not contribute to determining whether the software is placed on the market. In fact, if that FOSS is not otherwise monetised, it is not to be considered as placed on the market. Where the company that funded the FOSS’s development (as well as any other company) integrates it into its product with digital elements, that company is to exercise due diligence in accordance with Article 13(5) of the CRA.

Example 23: An individual developer publishes a FOSS project and actively maintains it. Manufacturer A requests that the individual developer add a specific feature for that FOSS, and funds that development. The developer adds the feature to the FOSS codebase, openly sharing it and making it freely available for all to access, use, modify and redistribute. The individual developer is not considered to have placed that FOSS on the market. If the manufacturer integrates the FOSS into its product with digital elements, it needs to exercise due diligence in accordance with Article 13(5).

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.

Example 27: Individual developer A has developed a FOSS. Developer A publishes that FOSS under its own name or trademark, but does not charge a price for its use. The software is openly shared and freely available for all to access, use, modify and redistribute. Developer A also includes a link to a platform to collect voluntary donations. Companies B, C and D integrate that FOSS into their own products with digital elements. To support ongoing maintenance, companies B, C and D make voluntary donations to developer A. These donations enable developer A to keep the project actively maintained. That FOSS is not placed on the market within the meaning of the CRA. Developer A has no obligations under the CRA. Companies B, C, and D are to exercise due diligence in accordance with Article 13(5) when integrating that FOSS into their own products with digital elements.

Example 28: Not-for-profit foundation F publishes a FOSS component for integration into other commercial products with digital elements. Foundation F commits to providing sustained support to that FOSS, to ensure its viability and uptake. Companies A, B and C integrate that FOSS into their own products with digital elements. Companies A and B voluntarily contribute some of their developers’ time to development and maintenance of FOSS projects within foundation F, including for that FOSS . As foundation F is a not-for-profit entity set up in such a way that its earnings after costs are used to achieve not-for-profit objectives, the FOSS is not considered to be placed on the market within the meaning of the CRA. Foundation F is the FOSS steward and is subject to the corresponding obligations laid down in Article 24. Companies A, B and C are to exercise due diligence in accordance with Article 13(5) when integrating that FOSS into their own products with digital elements.

Example 29: Company A has developed a FOSS component for integration into its own products with digital elements. It also publishes that FOSS separately under its own name or trademark and actively maintains it. However, it does not charge for its use or monetise in other ways. Companies B, C and D integrate that FOSS into their own products with digital elements, and voluntarily contribute some of their developers’ time to its maintenance. That FOSS is not considered to be placed on the market within the meaning of the CRA. Company A is not its manufacturer, but is its steward. Companies B, C, and D are to exercise due diligence in accordance with Article 13(5) when integrating the FOSS into their own products with digital elements.

Example 30: Company A publishes a FOSS under its own name or trademark and offers it as a paid version, which includes certain benefits such as technical assistance or performance optimisation. Developers from companies B, C and D contribute to the FOSS’s maintenance, but it remains under the control of company A. Company A is considered a manufacturer to that FOSS 15 . Companies B, C and D are not subject to obligations under the CRA for that specific FOSS. If they integrate that FOSS into their own products with digital elements, they are required to exercise due diligence in accordance with Article 13(5).

Example 31: Company A publishes a FOSS under its own name or trademark and provides ongoing maintenance to ensure its long-term viability, to enable that software to be integrated into other companies’ products with digital elements. Company A does not charge for its use, process personal data it collects through the product with digital elements, or sell support services associated with publishing the FOSS. Company B contributes code and developers’ time to the FOSS’s maintenance, but does not distribute it commercially. Company B offers technical support services independently from the FOSS’s distribution. Company A is deemed to be the steward for that FOSS, whereas company B has no obligations under the CRA for that FOSS.

Example 32: A FOSS component is published by a not-for-profit entity set up in such a way that ensures that all earnings after costs are used to achieve not-for-profit objectives. The entity provides sustained support to ensure the project’s long-term viability. Maintenance is financed through public funding, such as research grants. Additional developments, including new features, are funded through donations and specific projects, carried out in partnership with manufacturers that integrate that FOSS into their products with digital elements. Such features are incorporated into the FOSS’s codebase. The not-for-profit entity that publishes the FOSS is deemed the steward for that FOSS component. A manufacturer that has contributed to the development of certain features does not become the manufacturer of that FOSS component. Where the manufacturer integrates that FOSS component into its own product with digital elements, it needs to exercise due diligence in accordance with Article 13(5).

Example 33: A not-for-profit entity set up in such a way that ensures that all earnings after costs are used to achieve not-for-profit objectives publishes a FOSS software development kit (SDK) and ensures its ongoing maintenance. The SDK is openly shared and is freely available for all to access, use, modify and redistribute. Funding is provided through membership fees paid to the not-for-profit entity, and developers employed by member organisations contribute code and other resources to the SDK’s development. Manufacturers use the SDK as a component to build other products with digital elements. The not-for-profit entity that publishes that SDK is the steward for it. The foundation’s members are not responsible for the SDK’s compliance with the CRA. Where manufacturers use the SDK to build their own product with digital elements, they need to exercise due diligence in accordance with Article 13(5).

Example 34: An individual developer publishes a FOSS library on a public package repository for a given programming language and actively maintains it. In the package documentation, the developer adds a link to collect donations. A manufacturer downloads that library from the repository for free and integrates it into its own product with digital elements. The individual developer and the package repository do not have any obligations under the CRA. The manufacturer that integrates the library needs to exercise due diligence in accordance with Article 13(5).

Figure 1: Stylised flowchart for CRA coverage of free and open-source software

Fn. 15 Unless company A is a not-for-profit entity set up in such a way that ensures that all earnings after costs are used to achieve not-for-profit objectives, in which case it would be the steward to that FOSS.