As the leader of a foundation or project within the Linux Foundation, there are new legal requirements under the EU Cyber Resilience Act (CRA) that we, as open source software stewards*, must fulfill. Your members and maintainers may have already asked you about what they are required to do under the law. This document is a quick reference for you to understand the actions you and your group must take prior to the EU Cyber Resilience Act (CRA) reporting deadline for Manufacturers (Sep 11, 2026) and when the CRA fully goes into effect (Dec 11, 2027):

*An ‘open-source software steward’ means 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 (PDEs), qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products (Article 3.14)

The top 10 things to consider by the projects within the Linux Foundation to meet their CRA steward obligations:

  1. Confirm your foundation’s legal entity and include it on your foundation’s website. For LF Projects, if you are unsure about who your legal entity is, please contact your PMO and LF Legal via https://legalrequests.linuxfoundation.org/.
  2. Identify which of your foundation’s software projects need a steward. Not all do, however, if a software project is being used for commercial purposes (as many “graduated” projects are), then it is likely to need a steward. Consider deploying a security.md,or security.txt README.md, and/or FAQ about CRA obligations within each such project. Each such software project should identify their foundation (“LF Project”) as their steward. The software project can define its own specialized processes or defer to the general ones defined by its foundation, as long as they meet legal requirements.
  3. Understand your foundation’s security/reporting policy, security SMEs, and vulnerability handling. Post the policy. Consider OpenSSF’s Guide to Coordinated Vulnerability Disclosure for Projects & Maintainers & Guide to Becoming a CNA for OSS Projects. The LF has a top-level security policy, but your project may have or want one of their own.
  4. Operationally adopt and reuse LF-wide security processes, tools, and policies (e.g., reporting channels, vulnerability coordination, CNA support, and security tooling), documenting how the project relies on these shared mechanisms rather than duplicating them
  5. Establish processes for active exploit/cybersecurity breach detection. Publicly state how to report vulnerabilities/security incidents - both for repo code and infrastructure to you (e.g., GitHub private reporting, Linux kernel security bug reporting).
  6. Be prepared to report vulnerabilities using the EU Single Reporting Platform (SRP) operated by ENISA, and identifying relevant EU National CSIRTs, for reporting exploits/incidents (e.g. the Centre for Cybersecurity Belgium - CCB)
  7. Understand provided services and consider offering additional capabilities (e.g., SBOM generation, tooling support) to assist projects. See OpenSSF Projects.
  8. Perform due diligence on software components used by the project before publication. Consider the Concise Guide for Evaluating Open Source Software and the Open Source Project Security Baseline.
  9. Encourage members to actively support critical upstream projects. Listen to “What’s in the SOSS - S2E13 From Compliance to Community: Meeting CRA Requirements…”.
  10. Review and tailor the LF CRA Stewards Playbook for your community.

Bonus Thing - Take free course “Understanding the EU Cyber Resilience Act (CRA) (LFEL1001)”

CRA Steward Obligations

The table below is taken from the text of the CRA:

Area Citation Requirement TL/DR
Cyber Policy Article 24 1. Open-source software stewards shall put in place and document in a verifiable manner a cybersecurity policy to foster the development of a secure product with digital elements as well as an effective handling of vulnerabilities by the developers of that product. That policy shall also foster the voluntary reporting of vulnerabilities as laid down in Article 15 by the developers of that product and take into account the specific nature of the open-source software steward and the legal and organisational arrangements to which it is subject. That policy shall, in particular, include aspects related to documenting, addressing and remediating vulnerabilities and promote the sharing of information concerning discovered vulnerabilities within the open-source community. security.md +vuln handling process/link +detailed secure development practices
Cooperation Article 24 2. Open-source software stewards shall cooperate with the market surveillance authorities, at their request, with a view to mitigating the cybersecurity risks posed by a product with digital elements qualifying as free and open-source software. cooperate with M.S.A. to mitigate risks
    Further to a reasoned request from a market surveillance authority, open-source software stewards shall provide that authority, in a language which can be easily understood by that authority, with the documentation referred to in paragraph 1, in paper or electronic form. policy posted electronically, translated on request
Vulnerability Reporting Article 24 3. The reporting obligations laid down in Article 14(1) shall apply to open-source software stewards to the extent that they are involved in the development of the products with digital elements. The reporting obligations laid down in Article 14(3) and (8) shall apply to open-source software stewards to the extent that severe incidents having an impact on the security of products with digital elements affect network and information systems provided by the open-source software stewards for the development of such products. Report vulns and known exploits to the dedicated Union’s officials

In more plain language, here is what the Steward’s obligations come down to:

  1. Provide a vulnerability reporting process and a cybersecurity policy, to be adopted and publicly shared by each affected project, including details on secure development practices.
  2. Have a single point of contact for reporting and inquiring about vulnerabilities and potential incidents - both for the repo code and infrastructure (e.g. https://www.linuxfoundation.org/security)
  3. If approached by EU officials (Market Surveillance Authority (MSA), ENISA, National CSIRT, etc.) provide requested information as able. If unsure - consult with security@linuxfoundation.org.
  4. If a project’s software is known to be actively exploited or if foundation infrastructure has suffered a cybersecurity incident, report to the ENISA Single Reporting Platform (SRP).