Almost every app, plugin or firmware image is mostly open source. A typical product pulls in dozens or hundreds of libraries that someone else wrote. The Cyber Resilience Act (Regulation (EU) 2024/2847, "CRA") does not change that - but it makes one thing clear: if you sell the product, you answer for what is inside it.
When is open source itself in scope?
The CRA covers products "made available on the market", which means supply "in the course of a commercial activity, whether in return for payment or free of charge" (Art. 3(22)). Free and open-source software is software whose source code is openly shared under a licence that gives the rights to freely access, use, modify and redistribute it (Art. 3(48)).
The recitals draw the line at monetisation: free and open-source products "that are not monetised by their manufacturers should not be considered to be a commercial activity" (Recital 18). Signs of monetisation listed there include charging a price for the software, charging for technical support beyond cost recovery, monetising it through a platform for other services, or requiring personal data for purposes other than security, compatibility or interoperability.
The Commission's guidance of 27 July 2026 adds worked examples. In short:
| Situation | Under the CRA? |
|---|---|
| Library published for free, voluntary donations, nothing gated | Out |
| Individual developer sending pull requests to a project | Out - contributors have no CRA duties |
| Package repository hosting other people's packages | Out for the hosted content |
| A company funds a feature that is released openly | Out - funding alone does not make it the manufacturer |
| Paid edition, or a version bundled with paid support | In |
| Security updates or binaries only for donors or subscribers | In - treated as a price |
| Free app that earns from ads, commissions or subscriptions | In |
| Software that requires personal data for analytics or advertising | In |
If your own open-source project has a paid "pro" plan or paid support, read it as: the product is in scope. Our scope check walks through the general test.
Open-source stewards: a lighter regime
The CRA created a new role: the open-source software steward, a legal person other than a manufacturer that systematically supports the development of specific free and open-source products on a sustained basis (Art. 3(14)). Think of foundations and similar bodies that host and govern projects intended for commercial use.
Stewards must (Art. 24):
- put in place and document in a verifiable way a cybersecurity policy that fosters secure development and effective vulnerability handling by the project's developers;
- cooperate with market surveillance authorities on request;
- report actively exploited vulnerabilities and severe incidents under Article 14 to the extent they are involved in the development, or when an incident affects their own network and information systems.
Stewards may not affix the CE marking (Recital 19), and administrative fines do not apply to them (Art. 64(10)(b)).
What stewards are not: a guarantee for you. A library having a steward does not move your obligations to the steward. You still answer for your product.
If you sell a product built on open source
This is where most small companies are. You ship a paid app, a premium plugin, an SDK or a device, and it contains open-source code. You are the manufacturer of the whole product (Art. 3(13)), and four duties follow.
1. Due diligence on components. When you integrate components from third parties, you must exercise due diligence so that they do not compromise the cybersecurity of your product. This explicitly includes free and open-source components that were not made available in the course of a commercial activity (Art. 13(5)). In practice: choose maintained libraries, pin versions, watch for known vulnerabilities, and replace abandoned ones.
2. Know what is inside - the SBOM. Annex I, Part II, point 1 requires you to identify and document the vulnerabilities and components in your product, including by drawing up a software bill of materials covering at least the top-level dependencies, in a commonly used, machine-readable format. Without it you cannot answer the question "are we affected?" when a new CVE appears. More in CRA SBOM and technical documentation.
3. Report upstream and fix. If you find a vulnerability in an integrated component, including an open-source one, you must report it to the person or entity that manufactures or maintains the component, and address and remediate it as Annex I, Part II requires. Where you have developed a fix, you must share the relevant code or documentation with the maintainer, where appropriate in a machine-readable format (Art. 13(6)).
4. Report exploited vulnerabilities in 24 hours. If a vulnerability in a library inside your product is actively exploited, it is a vulnerability in your product. Since 11 September 2026, Article 14 requires an early warning within 24 hours, a notification within 72 hours and a final report within 14 days of a fix being available. See CRA 24-hour reporting.
You must also keep documenting relevant cybersecurity aspects, including vulnerabilities you become aware of and information from third parties, and update your risk assessment where needed (Art. 13(7)).
What this looks like week to week
| Task | How often | Why |
|---|---|---|
| Generate an SBOM from the lock files | Every release | Annex I, Part II(1) |
| Match the SBOM against vulnerability databases | Daily | So you notice an exploited CVE within hours, not weeks |
| Check whether the vulnerable function is actually used | Per new CVE | Decide: fix now, or document why you are not affected |
| Report to the library maintainer, share your fix | When you find something | Art. 13(6) |
| Update the dependency and ship a security update | Without delay | Annex I, Part II(2) |
| Draft the 24-hour early warning | When a CVE is actively exploited | Art. 14 |
Generating the SBOM is the easy part: free tools do it in seconds. The work is the daily follow-up - and that is the part that tends to be skipped in a three-person company.
Common mistakes
- "The library is free, so it is not my problem." Article 13(5) says the opposite.
- "We only use well-known packages." Well-known packages have vulnerabilities too; the CRA asks you to handle them, not to avoid them.
- "We wait for the maintainer to fix it." You must remediate in your product. If upstream is slow, that may mean a workaround, a fork or replacing the library.
- "Our open-source core is free, only the cloud is paid." If the paid service monetises the software, the product is likely in scope (Recital 18).
Not sure where you stand?
Take the free "Does the CRA apply to me and what must I do by December 2027" check: 8 questions, about 3 minutes, result on screen and checklist by e-mail. Take the free check
If the CRA applies to you, Earlybell does the recurring part every week: an SBOM with every release, a daily check of all your dependencies, ready-to-send drafts of the 24-hour and 72-hour reports for you to submit, and an up-to-date disclosure policy and security.txt. 49 EUR per product per month.
This article is based on Regulation (EU) 2024/2847 (Cyber Resilience Act) and on guidance published by the European Commission. It is not legal advice. Article numbers refer to that Regulation.