The EU Cyber Resilience Act (Regulation 2024/2847) is a regulation (not a directive: it applies directly in all member states) that entered into force on December 10, 2024. By September 11, 2026, manufacturers must report actively exploited vulnerabilities within 24 hours, with detailed reports within 72 hours. Full compliance is required by December 2027.

A Linux Foundation survey from March 2025 found that 62% of respondents were “not familiar at all” or only “slightly familiar” with the CRA. Only 28% correctly identified 2027 as the target year. 50% of stewards cited funding as their biggest gap.

September 2026 is five months away. This matters for open source right now.

Steward vs. manufacturer

The CRA introduces a distinction that matters a lot for foundations and maintainers.

A manufacturer places a product with digital elements on the EU market in the course of a commercial activity. They have the heaviest obligations: security requirements, conformity assessments, SBOMs, vulnerability handling, incident reporting.

An open source steward is a legal person (not an individual) that systematically provides sustained support for open source software intended for commercial activities, but does NOT place it on the market themselves. The CRA’s treatment of open source clarifies this distinction.

The FreeBSD Foundation is a good example. It employs developers, manages infrastructure, governs the project. FreeBSD itself is used in commercial products by Sony, Netflix, Juniper, and others. But the Foundation doesn’t sell FreeBSD: it supports an OS that manufacturers integrate into their products. Foundation = steward. Sony, Netflix = manufacturers.

Stewards have lighter obligations than manufacturers, but they’re not zero. Depending on the level of involvement (the draft guidance describes three tiers), stewards may be required to report actively exploited vulnerabilities within 24 hours and severe incidents within 72 hours.

Individual contributors are explicitly excluded from CRA obligations (recital 18). If you submit a patch to FreeBSD or the Linux kernel, the CRA does not apply to you.

Who’s working on this

I want to be clear: I’m not the only one who noticed these problems. There’s a large and active community working on CRA and open source, and I’m a small part of it.

The ORC Working Group (Open Regulatory Compliance) coordinates much of this work. Their Cyber Resilience SIG brings together people from foundations, companies, and policy organizations to review the regulation and draft guidance. The cra-hub repository tracks open issues, and the orcwg/orcwg repo collects formal feedback on the EC guidance. The Eclipse Foundation, Linux Foundation, Apache Software Foundation, Python Software Foundation, and others are involved.

There are also resources worth knowing about. The Linux Foundation published a free course on the CRA (LFEL1001). The OpenSSF has working groups on vulnerability disclosures and SBOM tooling. NLnet Labs has been contributing on upstream reporting. The Eclipse Foundation’s CRA page tracks their compliance approach. And the EC’s own consultation page is where formal feedback goes before the April 13 deadline.

Gaps I helped identify

Through the ORC WG’s Cyber Resilience SIG, I reviewed the EC’s 75-page draft guidance from a FreeBSD perspective (consultation deadline: April 13, 2026). Most of the gaps below are now tracked as GitHub issues with input from multiple contributors. I raised some of them, supported others, and in several cases the ORC WG had already flagged the same concerns independently.

Non-EU stewards have no clear CSIRT (orcwg #256). The CRA requires stewards to report vulnerabilities to a “designated CSIRT.” The rules for identifying the right CSIRT depend on where the steward is established. But the FreeBSD Foundation is in Delaware, the Apache Software Foundation in Delaware, the Python Software Foundation in Delaware, Mozilla in California. The guidance says nothing about which CSIRT applies to non-EU stewards.

Documentation language is unspecified (orcwg #255). The regulation requires documentation “in a language which can be easily understood by the market surveillance authority.” Most open source projects publish in English. National MSAs operate in German, French, Italian, Polish. For small foundations with limited staff, maintaining documentation in multiple EU languages is not realistic. And if a 24-hour clock is ticking on a vulnerability report, translation delay is not a minor concern.

The three-tier steward model is ambiguous (orcwg #258). The draft guidance creates three levels of steward involvement: non-technical support, IT infrastructure, engineering resources. The idea is that obligations scale with involvement. The problem is that most real foundations span all three tiers simultaneously. The FreeBSD Foundation does branding AND runs infrastructure AND employs developers. Which tier applies? The most demanding one, presumably, but the guidance doesn’t say.

The clock-start for stewards is undefined (orcwg #261, cra-hub #350). When does the 24-hour reporting window start for a steward? For manufacturers, the guidance discusses “reasonable degree of certainty” and the moment they “become aware” of an exploited vulnerability. But that language is entirely framed around “a product.” A steward doesn’t have “a product”: it supports software that shows up in many products. The trigger mechanism is different, and the guidance doesn’t address it.

Steward definition assumes publishing (orcwg #257). The guidance frames steward responsibility around “publishing” and “exercising primary control.” Many foundations meet the steward definition without directly publishing: publishing is handled by project governance. If publishing becomes central to the definition, some foundations could paradoxically fall outside it.

The funding problem

CRA compliance is not free. It requires dedicated staff time, tooling (SBOM toolchains, vulnerability tracking, reporting infrastructure), and probably legal counsel. The Sovereign Tech Agency funded EUR 686,400 for FreeBSD CRA readiness work, but that grant ended in December 2025.

Red Hat already has CVE Numbering Authority status and CSAF/VEX infrastructure. Canonical is marketing CRA compliance as an Ubuntu Pro feature. These companies absorb compliance costs as business expenses.

Foundations can’t do that. They rely on donations and grants. And the companies shipping products built on their software are classified as manufacturers under the CRA: their compliance spending goes toward their own obligations, not back to the foundations.

The CRA turns a chronic funding problem into an acute one. More money, more people, more structure needed, at the exact moment when all three are already stretched thin.

Where I fit in

I completed the Linux Foundation’s LFEL1001 course on the CRA in March 2026. I volunteer with the ORC Working Group’s Cyber Resilience SIG, where I review draft guidance, comment on GitHub issues, and bring the perspective of someone who’s been doing compliance work for 16 years and knows what it’s like to maintain an open source project.

I’ve contributed to several of the issues linked above, both on the ORC WG GitHub and on the EC’s consultation document. Some of my points were independently raised by others. Some I raised first. The important thing is that they’re being tracked and discussed, and the April 13 deadline gives us a concrete window to get this feedback into the EC’s hands.

If you work in open source and care about this, the best thing you can do right now is read the draft guidance and contribute your perspective before April 13. The ORC WG’s cra-hub and orcwg repositories are where the coordination happens.

Sources: EU Cyber Resilience Act (Regulation 2024/2847), EC Draft Guidance consultation, Linux Foundation CRA Readiness Report, ORC Working Group, ORC WG GitHub, FreeBSD Foundation CRA Readiness, LFEL1001 CRA Course. This post is part of the simbiosi.org open source sustainability research.