Due Diligence for FOSS Components
A manufacturer integrates hundreds of free and open-source software (FOSS) components like U-Boot, Linux kernel, Wayland, Qt, LVGL, GStreamer, Sqlite, VNC, RAUC, OpenSSH and Mosquitto into its machines or devices. Recital 34 requires the manufacturer to exercise due diligence for FOSS components when doing the CRA compliance for its product. How much due diligence is needed?
The manufacturer must verify the CRA compliance of the FOSS components to the extent that they influence the cybersecurity risk of its product. The effort for this check depends largely on whether the supplier has done a full, light-touch or no CRA compliance for its FOSS component. According to Recital 34, the manufacturer must verify
- whether and how much the supplier complies with the CRA,
- whether the FOSS component bears a CE mark,
- whether and how often the FOSS component receives security updates, and
- whether the FOSS component is free of exploitable vulnerabilities as capture in the European vulnerability database (EUVD) or other publicly accessible vulnerability databases.
The essential requirements for vulnerability handling of Annex I.II do not only apply to the software components of the manufacturer but also to all FOSS components used. The manufacturer must especially carry out its own security tests for the FOSS components. If, however, vulnerabilities in the FOSS components are not relevant to the product's security, the manufacturer can ignore them.
How much CRA compliance the supplier must perform, mainly depends on whether it monetises the FOSS component directly or indirectly in the course of commercial activities. The supplier must perform full, light-touch or no CRA compliance, if it makes available the FOSS in the course of a commercial activity, if it intends the FOSS for commercial activities or if it doesn't intend any monetisation.
The more CRA compliance the supplier takes over the less compliance effort - the less due diligence - the manufacturer has. The manufacturer will take this into account when selecting a component for a certain purpose.
Commercial Activities
The CRA applies only to products with digital elements (PDEs) made available for distribution or use in the course of a commercial activity (see Article 3.22). According to Recital 15 an activity is commercial, if the supplier
- charges a price for its product (CA1),
- charges a price for technical or support services, where the price exceeds the actual costs for developing the product (CA2),
- provides a product for free (e.g., a software platform) through which it monetises other services (CA3),
- provides a product for free in return for personal data (CA4), or
- accepts donations that exceed the actual costs for developing the product (CA5).
The supplier can be a natural or legal person. If a supplier makes its product - including FOSS products - available on the EU market in the course of a commercial activity, it becomes a manufacturer in the sense of the CRA and must perform full CRA compliance. This is true for all PDEs - including FOSS products.
There are two exceptions: not-for-profit organisations (NPOs) and contributors to FOSS projects.
- The development of FOSS by an NPO is not considered a commercial activity (see Recital 18). The Linux Foundation, Apache Foundation, Mozilla Foundation, Eclipse Foundation or freedesktop.org are examples for NPOs. NPOs do not have to perform full CRA compliance. They are regarded as open-source software stewards, which must only perform a light-touch CRA compliance (see Recital 19).
- Natural or legal persons contributing to FOSS projects (contributors) have no CRA obligations.
Recital 18 mentions other ways than accepting donations (CA5) to sponsor a FOSS project. Companies can delegate their own people or can pay people from third parties to work on the FOSS project. They can provide regular financial support so that the FOSS supplier can pay its infrastructure bills or can employ people. As long as the financial support does not exceed the costs for developing, deploying and maintaining the FOSS product, the FOSS supplier does not engage in a commercial activity.
Open-Source Software Stewards
Article 3.14 defines an open-source software steward (OSS steward or steward, for short).
Natural persons can never be OSS stewards. Self-employed persons are natural persons, whereas one-person companies are legal persons. Hence, natural persons either perform full CRA compliance as manufacturers or no CRA compliance at all.
Recital 19 gives examples for activities included by "providing support on a sustained basis":
- hosting and managing of software development collaboration platforms,
- hosting of source code or software, or
- governing, managing and steering FOSS products.
If manufacturers integrate FOSS into their own products and make their product available in the course of a commercial activity, the FOSS is "intended for commercial activities" (see Recital 19). However, this does not mean that the steward engages in a commercial activity.
Open-source software stewards are "subject to a light-touch and tailor-made regulatory regime" (see Recital 19). They must only perform a very simple form of CRA compliance - a light-touch CRA compliance - as outlined by Article 24.
- Article 24.1 - Stewards shall implement a cybersecurity policy similar to the Coordinated Vulnerability Disclosure (CVD) policy of Annex I.II.5-6. Moreover, stewards can follow the voluntary reporting of Article 15, but they are not obligated to do so.
- Article 24.2 - Stewards shall cooperate - on request - with market surveillance authorities to mitigate cybersecurity risks in their FOSS products.
- Article 24.3 - Stewards must report actively exploited vulnerabilities (Article 14.1) and severe incidents (Article 14.3) via the single reporting platform to the responsible CSIRT and to ENISA. Note that stewards are not required to observe the notification periods of 24 hours and 72 hours (Article 14.2 and 14.4). Stewards must also inform the impacted or all users of their FOSS product (Article 14.8).
As stewards must only perform a light-touch CRA compliance, they must not affix the CE mark to their FOSS products (see Recital 19).
Examples, Examples, Examples
Qt LGPL
The Qt Project, which is the governance body behind the Qt Community Edition, provides Qt LGPL free of charge (CA1). Manufacturers can use Qt LGPL without having to buy any technical services (CA2) or any other services (CA3) and without handing over personal data (CA4). The Qt Company, the Qt partners and numerous contributors put in financial and human resources to develop Qt LGPL. These resources don't seem to exceed the actual costs of Qt development (CA5).
In short, The Qt Project does not supply Qt LGPL in the course of a commercial activity. As Qt LGPL is integrated in commercial products, it is intended for commercial activities.
The Commission Guidance on the CRA corroborates this assessment in §49. The community version (Qt LGPL) and the paid version (Qt Commercial) are considered two separate products, even if their code bases are almost identical. Whereas The Qt Project is a steward for Qt LGPL, The Qt Company is a manufacturer for Qt Commercial and must perform the full CRA compliance.
For the CRA, it doesn't matter that Qt Commercial and Qt LGPL are supplied by two different entities and that they have two different licenses. The supplier, the licenses and the code base could be the same and the above argument wouldn't change: Qt Commercial is made available in the course of a commercial activity (CA1) and Qt LGPL is not.
Embedded Linux Distros
SoC, SoM and SBC makers provide embedded Linux distros (a.k.a. Linux BSPs). Makers of operator terminals, touch-panel PCs, industrial PCs and ECUs extend these distros. These makers provide the distros in addition to hardware. There are also suppliers who provide embedded Linux distros without any hardware.
Free and Open-Source Distros
NXP, TI, Variscite, Toradex, Torizon, the Yocto Project, the Debian Project, the Raspberry Pi Foundation, the YOE community and other entities provide embedded Linux distros publicly and free of charge (CA1). Everyone can use these distros without having to buy extra services (CA2 and CA3) and without having to provide personal data (CA4). Companies can provide financial and development support to FOSS products similar to what The Qt Company does with Qt LGPL (CA5).
Strictly speaking, Yocto is not a Linux distro but a tool to build one. Some distro suppliers might exploit this distinction to worm their way out of CRA compliance completely. The tool Yocto does not end up in customer products. It is the customer's job to build a Linux image with Yocto and to do the CRA compliance. Another shady way to avoid CRA compliance could be to mark the distro as not fit for production use. As I don't think that this is legal, I'll equate the tool Yocto with the distro Yocto.
Is Torizon OS a platform through which the Torizon Company monetises other services like Torizon Cloud or products like Toradex SoMs (CA3)? Short answer: No, it isn't. And here is the long answer. Purchasing Torizon Cloud is fully optional. Manufacturers can use the free Torizon OS without Torizon Cloud. Then, they must use alternative solutions for OTA updates, remote access, device monitoring and vulnerability management. Both free and paid alternatives are available. The Torizon Company actively supports bringing up Torizon OS on embedded devices not powered by Toradex hardware.
As using Torizon OS doesn't depend on purchasing Torizon Cloud or Toradex hardware, the Torizon Company is an OSS steward for Torizon OS. However, it becomes a manufacturer for the commercial Torizon product including Torizon OS, Torizon Cloud and Torizon SoM. In this case, the Torizon Company performs the full CRA compliance. The Torizon people confirmed this to me at the Torizon CRA Summit in Munich on 11 June 2026.
Although the legal and natural persons mentioned above are not manufacturers, they intend their distros for commercial activities such as for integration in commercial products. For legal persons like companies and NPOs, the conclusion is clear.
The YOE community is different. To my knowledge, the YOE community is a group of natural persons. As it is not a legal entity, the YOE community cannot be an OSS steward and is out of the scope for the CRA. Nevertheless, it is trying to build an embedded Linux distro that makes CRA compliance easy.
Commercial Distros
Foundries.io (a Qualcomm company) provides its embedded Linux distro - Linux microPlatform built with FoundriesFactory - as a subscription. Peridio does the same with Avocado OS. Linutronix markets its IGLOS distro as "designed for full compliance with the Cyber Resilience Act, NIS-2 and IEC 62443" and offers it for money (the terms are not obvious from their web site).
These companies charge a price (CA1) for their embedded Linux distros typically in the form of a subscription. As long as the subscription is active, customers receive the latest changes. When the subscription stops, customers are stuck on the latest version they got under the active subscription. As the companies make their distros available in a commercial activity, the conclusion is clear.
Some companies make their embedded Linux distros only available, if their customers buy their operator terminals, telematics units or ECUs. They couple the availability of the distro with purchasing their goods (CA2). Hence, these companies are manufacturers under the CRA and must perform full CRA compliance for their products.
If these companies supplied their distros as FOSS, they would only be OSS stewards and would only have to perform light-touch CRA compliance. It is not surprising then that quite a few SoM and SBC makers open-sourced their Yocto layers once the CRA entered the playing field.
Other Software
RAUC, SwUpdate and Mender are OTA update clients. Their maintainers - Pengutronix for RAUC, SwUpdate.org and Mender.io - provide these clients as FOSS without any commercial obligations. They are not manufacturers under the CRA.
All maintainers offer services to integrate their clients into embedded devices. Hence, the clients are intended for commercial activities. Pengutronix and Mender.io are companies. Hence, they are OSS stewards and must perform light-touch CRA compliance. To my knowledge, SwUpdate.org is not an NPO, but run by natural person. If that's true, its maintainer does not fall under the CRA. No CRA compliance needed.
The Mender company provides an end-to-end solution including its update client and an update server. It charges for this solution. For this solution, Mender is a manufacturer and must perform full CRA compliance. For the free and open-source update client, Mender is an OSS steward and must only perform light-touch CRA compliance. The end-to-end solution and the client are considered two products - similar to Qt Commercial and Qt LGPL.
The company LVGL Ltd. provides its embedded GUI library as two separate products: LVGL Open and LVGL Pro. LVGL Open is FOSS. LVGL Pro contains all of LVGL Open and adds some tools like a GUI designer and a Figma importer. The LVGL company is an OSS steward for LVGL Open and a manufacturer for LVGL Pro - requiring light-touch and full CRA compliance, respectively.
As a volunteer organisation, Freedesktop.org is part of the X.org Foundation, an NPO. It provides Wayland and Weston as FOSS without any commercial obligations but intended for integration into commercial products. Hence, freedesktop.org is an OSS steward, which must only perform light-touch CRA compliance.