I maintain a small npm package. It’s free, it has no ads, and nobody pays me for it. Last month I found myself reading a long EU regulation trying to work out whether it makes me legally responsible for that package’s security. That’s a strange place to end up for a side project, and the fact that the answer isn’t obvious is the entire story of the Cyber Resilience Act.
The CRA entered into force on December 10, 2024. Most of it doesn’t bite until December 11, 2027, when the main obligations land — but the first real deadline is sooner than people think. From September 11, 2026, manufacturers of “products with digital elements” have to report actively exploited vulnerabilities and severe incidents to their national CSIRT and ENISA: an early warning within 24 hours, a full notification within 72, a final report within 14 days of a fix. That’s not a distant deadline. That’s next year.
So the question every maintainer in Europe is quietly asking is: am I a manufacturer?
The 2022 version genuinely would have broken things
You have to understand where this started, because the current text is a reaction to how badly the first draft landed.
The 2022 proposal treated software like a toaster. Someone makes it, puts it on the market, and is on the hook if it hurts people. That model is fine for a company shipping a router. It falls apart the moment you remember that the router’s firmware pulls in forty open-source libraries written by volunteers who have never met, don’t know each other’s legal names, and definitely didn’t agree to be liable for a smart-home vendor’s product three dependencies downstream.
More than a dozen open-source organizations wrote an open letter saying, more or less, this will kill contribution. And they weren’t being dramatic. If maintaining a popular library exposed you to EU product liability, the rational move for an unpaid maintainer is to stop, or to geoblock Europe, or to slap on a license clause telling commercial users they’re on their own. The draft managed to threaten exactly the people who hold up the ecosystem it was trying to secure.
The Commission listened, which is rarer than it should be. The final text is a different animal.
Two words do all the work: “commercial activity”
The core carve-out is one sentence: free and open-source software developed or supplied outside the course of a commercial activity is not covered. If you’re not doing it commercially, the CRA does not apply to you. Full stop.
The obvious follow-up — what counts as commercial? — is where the recitals do the heavy lifting, and they’re more reassuring than you’d expect. Recital 18 says the mere presence of regular releases doesn’t make something commercial. Accepting donations without the intention of making a profit doesn’t. Being hosted on a public forge doesn’t. Even a company contributing to your project, or a manufacturer giving you money without you turning a profit, doesn’t automatically flip you into “manufacturer.”
So the weekend hobbyist who ships a project and shares it is safe. The maintainer who cuts monthly releases and has a GitHub Sponsors tip jar is safe. My free npm package with no revenue is, by any honest reading, out of scope.
That’s a genuinely good outcome. But notice what it rests on: intent and profit. “Commercial activity” is a line drawn around your motive and your money, not your code or its reach. And motive is exactly the kind of thing that’s clear in the easy cases and a lawyer’s playground in the hard ones. A maintainer who starts selling support contracts. A project that spins up a paid hosted version. An open-core company whose free tier is the same binary millions of businesses depend on. The regulation tells you the extremes; the interesting middle is left to be argued.
The invention: an “open source steward”
Here’s the part I find genuinely clever, and also a tell.
The CRA created a legal category that didn’t exist before: the open source steward. It’s a legal entity — not a manufacturer — that provides sustained support for open-source software intended for commercial products. Read: the foundations. The organizations that employ maintainers, run the CI, hold the trademarks, and keep critical infrastructure alive on donations.
Stewards get a deliberately light regime. They don’t need CE marking, conformity assessments, or technical documentation. They owe three things: a documented cybersecurity policy, cooperation with authorities, and vulnerability reporting for the projects they steward. And — this is the part that shows the drafters understood the terrain — stewards are exempt from administrative fines. You can’t fine a nonprofit into solvency for a bug in code it gave away.
I think the steward role is the smartest thing in the whole regulation. It acknowledges that between “unpaid individual” and “company selling a product” there’s a third actor — the institution that sustains shared infrastructure — and that leaning on it with product-liability rules would just collapse the institution.
But invent a new legal species and you’ve admitted your taxonomy was wrong. The steward exists because the manufacturer model couldn’t describe how software actually gets made. It’s a patch. A good patch, but a patch over a deeper mismatch: regulators still reach for a world of discrete products with identifiable makers, and modern software is a supply chain of dependencies most of whose authors nobody is paying.
What this actually means if you ship code
Strip away the noise and it’s not that complicated for most people reading this.
If your open-source project has no commercial intent — no product, no paid tier, no support business, donations notwithstanding — the CRA’s manufacturer obligations aren’t yours. Keep shipping. The exemption was written with you in mind, and it’s broad.
If you’re a foundation or a company that systematically sustains open source for others, look hard at whether you’re a steward, and start writing down a vulnerability-handling policy now. It’s cheap insurance and it’s mostly documentation you should have anyway.
And if you sell something with digital elements into the EU — this is you, and the September 2026 reporting clock is already running. The 24/72/14 cadence for actively exploited vulnerabilities is the near-term obligation people are sleeping on while they fixate on the 2027 date.
The honest summary is that the CRA got the aim right. Someone should be accountable for the security of things people pay for, and “it’s built on open source” was never a real excuse for a vendor shipping negligent products. The regulation mostly aims that accountability at the party taking the money, and it went out of its way to spare the volunteers underneath. That’s a better law than the one that almost passed.
I still don’t love that whether a maintainer is liable turns on a phrase — “commercial activity” — that won’t get a real definition until someone gets taken to court over it. For my little package, the answer is clear enough. It’s the maintainer one git commit away from a support contract who’s going to find out where the line is, probably the expensive way.