Open source and the Cyber Resilience Act

The European Union's Cyber Resilience Act (CRA) has caused a stir in the software-development world. Thanks to advocacy by the Eclipse Foundation, Open Source Initiative, Linux Foundation, Mozilla, and others, open-source software projects generally have minimal requirements under the CRA — but nothing to do with law is ever quite so simple. Marta Rybczyńska spoke at Linaro Connect 2025 about the impact of the CRA on the open-source ecosystem, with an emphasis on the importance of understanding a project's role under the CRA. She later participated in a panel discussion with Joakim Bech, Kate Stewart, and Mike Bursell about how the CRA would impact embedded open-source development.

Rybczyńska is not a lawyer. She's a security professional and a developer, but "we cannot leave law to the lawyers". A company in need of legal advice should go to its lawyer; for the rest of us, we have to rely on summaries from interested non-lawyers, or our own research.

The CRA has already become law, but does not come completely into force until 2027, Rybczyńska said. Some provisions start earlier than others; as of September 2026, vendors will need to report exploited vulnerabilities. "Basically everything" is affected: any software or hardware that is or can be connected to the Internet and is sold in Europe. There are specific exceptions for web sites, for products with existing regulations, and for hobby projects (including many open-source projects). Open-source stewards, organizations that guide an open-source project but don't qualify as manufacturers, also have reduced requirements.

So, if hobby projects are an exception to the law, why does anyone without access to a corporate legal team need to care? Rybczyńska laid out two possible futures: either CRA compliance becomes another regulation for lawyers to work around with paperwork, self-assessments, and calculated risks of being caught, or software developers take the opportunity that the CRA offers to persuade companies to employ the best practices "that engineers have always wanted."

If someone is simply a developer of open-source software, which they don't monetize, they have no obligations under the CRA. But they can help vendors who do have those obligations choose real change over paperwork-only "compliance" by having a clear reporting channel for security vulnerabilities and a way to announce to users when those vulnerabilities are discovered. This helps consumers, but another provision of the law directly helps the open-source project itself. Manufacturers that monetize their products are legally responsible for all included software in their products, even if it's open source. If a manufacturer uses 1,000 open-source projects, it is responsible for fixing bugs in those 1,000 projects, Rybczyńska said.

Historically, companies have often demanded security fixes from open-source projects. The CRA inverts that relationship: companies are required to fix security problems in the open-source software they use, and report security problems to the upstream project. This obligation lasts for the entirety of the CRA's support period, five years after a consumer buys the end product. The companies are, unfortunately, not required to actually share their bug fixes (except as compelled to do so by a project's license) — but if an open-source project makes it easy to do so, they can likely be convinced to contribute back, if only so that they don't have to maintain a fix out-of-tree. [As pointed out in a comment, the CRA does actually require companies to share bug fixes with the upstream project.]

That isn't the only obligation companies have under the CRA, Rybczyńska continued. Companies will also be required to report security incidents to the government, and perform a risk analysis of their software-development process, although the CRA doesn't mandate a framework to perform that risk analysis. It does require companies to use encryption for user data, encrypted communication, and mechanisms to ensure code integrity, such as signed images, in their products.

Rybczyńska finished her talk by inviting people again to consider the two possible worlds. Open-source developers can ignore the CRA, in which case companies will likely stick to working around the CRA with paperwork, or fixing bugs without sharing. Or open-source developers can embrace the CRA, make it easy for corporate users of their software to contact them with information about vulnerabilities, cooperate with risk analyses, and receive an army of paid engineers to fix security-related bugs for them.

Discussion

Bech, an employee at Linaro, led a later panel discussion about the CRA with Rybczyńska, Stewart, and Bursell. Stewart works at the Linux Foundation on dependable embedded systems; she gave a related talk earlier in the week. Bursell serves as the executive director of the Confidential Computing Consortium. Bech opened with a simple question for Rybczyńska: "Marta, if I'm a small business, what should I do?" Her answer was: "Figure out who you are, under the CRA". Manufacturers, open-source stewards, and contributors all have different obligations, she explained. Bursell added that there are specific provisions for small businesses as well, so company size can also play a role.

"If you fancy going to sleep one night, reading the CRA is a great way to do that," he said. Rybczyńska and Stewart disagreed, saying that the law has many interesting parts. Stewart was particularly interested in the classification of operating systems as "important" components.

