Open Source Maintainers Feeling the Weight of the EU’s Cyber Resilience Act

The EU Cyber Resilience Act (CRA) doesn't fully take effect until early 2027, but open source maintainers are already feeling its gravity. On July 11, cURL creator Daniel Stenberg shared that he had received a formal request from a Fortune 500 company asking for detailed security and SBOM information about an old version of libcurl, a project he maintains as a volunteer. He has no relationship with the company and no contractual obligation to support them. Still, the request was framed as an urgent compliance need, with a two-week deadline.

The email, which Stenberg partially redacted and shared on his blog, is part of a cybersecurity risk assessment process tied directly to CRA compliance. It asked nine detailed questions about libcurl 7.87.0, a version released in December 2022, and emphasized the importance of timely cooperation. The company also assured him the information would be kept confidential.

They're asking for a fast, formal compliance response with a two-week deadline for a version of libcurl released in December 2022. That’s over two and a half years old by the time of the request. This suggests the company may not have updated its dependencies in some time, yet still expects an upstream maintainer to drop everything to support them. This kind of mismatch highlights the asymmetry in expectations between large enterprises and volunteer OSS maintainers.

Stenberg’s response was polite but firm: he referred them to wolfSSL for a commercial support contract and declined to offer free assistance. “I am not their vendor without having a more formal relationship established,” he wrote. “I am certainly not going to spend a few hours of my spare time gathering a lot of information for them for free for their commercial benefit.”

A Glimpse of What’s Coming#

While this is just one example, it illustrates a broader concern: the CRA may create ripple effects that shift compliance responsibilities onto upstream open source maintainers, many of whom are unpaid volunteers. These developers are not under contract, yet companies may start treating them as if they are required to provide audit-ready answers for enterprise use cases.

As more companies prepare for the CRA’s full implementation, similar requests are expected to become more common. That poses a significant burden for maintainers, especially those whose projects are used widely across commercial software stacks.

Open Source Ecosystem Works to Understand CRA Scope and Obligations#

The CRA introduces new obligations for "manufacturers of digital products" sold or made available in the EU, including:

• Maintaining a Software Bill of Materials (SBOM)
• Proactively monitoring for known vulnerabilities in third-party components
• Ensuring secure-by-default configurations
• Providing post-market cybersecurity support and vulnerability reporting mechanisms

For companies using open source, this means they must understand and monitor the components they rely on, which in turn is pushing them to reach out to upstream projects.

That said, much of the public guidance, including from the Open Source Security Foundation (OpenSSF), suggests that most unpaid open source maintainers are not directly subject to CRA obligations. In its brief guide for OSS developers, OpenSSF interprets the law to generally exclude individuals who contribute to others’ open source projects or who publish code without intent to commercialize it.

While the OpenSSF guidance offers a helpful summary for developers, it is not legally binding. OpenSSF did not author the CRA and cannot dictate how it will ultimately be enforced. The definitive interpretation will depend on the official text and the decisions of EU regulatory bodies.

According to the OpenSSF guide, CRA requirements are triggered when software is distributed as part of a “commercial activity.” That includes things like charging for software or services, bundling OSS into a paid product, or monetizing access. By contrast, typical community activities, like accepting donations, publishing code to a public repo, or receiving unpaid contributions, do not by themselves qualify.

However, organizations that use OSS in commercial products, whether by embedding a library like libcurl or bundling a CLI utility, must comply with the CRA. They are responsible for vulnerability monitoring, incident response, and supply chain disclosures, including due diligence on their dependencies. That’s what likely motivated the risk assessment request Stenberg received.

The Vendor Illusion#

This blurring of the lines between open source maintainers and vendors has long been a source of tension. Projects like cURL are freely available, with documentation and changelogs provided openly. But formalized security questionnaires and compliance checklists demand time, attention, and often legal caution. Maintainers may feel pressure to comply, even when they have no formal obligations.

Stenberg encouraged the company to purchase a support contract, a move likely to be echoed by other maintainers facing similar requests. But it still exposes the fundamental disconnect between the CRA's intent and the structure of open source software ecosystems.

Community Concerns and Pushback#

Organizations including the Open Source Initiative (OSI), Eclipse Foundation, and the Linux Foundation have raised concerns about the CRA's unintended consequences for open source. The fear is that well-meaning regulations could:

• Discourage maintainers from publishing code
• Create legal uncertainty around "non-commercial" development
• Incentivize companies to fork projects they can control internally

Resources like the OpenSSF’s CRA guidance have emerged to help open source contributors navigate the upcoming rules and determine whether they qualify for exemptions.

Some in the open source and consulting space have expressed concern over how CRA’s definitions, especially around “commercial activity," may affect individual maintainers who also use their own projects in paid client work. The interpretation of what qualifies as a manufacturer remains a gray area, especially for freelancers and small consultancy businesses.

Who Bears the Cost?#

At the heart of this debate is the question of who should shoulder the burden of compliance. If commercial entities benefit from open source, should they not also be responsible for meeting regulatory requirements without offloading work onto upstream maintainers?

The CRA may unintentionally highlight the fragile dependency many enterprises have on underfunded open source infrastructure. It also presents an opportunity for companies to rethink how they support the tools they rely on, not just with security fixes, but with actual investment in sustainability.

As Stenberg noted, this is probably just the first of many such requests. The real test will be how maintainers respond, and whether regulators or vendors adjust expectations before these requests overwhelm the very people building the software the internet runs on.