European Union Cyber Resilience Act (CRA) Compliance Guidelines for LF Hosted Projects
Overview
For open source software stewards, the CRA’s reporting obligations will apply from 11 December 2027 (EC FAQ 5.5 and ENISA FAQ 29), requiring qualifying stewards to report actively exploited vulnerabilities and severe security incidents to EU authorities on tight deadlines (24 hours, 72 hours, and a final report due within 2 weeks of correction for AEVs and 1 month for severe incidents).
The Linux Foundation is handling this by default for LF Hosted Projects. LF’s project-hosting legal entities will act as the CRA stewards for the projects they host (“LF CRA Steward”). They are registered on the EU reporting platform; they know the deadlines, and they file the regulatory reports. LF Hosted Projects do not need to build their own EU CRA regulatory compliance function.
CRA actions for LF Projects
In short, projects need to do three things for CRA Compliance.
- Document whether the software produced by your project is ultimately intended for commercial activities (most widely-used LF open source software projects are). If your project does not publish software, the CRA is not relevant to your project.
- Add a short CRA stewardship statement to your SECURITY.md identifying your LF CRA Steward. Projects can contact support@linuxfoundation.org to assist in identifying their LF CRA Steward.
- Escalate to the LF CRA Steward on a qualifying event. If you learn of an actively exploited vulnerability or a severe incident (for example, compromise of your release process), notify your foundation security contact and your LF CRA Steward immediately, while you fix the problem, never instead of fixing it.
More details on these actions are below.
Document whether the software produced by your project is ultimately intended for commercial activities
The CRA steward regime only applies to open source software that is ultimately intended for commercial activities. For example, software meant to be integrated into commercial products or monetized services. Consider your project’s intended use and ecosystem, then document the conclusion.
- Likely in scope: production-grade software that companies are expected to integrate into products or solutions.
- Likely out of scope: specifications and documentation, training materials, experimental or sandbox projects, and software operated only as a hosted service that is not itself placed on the market for others to use.
If your project is not intended for commercial activities, document that conclusion, tell your foundation, and carry on maintaining good security practices. No stewardship arrangement is needed. Revisit the assessment if the project’s purpose, distribution, or maturity materially changes. If the classification is unclear, ask the LF legal team. Do not make a definitive legal determination on your own.
Add a short CRA stewardship statement to your SECURITY.md identifying your LF steward
Add the following to your SECURITY.md, security.txt, or equivalent (and, where you have one, your project website):
CRA stewardship: This project is supported under the Linux Foundation CRA stewardship framework, as described at https://www.linuxfoundation.org/security. Security vulnerabilities should be reported through the mechanisms described below, which we will coordinate with our CRA steward. For actively exploited vulnerabilities and severe incidents that may require CRA escalation, please use the project’s emergency security reporting mechanisms as appropriate.
Projects must maintain an accessible, private, security reporting mechanism, and have established processes for receiving, assessing, remediating, and disclosing vulnerabilities.
Escalate to the CRA Steward on a qualifying event
Two categories of events can trigger CRA reporting by the LF CRA Steward. If your project becomes aware of either, notify all of the following simultaneously and promptly: your LF CRA Steward and your project’s own security channel.
| Event | What it means |
|---|---|
| Actively exploited vulnerability (AEV)
(reporting the project software has a bug that someone has compromised somewhere, everyone should patch) |
A vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the owner’s permission. Awareness often arrives from outside — a downstream vendor, a security researcher, or a government agency telling you your component is being exploited in the wild. That report itself triggers the escalation duty. |
| Severe incident
(reporting project run systems are compromised) |
An incident that harms (or could harm) the confidentiality, integrity, availability, or authenticity of important data or functions, or that has led (or could lead) to malicious code in the product or in users’ systems. Compromise of your release process resulting in malicious code in a release is the canonical example and must always be escalated. |
When escalating, provide what you have: a description of the issue, reproduction steps, affected versions, any evidence of exploitation, and known mitigations. Don’t wait for complete information – the clock the steward faces starts at awareness.
LF CRA Stewards include the following:
- LF Charities, Inc.
- Linux Foundation Europe
- The Linux Foundation
- Joint Development Foundation Projects, LLC
- LF Projects, LLC
- The Linux Kernel Organization
- LF Open Source, LLC
To contact any of those, please use the usual single point of contact: steward@linuxfoundation.org.
Two clarifications that save a lot of worry:
- An ordinary vulnerability with no evidence of exploitation is not a CRA reporting event. Fix it and release the patch in a timely way, as you always have.
- Never delay remediation while anyone figures out whether an issue is CRA-reportable. Fixing comes first; the steward handles the paperwork in parallel.
FAQ
Can an LF Foundation/Project be their own CRA Steward?
While yes, an LF Foundation/Umbrella/Project be their own CRA Steward, it is highly recommended to use the default LF CRA Steward.
A project should only act as its own CRA steward if it can demonstrate the resources, capacity, and processes are sufficient to carry the obligations long term. Any such arrangement should be agreed and documented with the Linux Foundation before you move forward. Note that a project does not need to be its own legal entity to act as its own CRA steward.
What the LF CRA Stewards will do for Projects
Each LF CRA Steward is putting the following in place ahead of 11 December 2027, so that individual projects don’t have to:
- EU reporting capability. At least one designated representative (Primary AR) registered with a personal EU Login account and able to file reports through the SRP, The steward may additionally designate up to 20 Secondary ARs, who may also submit reports through the SRP.
- Deadline-capable processes. Internal triage and escalation procedures built to meet the CRA’s 24-hour early warning, 72-hour notification, and final-report deadlines.
- CSIRT relationship. Identification of and collaboration with the relevant national coordinating CSIRT (for the LF CRA Stewards, which will be Belgium’s Center for Cybersecurity, based on Linux Foundation Europe’s establishment in Brussels and existing coordination underway).
- Authority interface. Acting as the CRA point of contact for market surveillance authorities and coordinating any responses to authority requests, so authorities deal with the steward, not with individual maintainers.
- A published cybersecurity policy fostering secure development across covered foundations and projects, as CRA Article 24 requires of stewards.
- Records and review. Documentation of stewardship arrangements, covered foundations and projects, communications with market surveillance authorities, and evidence of fulfilment of stewardship responsibilities, including vulnerability/incidents reports, follow-up actions, and other relevant interactions. Periodic review when circumstances change.