How the Cyber Resilience Act treats open source software
The CRA does not regulate open-source maintainers the way it regulates manufacturers. It regulates the company that ships open source inside a commercial product.
A recurring worry among hardware and embedded teams is that the Cyber Resilience Act will make using open-source components legally risky, or that it somehow regulates open-source maintainers the way it regulates manufacturers. Neither is quite right, and the actual answer matters for anyone shipping firmware built on an RTOS, a TLS library, or any of the dozens of open-source packages a typical connected product depends on.
TL;DR: The CRA does not impose manufacturer obligations on open-source software distributed outside a commercial activity. It does impose full manufacturer obligations on you if you integrate open-source components into a product you sell, and it creates a separate, lighter "open-source software steward" category for organisations that commercially support open-source projects without selling a product built on top of them.
Can open source software comply with the Cyber Resilience Act?
The question is slightly the wrong shape. Regulation (EU) 2024/2847 regulates manufacturers of products with digital elements, not software licenses. Open-source software made available outside the course of a commercial activity, the typical case of an individual or community maintaining a project without a commercial arrangement, falls outside the manufacturer obligations entirely. The CRA is not asking whether an open-source project itself is compliant, it is asking whether the commercial product built with it is.
Does using open-source components make my product exempt?
No, and this is the most common misreading. If you take an open-source RTOS, networking stack, or library and integrate it into a product you place on the EU market commercially, you are the manufacturer of that finished product. The essential requirements, secure by design, no known exploitable vulnerabilities, an SBOM, a vulnerability disclosure process, ongoing security updates, apply to your product as a whole, regardless of what fraction of the code is open source. The license on the components does not change who carries the obligation.
What is an "open-source software steward" under the CRA?
This is a real, narrower category the regulation defines for organisations that provide sustained support for open-source software intended for use in commercial products, without themselves selling that product. Think of a foundation that maintains a widely used embedded library commercially supported by donations or sponsorships, but does not ship a physical product. Stewards carry proportionate obligations, largely centred on vulnerability handling and coordinated disclosure, that are meaningfully lighter than the full manufacturer requirements. It is a deliberate accommodation so the CRA does not discourage the open-source foundations the wider ecosystem, including most connected product companies, actually depends on.
Why does this distinction matter in practice?
Because most hardware teams are simultaneously open-source consumers and CRA-obligated manufacturers, and it is easy to conflate the two roles. Your firmware might depend on an open-source MQTT client and TLS stack maintained by a steward-type organisation with light obligations, while your own finished product, the thing with your brand on it that a customer buys, carries the full manufacturer obligations. Confusing "the library is open source" with "therefore my product's compliance burden is reduced" is exactly the gap that shows up during a conformity assessment.
Does the CRA require me to audit every open-source dependency?
Functionally, yes, though "audit" understates the mechanism. The requirement is a Software Bill of Materials covering the components in your product, which for most connected devices means enumerating the open-source packages and versions your firmware and application layer depend on. Once you have that inventory, vulnerability monitoring against it is what lets you actually answer "are we affected by this CVE" instead of guessing. Our hands-on SBOM walkthrough and CycloneDX versus SPDX comparison cover the mechanics of building that inventory for embedded firmware specifically.
Does the CRA discourage using open source at all?
No, and the regulation is explicit about this. Open source is recognised as a significant contributor to innovation in the software economy, and the steward category exists specifically so the CRA does not place a disproportionate burden on non-commercial maintainers. The obligations are aimed squarely at commercial manufacturers placing finished products on the market, not at the act of writing or contributing to open-source software. If anything, the CRA pushes commercial manufacturers to be more deliberate about which open-source components they choose and how well those components are maintained upstream, which is good practice independent of the regulation.
How does this connect to supply chain obligations more broadly?
Open-source components are one category inside a broader manufacturer duty: know what is in your product, wherever it came from, and make sure none of it introduces vulnerabilities you cannot see or fix. We cover the vendor and supply-chain side of that same obligation, including proprietary third-party components, in CRA supply chain requirements.
Where Scadable fits
Scadable builds and maintains the SBOM for your product automatically, tracks every open-source and proprietary component against live vulnerability data, and tells you the moment something in your dependency tree becomes actively exploited. You do not need to manually re-audit your open-source stack every time a new CVE drops. If your product leans heavily on open source and you want to know exactly what your CRA exposure looks like, book a walkthrough.
Last reviewed: July 1, 2026.
Frequently asked questions
Can open source software comply with the Cyber Resilience Act? Open-source software distributed outside the course of a commercial activity is not itself subject to manufacturer obligations. Compliance attaches to the commercial manufacturer who integrates that software into a product placed on the EU market, not to the upstream project.
What is an open-source software steward under the CRA? A defined category for legal entities that provide sustained support for the development of specific open-source software intended for commercial activities. Stewards carry lighter, more proportionate obligations than commercial manufacturers, focused on vulnerability handling rather than the full manufacturer requirements.
Does using open-source components make my product exempt from the CRA? No. If you integrate open-source components into a product you sell commercially, you are the manufacturer of that finished product and the CRA's obligations, secure-by-design, SBOM, vulnerability handling, patching, apply to you regardless of the license on the components inside.
Do I need an SBOM if my product is mostly open source? Yes, if anything more so. An SBOM is how you and, eventually, an assessor confirm exactly which open-source components and versions are in your product, which is the only way to know when an upstream CVE actually affects you.
Does the CRA discourage using open source software? No. The regulation explicitly recognises open source as important to the software ecosystem and structures the steward category to avoid burdening non-commercial maintainers. The obligations are aimed at commercial manufacturers who build products, not at open-source contribution itself.