Answer:

The classification of an Open Source component results in a corresponding classification of the end product only if it constitutes the product’s core functionality. According to Article 7(1) CRA, the core functionality of a product with digital elements determines whether the product with digital elements must be attributed to a class of important elements (accordingly, pursuant to Article 8(1) CRA, for critical product categories).

Article 7(1) CRA stipulates:

“Products with digital elements which have the core functionality of a product category set out in Annex III shall be considered to be important products with digital elements and shall be subject to the conformity assessment procedures referred to in Article 32(2) and (3). The integration of a product with digital elements which has the core functionality of a product category set out in Annex III shall not in itself render the product in which it is integrated subject to the conformity assessment procedures referred to in Article 32(2) and (3).”

The same applies to integration of an Open Source component. The sole determining factor is what constitutes the core functionality of the end product.

First and foremost, it is important to understand what the ‘core functionality’ of a product is exactly. To this end, Annex I of the Commission Implementing Regulation (EU) 2025/2392 provides the technical descriptions of Classes I and II of Annex III of the CRA.

Additionally, the recitals of Implementing Regulation 2025/2392 contain some examples for classification:

“For example, integrating an embedded browser as a component of a news app for use in smartphones does not in itself render the news app subject to the conformity assessment procedure applicable to products with digital elements that have the core functionality of ‘standalone and embedded browsers’.” (Recital 3, 2025/2392)

It should also be noted here that, in accordance with the CRA, the manufacturer must additionally ensure “that the product with digital elements as a whole meets the essential cybersecurity requirements.” (Recital 3, 2025/2392). In the cited example, the manufacturer of the news app must demonstrate that the app is CRA-compliant as a whole. Depending on the outcome of the risk assessment pursuant to Art. 13(2) CRA, the integrated browser may also need to be considered for this purpose, even though responsibility under the CRA for the browser generally lies with the browser manufacturer. Thus, there is a difference in the integration of proprietary and Open Source components: With proprietary components, there is a “chain of responsibility” such that while the manufacturer bears overall responsibility for the end product, they are only required to meet the requirements for their core functionality. Otherwise, responsibility for fulfilling CRA obligations falls on the suppliers of the proprietary components. Whereas, when integrating Open Source components, the manufacturer cannot simply rely on a declaration of conformity from the Open Source project but must ensure that these components do not compromise the cybersecurity of their products with digital elements (see also the Commission’s FAQ, chapter 4.4). For details on the specific aspects of integrating FOSS into a product, see OSADL FAQ “What obligations must be met when FOSS components are integrated into a product that falls within the scope of the CRA?”

Furthermore, Implementing Regulation 2025/2392 clarifies that even if a product with digital elements contains ancillary functionalities other than or in addition to those listed in Annex I, 2025/2392 it does not necessarily lack the core functionality of one of the product classes listed in Annexes III or IV CRA. It is therefore not possible to avoid classification as an important or critical product simply by adding a secondary functionality. Recital 4, 2025/2392, provides the following example:

“For example, products with digital elements that have the core functionality of ‘operating systems’ often include software that performs ancillary functions not included in the technical description of that product category, such as calculators or simple graphics editors. Products with digital elements often also incorporate components that have the functionality of another important or critical product with digital elements, such as an operating system integrating browser functionality, or a router integrating firewall functionality. This, however, does not in itself mean that such products with digital elements do not have the core functionality of ‘operating systems’ or ‘routers, modems intended for the connection to the internet, and switches’, respectively.“

A product with digital elements that performs the functions of a product category listed in Annexes III and IV of the CRA, “but whose core functionality itself is different from that of such product category is not to be considered to meet the technical description of that product category. ” (Recital 5, 2025/2392).

“For example, a security orchestration, automation and response (SOAR) software often has the ability to perform the functions of products with digital elements in the category of ‘security information and event management (SIEM) systems’, i.e. gather data, analyse it and present it as actionable information for security purposes. However, as its core functionality is not that of a SIEM, SOAR software are generally not to be considered to meet the technical description of ‘security information and event management (SIEM) systems’. Similarly, a smartphone typically integrates components that perform the functions of several product categories set out in Annexes III and IV to Regulation (EU) 2024/2847, such as an operating system or an integrated password manager. However, as a smartphone’s core functionality is not that of an operating system or of a password manager, it is generally not to be considered to meet the technical description of such product categories.” (ErwGr 5, 2025/2392)

In conclusion, the focus should solely be on the core functionality of the end product. The functionality of incorporated (Open Source) components is only relevant if they also constitute the core functionality of the end product.

Example scenario:

A manufacturer of machine control systems integrates a container runtime system into its products. The manufacturer uses this container runtime system to run containers that provide the product’s core functionality, namely machine control. Alternatively, users can install and run their own containers on the system to configure the device or add additional product functionality.

Assessment of the scenario and information on the alternative scenario:

According to Annex I, 2025/2392, the technical description of ‘container runtime systems’ is as follows:

“Container runtime systems are software products with digital elements that manage the execution and lifecycle of containers running on a single host operating system as isolated processes, allocating resources and allowing the management and orchestration of individual containers.”

In the given scenario, the core functionality of a container runtime system can be ruled out. The core functionality of the product in the example scenario is controlling machines, not providing a container runtime system. The assessment would be different if the control system’s intended purpose was managing containers.

In the alternative scenario, the fact that the recipients can install and run their own containers must be considered in the risk assessment pursuant to Art. 13(2) CRA. This results from Article 13(3) CRA:

“The cybersecurity risk assessment shall be documented and updated as appropriate during a support period to be determined in accordance with paragraph 8 of this Article. That cybersecurity risk assessment shall comprise at least an analysis of cybersecurity risks based on the intended purpose and reasonably foreseeable use, as well as the conditions of use, of the product with digital elements, such as the operational environment or the assets to be protected, taking into account the length of time the product is expected to be in use.”

CRA; Commission Implementing Regulation (EU) 2025/2392; Core functionality; Critical product with digital elements; Cybersecurity; End-user product; FOSS; FOSS integration; Important product with digital elements; Open Source software; Product category; Product with digital elements

Most recent content update of this FAQ: June 2026