What the Cyber Resilience Act Means for Community Open Source.

Since 11 September 2026, companies that sell software or connected devices in the EU have had to report actively exploited vulnerabilities in their products within 24 hours of becoming aware of them, through a single reporting platform run by ENISA that went live the same day. That is the first hard deadline of the Cyber Resilience Act. If you maintain a civic tool on GitHub in your evenings, or work at a city that publishes its code, you have probably wondered whether it applies to you.

For most community projects, it most likely doesn't. Nothing here is legal advice. We are a small lab reading the same documents you can, and if your situation is borderline you should ask a lawyer.

The basics first. Regulation (EU) 2024/2847 was published in the Official Journal on 20 November 2024 and entered into force on 10 December 2024. Article 71 sets the rest of the timetable: the reporting rules in Article 14 apply from 11 September 2026, and the regulation as a whole applies from 11 December 2027. That later date is when the main obligations on manufacturers arrive.

The whole regulation hangs on one phrase. It covers products "made available on the market", which Article 3 defines as supply "in the course of a commercial activity, whether in return for payment or free of charge." Free is not automatically outside. Commercial is the test, and recital 18 says how to read it for open source: software "that [is] not monetised by [its] manufacturers should not be considered to be a commercial activity", and "the mere presence of regular releases should not in itself" make it one. People who contribute code to a project they don't control are outside the regulation entirely.

That text was not where things started. When the Commission's proposal was going through Parliament and Council, the open-source world read it as a threat. In April 2023 the Python Software Foundation warned that the PSF "could potentially be financially liable for any product that includes Python code" and that keeping PyPI available in Europe could become impossible. Six days later the Eclipse Foundation, the Open Source Initiative, Linux Foundation Europe and other European open-source organisations sent an open letter saying the draft would have "a chilling effect on open source software development" and that the community had not been consulted. That July the Apache Software Foundation wrote that, under the draft definitions, the act "applies to the ASF, all of its (volunteer) developers, and all our output."

The final text moved a long way. By January 2024 the same ASF author was writing about "lots of improvements & good news": contributors and distribution platforms were no longer treated as economic actors, and lawmakers had invented a new category, the "open-source software steward." Recital 20 of the adopted regulation confirms that simply hosting code on an open repository is not making it available on the market.

A steward is a legal person, other than a manufacturer, that systematically supports free and open-source software intended for commercial activities over the long term. Recital 19 calls their regime "light-touch and tailor-made." Under Article 24, a steward must keep a documented cybersecurity policy for handling vulnerabilities and cooperate with market surveillance authorities when asked. It reports exploited vulnerabilities and severe incidents only to the extent it is involved in development. Article 64(10) says fines do not apply to stewards at all. Their reporting duties don't start until 11 December 2027, not this September. Individuals can never be stewards.

The most useful document for small projects is the Commission's guidance of 27 July 2026, which is non-binding but has 67 worked examples. Its open-source chapter is plain about the common cases. A donation link does not make a project commercial, even when donations exceed costs, unless releases or security updates are effectively reserved for donors. Paid consultancy or training around freely downloadable software does not make the software commercial; a paid edition bundled with support does. Being funded by a company or a public body to build a feature does not change the project's status. A not-for-profit that puts all earnings after costs back into its mission is not placing its software on the market, though it may be a steward. Two triggers catch people out: monetising other services through the app, and requiring personal data processing as a condition of use for anything beyond security or compatibility.

The guidance also settles something that matters a lot for civic tech: web applications accessed only through a browser, and websites, are not on their own products with digital elements. A council's participation portal or a transparency dashboard you host is mostly outside the CRA.

The guidance doesn't address municipalities or public bodies that publish code, and we couldn't find anything official that does. A city releasing an openly licensed tool it doesn't charge for, with no data harvesting attached, looks like the non-monetised case on the guidance's own logic. A city that keeps actively maintaining a component it expects companies to build into their products might fit the steward definition. That second case is a question for your legal team, not for us.

The duty that will reach community projects indirectly is the one on manufacturers. Anyone who places a product on the market has to do due diligence on the open-source components they integrate, and Annex I requires a software bill of materials "in a commonly used and machine-readable format" covering at least top-level dependencies. If a vendor ships your library in something it sells, expect more questions about your release process, your security contact and your dependencies.

So what should a small civic project do now? Write down who the maintainers are and who decides releases, since the guidance puts responsibility on those people and not on drive-by contributors. Publish a security policy with a real contact and a way to report privately. Generate an SBOM in CI; it costs almost nothing and answers the vendor questions before they arrive. If you sell anything around the project, check it against the guidance's examples. If you are a foundation or an institution sustaining a widely reused component, read Article 24 now, because December 2027 is not far off.

You don't have to read the regulation alone. The Eclipse Foundation hosts the Open Regulatory Compliance Working Group, which grew out of a 2024 initiative by seven foundations including Apache, Python, Rust and PHP to write common security process specifications, and maintains a community CRA FAQ. OpenSSF and Linux Foundation Education offer a free 90-minute course, and on 6 October OpenSSF published a CRA readiness guide and user journey.