As the leader of a foundation or project that may qualify as an open source software steward under the EU Cyber Resilience Act (CRA) you have ongoing obligations relating to cybersecurity, vulnerability handling, cooperation with authorities, and, depending on the support you provide, regulatory reporting. 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 every qualifying steward should consider:

  1. Identify the responsible legal entity. Confirm which legal person qualifies as the steward for each relevant project or group of projects. Make the steward’s identity and contact information readily available, including on the project’s website or repository where appropriate..
  2. Determine which projects are in scope. Identify which of your organization’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. 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. Establish and publish a cybersecurity policy. 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. For example, the LF has a top-level security policy, but some of its projects may have or want one of their own.
  4. Provide clear vulnerability and incident reporting channels. Operationally adopt security processes, tools, and policies (e.g., reporting channels, vulnerability coordination, CNA support, and security tooling). We suggest considering or reusing existing examples, such as the LF’s. Where practical, document how the project uses or 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. Prepare for CRA reporting obligations. Where Article 24(3) applies, 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 (https://csirtsnetwork.eu/#network_members)
  7. Establish an incident response process. Maintain processes for detecting, assessing, escalating, and responding to security incidents affecting project infrastructure and development systems. Define who makes reporting decisions, who communicates externally, and how legal/security escalation occurs.
  8. Be prepared to cooperate with authorities. Designate a contact point for MSAs and be prepared to provide requested documentation. Understand the roles of ENISA and national CSIRTs in CRA reporting, vulnerability coordination, and incident response. Establish a process to coordinate authority requests with relevant project, security, legal, and compliance teams.
  9. Support secure development and responsible dependency management. Perform due diligence on software components used by the project before publication. Consider appropriate security practices for the project’s risk profile, including: security reviews and threat modeling; dependency and vulnerability management; SBOM generation where useful; automated security tooling; secure build and release practices; and appropriate verification of important third-party components. Consider the Concise Guide for Evaluating Open Source Software and the Open Source Project Security Baseline.
  10. Encourage members to actively support critical upstream projects. Listen to “What’s in the SOSS - S2E13 From Compliance to Community: Meeting CRA Requirements…”.

To help put these 10 actions into practice, review and tailor the LF CRA Stewards Playbook to your organization’s stewardship framework. 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.
  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).

This is a living document - to submit PRs please use this link: https://github.com/ossf/wg-globalcyberpolicy/blob/main/docs/CRA/stewards-one-pager.md