The Cyber Resilience Act and Open-Source Software

The European Union's Cyber Resilience Act (CRA) aims to improve the cybersecurity of products with digital elements. This page looks at what it means for free and open-source software (FOSS) and at the role of open-source software stewards.

Contents

1. How the CRA treats FOSS
2. Who is affected?
3. The role of the open-source software steward
4. Obligations of open-source software stewards
5. Risk categories of products
6. Assessment and outlook

How the CRA treats FOSS

The CRA recognizes the particular role and importance of open-source software. The first question is whether a FOSS product falls within its scope at all. What counts is whether the software is made available on the market in the course of a commercial activity.

Where the CRA applies, the conformity assessment route depends on the product category. For most products, internal control (module A) is enough. Important and critical products face stricter procedures, as proprietary products do. For important products, the CRA makes one exception for open source: if the manufacturer makes the technical documentation public, internal control remains available (Article 32(5)).

Who is affected?

The following diagram shows whether and how the CRA affects an open-source project:

The main points:

1. Supplying versus contributing: The CRA distinguishes between supplying FOSS under your own responsibility and merely contributing to it, for example with individual code contributions without control over the release. If you only contribute and do not bear responsibility for the product, you are not in scope. Obligations arise only when the software is made available on the market in the course of a commercial activity.
2. Direct monetization: FOSS providers that make money from it directly count as “manufacturers” under the CRA.
3. Support for commercial activities: Legal persons that support the development of FOSS products for commercial activities on a sustained basis, without monetizing them directly, are open-source software stewards.
4. Making available counts, not development: For manufacturer status, the circumstances in which FOSS was developed and how its development was financed do not matter. What matters is only whether it is made available on the market in the course of a commercial activity. Only this makes a provider a manufacturer under the CRA.

The role of the open-source software steward

The CRA introduces the open-source software steward. This is a legal person, other than a manufacturer, that systematically supports the development of open-source software intended for commercial activities on a sustained basis and ensures its viability. The software is published but not made available on the market by the steward itself. Stewards are subject to a lighter regulatory regime. Examples include:

• foundations that support the development of commercially used FOSS projects on a sustained basis
• non-profit organizations that maintain such FOSS projects over time and ensure their viability

Obligations of open-source software stewards

The obligations of open-source software stewards are less extensive than those of manufacturers, but they still cover several points:

1. Cybersecurity policy: Stewards must put in place a cybersecurity policy that takes account of the specific nature of their role and promotes the voluntary reporting of vulnerabilities (Article 24(1) of the CRA). The policy should address the particular challenges and risks of developing and supplying open-source software.
2. Cooperation with authorities: Stewards must cooperate with market surveillance authorities at their request (Article 24(2) of the CRA). This can include answering questions about security aspects of the software, providing information, or supporting investigations.
3. Reporting vulnerabilities and incidents: Stewards must report actively exploited vulnerabilities to the extent that they are involved in developing the products concerned. They must report severe incidents to the extent that the incidents affect the systems the steward provides for development. Reports go to the CSIRT designated as coordinator and to ENISA through the single reporting platform. This creates transparency and allows a faster response to security risks.

Risk categories of products

The CRA sorts products with digital elements into risk categories:

• Default category: Most products with digital elements fall into this category, including many FOSS projects. The manufacturer assesses conformity itself.
• Important products: These require either full application of harmonized standards or the involvement of a notified body. Examples are operating systems, software that searches for, removes, or quarantines malicious software (anti-virus), and routers, modems, and switches, as well as firewalls in the higher class.
• Critical products: For this category, the Commission can require a European cybersecurity certificate in the future. Examples are smartcards and similar devices, including secure elements, and smart meter gateways.

Whether internal control (module A) is enough depends on the product category. Once software counts as a critical product, the stricter procedures apply, even if it is FOSS. For important products, Article 32(5) of the CRA provides an exception: manufacturers of FOSS in a category listed in Annex III can still use internal control, provided they make the technical documentation public when they place the product on the market.

For more on conformity assessment, see our overview of the Cyber Resilience Act.

Assessment and outlook

The CRA tries to strike a balance for open-source software. Commercial FOSS providers have obligations similar to those of proprietary software manufacturers. Non-commercial FOSS projects and their supporters face a lighter regime. The main obligations of the CRA apply from December 11, 2027. The reporting obligations of manufacturers have applied since September 11, 2026. For open-source software stewards, the reporting obligation under Article 24(3) applies only from December 11, 2027.

The steward category shows that the legislator recognizes the particular role and importance of FOSS and wants to avoid unnecessary burdens. FOSS projects are still expected to take certain measures to ensure cybersecurity.

FOSS developers and organizations should familiarize themselves with the requirements of the CRA and check which category they fall into. In particular, they should consider drawing up a suitable cybersecurity policy and set up processes for cooperating with authorities and for reporting security incidents.