tl;dr Contributors are not legally liable for security issues, and neither are OSS stewards.

Obligations of contributors and OSS stewards

Contributors

Don’t worry contributors, the CRA is your friend. If you are a contributor to an OSS project - regardless of the size or the market share of the project - rest easy. You will not be held liable for the vulnerabilities found in the code, nor will you be obliged to fix them. It is explicitly stated in the preamble of the CRA that it does not impose any obligations on contributors:

This Regulation 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. 1

Since an OSS steward, as explained below, must be a legal person, you will never be deemed a steward.

OSS stewards

OSS stewards, in plain terms, are legal persons that provide sustained support, maintenance and infrastructure for OSS projects, provided they do not act as a commercial vendor 2. For example, The Linux Foundation is the steward for Linux, the Drupal Association and the TYPO3 Association are the stewards for the respective CMS.

As mentioned above, since the responsibility to fix vulnerabilities lies with the manufacturers, OSS stewards do not bear the burden of addressing them. However, OSS stewards may bear certain responsibilities.

As of March 2026, the guidance on the application of the CRA has not been finalised, which defines how the regulation is applied in practice 3. The obligations of each OSS steward will likely differ depending on their level of involvement in the project, but the determining factors remain undefined until the guidance is finalised later this year. I will update this post and/or publish a follow-up post once the final version of the guidance is available.

Below is the brief summary of obligations OSS stewards may need to fulfill:

  • ‘document . . . a cybersecurity policy to foster the development of a secure product . . . as well as an effective handling of vulnerabilities’ 4
  • Cooperate with the market surveillance authority to mitigate the cybersecurity risks 5
  • Swiftly report to ENISA regarding actively exploited vulnerabilities, and notify users of the risks and corrective measures 6
  • ‘[establish] voluntary security attestation programmes’ 7

OSS stewards are not subject to administrative fines

Unlike economic operators such as manufacturers and distributors, stewards are not subject to administrative fines. This is clearly stated in Article 64 (10 b). Stewards will, of course, be expected to cooperate, but they will never be penalised.

For being non-profit organisations as well as the powerhouse of innovations, it only makes sense to exclude stewards from the corrective measures involving administrative fines. However, the initial draft of the CRA published in 2022 did not clearly distinguish OSS stewards from manufacturers.

This distinction was made after various open source advocates campaigned against the initial draft. A series of consultations were followed by open letters raising concerns over the damage the proposed regulation would incur to the open source ecosystem. (This change is incredibly significant to the OSS community as a whole. Kudos to all who were involved.)

So… when a vulnerability is found, who fixes it?

When a vulnerability is identified within a product, the manufacturer bears the primary responsibility for reporting and resolving it. From the perspective of stewards and maintainers, this is great for two key reasons: 8

  • It alleviates the burden of maintainers (although they are still expected to cooperate in verifying fixes, preparing security advisories, and coordinating releases)
  • It effectively prevents manufacturers from ‘free-riding’ on the OSS ecosystem supported by dedicated volunteers

Resources

The Eclipse Foundation has published a comprehensive whitepaper detailing the current understanding of the obligations of OSS stewards: https://github.com/orcwg/orcwg/blob/main/cyber-resilience-sig/whitepapers/stewards-and-cra.md

While I have consulted several sources regarding these obligations, this whitepaper is the most thorough I have encountered so far.

As previously noted, bear in mind that it remains uncertain which specific obligations will apply to each steward until the official guidance is finalised.

The boundary between contributors/stewards and manufacturers

I will explain in another post, but in the CRA, a manufacturer is defined as those who make the products with digital elements.

So if a legal entity doesn’t only maintain the OSS, but also uses the software to run a business, then they are considered a manufacturer. For example:

  • providing paid service, support and/or extra features
  • producing products that include the OSS

It is quite interesting to see how the regulation may be applied in practice. If you are interested, you can find a number of complex scenarios in the draft version of the guidance 9.

Conclusion

If you are an individual contributor, then there is nothing you need to worry about.

If you are part of an OSS steward, you also don’t need to worry about you or the organisation being penalised for failing to comply with the regulation. However, keep an eye on the status of the guidance, and once finalised, produce documents and implement measures as necessary.


  1. Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act) [2024] OJ L 2024/2847, recital 18 https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847 accessed 11 March 2026. ↩︎

  2. ibid art 3. The CRA 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’. ↩︎

  3. European Commission, ‘Draft Commission guidance on the Cyber Resilience Act’ https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en accessed 19 March 2026. ↩︎

  4. CRA, art 24(1). ↩︎

  5. ibid art 24(2). ↩︎

  6. ibid art 24(3). ↩︎

  7. ibid art 25. ↩︎

  8. This was explained in my previous post ‘Why the CRA Complicates Providing IT Products and Services in the EU (And Why It Ultimately Benefits Us All)’ ↩︎

  9. European Commission, ‘Draft Guidance’ (n 3) pt 3.5. ↩︎