The Cyber Resilience Act and the unpaid maintainer
Europe is about to regulate software security across the whole product lifecycle. Open source is mostly carved out, and mostly is doing a lot of work.
The EU Cyber Resilience Act imposes security requirements on products with digital elements sold in the EU. Reporting obligations for actively exploited vulnerabilities begin this September; the main obligations follow at the end of 2027.
If you sell software into Europe, this is a real compliance project. If you maintain open source, the situation is more nuanced than either the panic or the reassurance suggests.
what it requires#
For products with digital elements — which is essentially any software or connected device sold commercially:
- Security by design and by default. Documented, with a risk assessment.
- No known exploitable vulnerabilities at time of release.
- Security updates for a support period, minimum five years or the expected product lifetime.
- A software bill of materials, maintained.
- Vulnerability disclosure process, published.
- Reporting of actively exploited vulnerabilities to the authorities within 24 hours of becoming aware, with follow-ups.
- CE marking and conformity assessment, the depth of which scales with product criticality.
That last set of obligations is the near-term one and the 24-hour clock is aggressive.
the open source position#
The Act was substantially amended after the initial draft caused an outcry from the open source community. The current position, roughly:
Not covered: software developed and supplied outside the course of a commercial activity. A maintainer publishing a library for free is not a manufacturer.
Covered: anyone who integrates that library into a commercial product. The obligation lands on the person selling the product, not on the upstream.
Partially covered: a new category of "open source software steward" — foundations and organizations that support the development of open source used in commercial products. Stewards have lighter-touch obligations around security policy and cooperation with authorities, not full manufacturer duties.
That structure is basically correct. The obligation should sit with the entity taking money for the product.
the part that will still hurt#
The obligation may not flow upstream legally, and it will flow upstream socially.
A company that must produce an SBOM, attest to no known exploitable vulnerabilities, and report incidents within 24 hours will start asking questions of its dependencies. Those questions arrive as GitHub issues addressed to unpaid maintainers:
- "Can you provide an SBOM for this library?"
- "What is your vulnerability disclosure policy?"
- "Can you commit to a support period?"
- "Please fill out this 40-question security questionnaire."
None of that is legally required of the maintainer. All of it will land in their inbox, and the maintainer of a two-thousand-line utility with a hundred million downloads is going to receive a lot of it.
The predictable outcome: some maintainers will comply out of conscientiousness and burn out. Some will add a line to their README saying they provide no warranties and will not respond to compliance requests, which is entirely their right. Some will archive the project.
what companies should actually do#
If you are the one with the obligation:
Do not send questionnaires upstream. Answer the questions yourself, about your product, using the information that is publicly available. That is what the regulation asks of you.
Generate the SBOM from your build, not by asking your dependencies. Tooling for this is mature.
Fund the projects you depend on. This is the actually effective response, it is cheap relative to compliance costs, and it is the only thing that improves the underlying situation. A maintainer with funding can respond to security reports; one without cannot.
Have a vendored fallback plan for critical dependencies with a single maintainer. If they archive the project, what do you do? Answer that before you need to.
the honest assessment#
The Act is trying to fix a real problem: consumer devices ship with known vulnerabilities and are never patched, and there has been no consequence for that. The obligations on manufacturers are reasonable and overdue.
The risk is that compliance cost lands disproportionately on small companies and that pressure lands informally on volunteers who owe nobody anything.
The mitigation for both is the same and it is boring: fund maintenance, generate your own compliance artifacts, and do not treat your dependencies' authors as your vendors. They are not, they never agreed to be, and the license says so explicitly.
— Dom, April 20, 2026