We Speak Supply Chain: Open Source
We Speak Supply Chain: Open Source
There is a comfortable belief circulating in open source that the Cyber Resilience Act carved out an exemption and that the problem therefore belongs to somebody else. The belief is half right, which is the worst kind of right.
The regulation does not exempt open source. It exempts a particular way of supplying it, and if you have built a business around your project, there is a good chance in the near future that you will no longer be able to supply it that way any more.
The line is drawn around money, not licences
Nothing in the CRA turns on which open-source licence you picked. Apache, GPL, MPL, it makes no difference. What matters is whether the software is supplied in the course of a commercial activity. Recitals 15 to 20 work through this at some length, and the shape of it is roughly as follows.
Software developed and shared outside a commercial activity sits outside scope. A project run by volunteers, or by a not-for-profit, given away with no attempt to monetise, is not what the regulation is aimed at. Donations that do not exceed certain amounts and are received without profit intention do not change that. Neither does the fact that companies happen to use your code, or that a manufacturer sponsors the project.
What does change it is money flowing to you for the thing itself. Charging for the software. Charging for technical support beyond recovering your actual costs. Monetising through personal data for purposes other than security, compatibility or interoperability. Developing the project inside a company so that it can be shipped in that company’s commercial products.
If any of those describe you, the exemption you were counting on is not there.
Where the common models actually land
What you do | Likely role under the CRA |
|---|---|
Volunteer project, no revenue, occasional donations | Out of scope. Nothing to do, though downstream will still ask. |
Foundation or similar body sustaining a project used commercially | Open-source software steward, Article 3(14). Lighter regime under Article 24. |
Open core, free edition plus paid enterprise edition | Manufacturer for what you sell. The status of the free edition is arguable and depends on how tightly it feeds the paid one. |
Dual licensed or source-available, paid for commercial use | Manufacturer. You are charging for supply. |
Paid support or hosting around your own project | Commercial activity. Manufacturer for the product you place on the market. |
Company maintaining a project it embeds in its own products | Manufacturer for those products, and in practice the upstream everyone else reports to. |
Some of these boundaries are genuinely unsettled and will be argued about for a few years. That is not a reason to assume the answer you prefer.
What a manufacturer owes
If you land in the manufacturer column, the obligations are the same ones every other vendor carries. Annex I essential requirements and vulnerability handling. Annex VII technical documentation. An EU Declaration of Conformity and CE marking. A support period of at least five years under Article 13(8), unless the product’s expected lifetime is shorter. Reporting of actively exploited vulnerabilities under Article 14, with 24 hours to send an early warning. Article 14 also requires a separate 24-hour early warning for severe incidents having an impact on the security of the product, which is a distinct obligation from vulnerability reporting.
Read that last one twice, because it is the one that hurts. Twenty four hours is not a lot of time for a project that triages when someone has a spare evening.
What a steward owes
Article 24 is much lighter, and it was written deliberately so. A steward needs a documented cybersecurity policy, has to cooperate with market surveillance authorities, and has to report actively exploited vulnerabilities to the extent it is involved in the development of the product.
No CE marking. No Declaration of Conformity. No five year support commitment. If your project is held by a foundation whose purpose is to sustain it, this is very likely where you sit, and the burden is manageable.
The catch is that stewardship is defined by what the body actually does, not by what it is called. Setting up a foundation as a liability shield while a single company makes all the decisions and takes all the revenue is a structure that will not survive contact with anyone reading Article 3(14) carefully.
Being out of scope does not get you out of the conversation
Every commercial user of your project is a manufacturer, and Article 13(5) obliges them to exercise due diligence on the third party components they integrate. They have to know what is in their product, so they need an SBOM that includes you. They have to hand a vulnerability handling story to a market surveillance authority, and yours is part of it. Under Article 13(6), when they find a vulnerability in your component they must report it to you and share whatever fix they wrote.
None of that requires you to be in scope. It only requires them to be. So the questionnaire arrives regardless, and the honest position is that “we are exempt” is not an answer to it. It is an answer to a different question that nobody asked.
Projects that cannot answer will get worked around. Vendored, forked, pinned to an ancient version, or quietly swapped out at the next architecture review. That is not a threat, it is just what a procurement team does when a dependency becomes a compliance risk they cannot manage.
The version of this that is good news
The CRA also creates the first real commercial case for paying an open-source maintainer, by turning responsiveness into something downstream users legally need.
For twenty years the standard complaint of the commercial open source maintainer has been that companies build billion euro businesses on your work and contribute a bug report at Christmas. The CRA changes the economics of that, because it turns your responsiveness into something your users legally need.
An integrator on a 24 hour clock needs an upstream that answers in hours. They cannot get that from a mailing list. They can get it from a support agreement with the people who wrote the code, which is you, and they now have a compliance reason to sign one rather than a warm feeling about sustainability.
This is the first regulation that has made a maintenance relationship worth paying for. Products that fit that opening include commercial support with a contractual notification window, voluntary security attestation of the component, SBOM and evidence delivery as part of the subscription, and a named contact who is awake when the CVE lands.
The CRA sketches a voluntary security attestation route for open source in Article 25. The details are still being worked out, but the direction is clear. Attestation is what lets a downstream manufacturer rely on your component without treating it as an unmanaged risk. If your project is the one that has it, you are the one that stays in the bill of materials.
Where to start
- Work out honestly which column you are in. Not which one you would like to be in.
- If there is a foundation, look at whether it genuinely stewards the project or whether it is decorative.
- Generate SBOMs from the build, publish them with releases, and treat them as a deliverable rather than a favour.
- Publish a disclosure policy and a contact point that is actually monitored.
- Decide what you are willing to promise about support and security fixes, and say so in writing before someone asks you to promise more.
- Look at your commercial agreements. If you sell support, hosting or an enterprise edition, those contracts are about to acquire notification windows and liability terms that were not in the version you drafted in 2021.
We speak supply chain
Comply.Land works on the CRA where it is actually written, in the harmonised standards, the essential requirements and the technical documentation. We also spend a lot of our time in open source, which means we understand both what the regulation asks and what a maintainer can realistically deliver on a Tuesday.
Send us what you already have. A gap analysis, a conformity assessment or a draft technical file. Our experts will revert back within 48 hours with a pass or fail, free of charge. Submit your document at https://comply.land/products/#hs-form-doc-review
If you are still trying to understand whether you are a manufacturer, or require further support, get in touch with us at https://comply.land/contact/
General information on Regulation (EU) 2024/2847, not legal advice. Article, Annex and recital references are to the Cyber Resilience Act as published. Whether the regulation applies to you depends on your project, how it is supplied and how you make money from it.