Bursell briefly explained about the different levels of products defined in the CRA (in paragraphs 43 through 46, primarily). By default, products can be self-certified for compliance; their manufacturers only need to provide supporting materials on request. "Important" products, a category that includes everything from baby monitors to operating systems, are held to a higher standard, and may need to have paperwork filed in advance. "Critical" products are the highest category, with additional compliance obligations. He advised people to err on the side of caution, or ask the EU for clarification if unsure about the status of a specific product.

A concern that applies regardless of product classification, however, is the mandate that companies which sell a product retain documentation about its CRA compliance for 10 years. Rybczyńska urged everyone to generate that documentation in advance and save it in a safe place; trying to come up with a software bill of materials (SBOM) at the time of a request is likely to be problematic. Stewart agreed, saying: "Yeah, don't do that."

Bech asked what kind of documentation was covered by the requirement. Rybczyńska gave a long list: processes for software development, evidence that they were followed, a product's SBOM, and a complete history of security updates for the product. She emphasized that companies should really have a complete history of security updates for their products already. "We all know many cases where something went wrong in a product after a sequence of updates; if you don't have them, you can't debug."

Stewart advised that companies should be generating a new SBOM along with each of those security updates, as well, which can help with reproducing problems. A lot of the challenges of CRA compliance will come during mergers and acquisitions, she said, when trying to reconcile processes for these things across companies. Stewart was also worried about the relationship between datasets and trained machine-learning models, which the CRA doesn't cover. Rybczyńska agreed, noting that machine-learning models are increasingly used in security-critical applications such as firewalls.

Bech asked the panel members what they thought about the requirement that companies provide security fixes for their dependencies — "won't that result in a kind of fragmented 'fixed' ecosystem?" Rybczyńska agreed that it could happen, but called it an opportunity for vendors to review their whole supply chain and minimize their dependencies, focusing on dependencies with good security policies. If a company relies on abandoned projects, she said, that's going to cause a nightmare eventually, so it's better to find that out up front. In her opinion, the next thing SBOM tooling needs is a way to track project's security policies as well as their licensing requirements.

"I'd go further," Bursell asserted. If a vendor's product relies on an open-source project, the company should be involved in the project's development, or at least pay for its support, he said. He expressed the hope that the CRA would push more companies in that direction. Bursell also wondered how much information about the software running in a product's build environment, rather than direct dependencies, the CRA requires.

Stewart answered that the CRA leaves that undefined, just requiring "an SBOM". What exactly that means is not clear, with US, German, and Japanese agencies all publishing different definitions and requirements. Bech asked what parts of the definition were missing from the CRA.

The industry currently focuses too much on documents, Stewart answered, which provide a snapshot in time. The definition of an SBOM would ideally handle keeping that information in a database. Rybczyńska added that the tooling simply isn't there yet — there are multiple SBOM standards, multiple SBOM-generating tools, and "you are expected to make sense of all of that".

One member of the audience asked whether the panelists thought that the CRA would harm open-source adoption. Stewart said that the Linux Foundation had a survey done which showed that 46% of manufacturers passively rely on upstream projects for security fixes. "The way the CRA looks at it is, the people making money should have skin in the game." Ultimately, she doesn't think the CRA will hurt open source. Bursell also suggested that if an open-source developer is worried about this, it's "a great chance to figure out who your users are".

Rybczyńska pointed out that under the CRA, open-source projects are not required to attach a "CE mark" to their project (the mark that claims compliance with the CRA's security requirements) — but nothing is stopping them from doing that paperwork voluntarily. If a project is concerned with increasing adoption, it could do the work to obtain a C mark as a marketing tactic.

The panel session ended with a few more questions about the exact scope of the CRA. The panelists clarified that it applies to "any product with a digital element", including firmware. Rybczyńska advised that if someone were really concerned about whether they could get away with not complying for a specific product, they should "speak to your lawyers, not three semi-experts".

It seems clear that the CRA is going to have an impact on the open-source ecosystem, if only because of its impact on the entire software sector. While open-source contributors don't have direct obligations under the CRA, they will still need to be aware of its implications in order to effectively guide their projects.

[Thanks to Linaro for funding my travel to Linaro Connect.]

Addendum: Videos of Rybczyńska's keynote and the panel discussion are available on YouTube, and slides for the talks are available on Linaro's website.