Does the EU Cyber Resilience Act apply to open source software?

The CRA reaches products with digital elements made available on the Union market, meaning supplied for distribution or use in the course of a commercial activity. Recital 18 applies that test to the supply of the software. The circumstances under which the software was developed, and the way that development was financed, stay out of the assessment.^[1]

Recital 18 settles several cases that come up constantly:

• Free and open source software that its manufacturer does not monetise is outside the scope.
• A FOSS component supplied for integration into another manufacturer's product counts as making available on the market only where the original manufacturer monetises the component.
• Financial support from manufacturers, corporate code contributions and donations leave the activity non-commercial on their own.
• Regular releases on their own say nothing about commercial supply.
• A not-for-profit organisation set up so that all earnings after costs go to not-for-profit objectives is outside commercial activity.
• People who contribute source code to a project that is not under their responsibility fall outside the Regulation entirely.

Recital 20 covers the point maintainers ask about most. Hosting a product on open repositories, including through package managers or on collaboration platforms, is not by itself making it available on the market. The provider of such a service is a distributor only where it supplies the software for distribution or use on the Union market in the course of a commercial activity.^[3]

The Commission guidance sharpens the monetisation question. Its decisive factor is whether access to the software itself, including a specific version or bundled benefits such as technical assistance, is conditioned on remuneration. A paid enterprise edition is placed on the market even where a functionally equivalent free version exists under a FOSS licence, and the two count as different products. Optional support or consultancy sold around a freely downloadable product leaves that product off the market. This guidance is interpretive and carries no binding force.^[11]

Article 3, point (48) defines free and open source software as software whose source code is openly shared and which is made available under a free and open-source licence providing for all rights to make it freely accessible, usable, modifiable and redistributable.^[4]

Two conditions have to hold together:

1. The licence grants the full set of rights, covering access, use, modification and redistribution.
2. The source code is openly shared, meaning publicly available.

Software released under a permissive licence whose source reaches only paying customers or a closed group falls outside this definition, so none of the FOSS provisions apply to it. Such a product is assessed as any other product with digital elements.

Article 3, point (14) defines an open-source software steward as a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements qualifying as free and open source software and intended for commercial activities, and that ensures the viability of those products.^[4]

Recital 19 names software foundations and entities that develop and publish FOSS in a business context, including not-for-profit entities. It counts hosting and managing development collaboration platforms, hosting source code, governing a product and steering its development as sustained support.^[2]

Article 24 sets three obligations.^[6]

1. Put in place and document, in a verifiable manner, a cybersecurity policy fostering secure development and effective vulnerability handling by the product's developers, fostering voluntary reporting under Article 15, and promoting the sharing of vulnerability information within the open-source community.
2. Cooperate with market surveillance authorities at their request, and supply that documentation on a reasoned request in a language the authority understands.
3. Report under Article 14 on a restricted footing. Article 14(1) applies to the extent the steward is involved in developing the product. Article 14(3) and (8) apply to the extent severe incidents affect network and information systems the steward provides for that development.

Two consequences carry real commercial weight. Recital 19 withholds the CE marking from stewards for the products whose development they support, because the regime does not impose the manufacturer obligations on them.^[2] Article 64(10), point (b), disapplies the administrative fines of Article 64(3) to (9) for any infringement of the Regulation by an open-source software steward.^[9]

Steward status is assessed per product. One legal entity can be the manufacturer of the paid edition it places on the market and the steward of the free community edition it publishes without monetisation.

Integrating FOSS into a product you place on the market makes you the manufacturer of that product, and the CRA obligations cover it in its entirety, every integrated component included.

Article 13(5) requires manufacturers to exercise due diligence when integrating components sourced from third parties, so those components do not compromise the cybersecurity of the product. The paragraph says so expressly for free and open source components that have not been made available on the market in the course of a commercial activity.^[5]

Article 13(6) adds the upstream duty. On identifying a vulnerability in an integrated component, including an open source component, you report it to the person or entity manufacturing or maintaining that component, and you address and remediate it under the vulnerability handling requirements of Annex I Part II.^[5]

Integration leaves the component's own status under the Regulation unchanged. You do not take on responsibility for the component's compliance, even where you contribute code to it or fund its development.^[11]

Article 25 empowers the Commission to adopt delegated acts establishing voluntary security attestation programmes for FOSS products, so that developers, users and third parties can assess conformity and ease exactly this due diligence burden. No such programme is in force yet.^[7]

Yes, on one route. Article 32(5) lets a manufacturer of a product qualifying as free and open source software that falls under the important categories in Annex III demonstrate conformity using any of the procedures in Article 32(1). Those include the internal control procedure based on module A set out in Annex VIII, which is self-assessment. The concession carries one condition. The technical documentation referred to in Article 31 has to be made available to the public at the time the product is placed on the market.^[8]

That matters because of what Article 32(2) and (3) otherwise require. A Class I important product escalates to third-party assessment, meaning module B plus C, module H, or a European cybersecurity certification scheme, wherever the manufacturer has not fully applied a harmonised standard, common specification or certification scheme at assurance level at least substantial, or where none exists. Harmonised standards under the CRA are still being developed, so that escalation is the live case for most manufacturers today. Publishing the technical documentation buys a FOSS manufacturer out of it.^[8]

Article 71(2) sets the calendar. The Regulation applies from 11 December 2027. Article 14, covering reporting of actively exploited vulnerabilities and severe incidents, applies earlier, from 11 September 2026. Chapter IV, Articles 35 to 51 on notifying conformity assessment bodies, applies from 11 June 2026.^[10]

For a steward the practical consequence is a split. The Article 24(3) reporting duties follow Article 14 and bite from 11 September 2026. The cybersecurity policy and cooperation duties in Article 24(1) and (2) bite from 11 December 2027.