The EU Cyber Resilience Act: What It Means for Open Source Developers

The EU Cyber Resilience Act (CRA) will be fully applicable in three years, with vulnerability reporting obligations taking effect even sooner, in September 2026. For GitHub's developer policy team, the CRA has been a focal point for nearly six years, from early discussions to final implementation. The outcome, shaped with input from EU lawmakers, aims to avoid the legal uncertainty that open source projects faced under earlier drafts. Responsibility for cybersecurity now sits more clearly with the entities that have the resources to act.

Why the CRA Exists

The EU's decision to regulate software products follows well-documented failures: cheap IoT devices abused in botnets, smartphones that stop receiving security updates shortly after purchase, and apps that leak user data. These incidents ripple beyond individual consumers, enabling cyberattacks that can disrupt entire industries and public services. The CRA responds by creating cybersecurity, maintenance, and vulnerability disclosure requirements for software products sold on the EU market.

Open source is not exempt from these concerns, nor should it be. But open source thrives precisely because it is offered as-is, free to reuse, without guarantees from the community that built it. Many projects are understaffed and underresourced despite their societal value. That's why GitHub's advocacy has centered on supporting open source projects rather than over-regulating them—through initiatives like public funding programs such as Germany's Sovereign Tech Agency and the GitHub Secure Open Source Fund.

Who Falls Under the CRA

The CRA imposes obligations on software manufacturers, importers, and distributors. For individual open source contributors, the central question is whether the CRA applies at all. In many cases, it will not. But some uncertainty remains, since the EU is still drafting follow-up legislation and guidance, and courts will ultimately interpret the law.

The CRA was designed from the start to exclude free and open source software that falls outside a commercial activity. GitHub pushed for a clear definition of that term throughout the legislative process. The final text includes clarifying language that places the principal compliance burden on companies that use open source, not on the projects they depend on.

Whether your open source project is covered depends on whether the software is "made available on the market"—that is, intended for "distribution or use in the course of a commercial activity, whether in return for payment or free of charge." If not, the CRA's provisions do not apply. If you intend to monetize the software yourself, you likely qualify as a manufacturer and must meet the full requirements.

A Lighter Touch for Stewards

Organizations that support and maintain open source software intended for commercial use by others may qualify as "open source software stewards" under the CRA. This category, introduced after consultation with the open source community, covers entities like certain foundations and businesses that develop and publish free and open source software, including not-for-profits.

Stewards face limited obligations: they must establish and document a cybersecurity policy, notify authorities of actively exploited vulnerabilities in their projects, and promote information sharing about discovered vulnerabilities within the open source community. The CRA's text is explicit that stewards should be subject to a "light-touch regulatory regime," with details to be filled in by industry standards over the coming years.

Several provisions are worth careful attention when determining your status:

  • Donations: Accepting donations without profit intent is not a commercial activity. However, if manufacturers that integrate a component regularly contribute to its development or provide ongoing financial support to ensure its continuity, the recipient may qualify as a steward.
  • Development vs. supply: Providing open source software that is not monetized by its manufacturers is not considered a commercial activity.
  • Manufacturer contributions: Financial support from manufacturers or their contributions to a project's development does not, by itself, make the activity commercial.
  • Regular releases: Consistent release cadence alone does not indicate supply in the course of commercial activity.
  • Not-for-profit organizations: Development by nonprofits is not commercial, provided earnings after costs are used to achieve not-for-profit objectives.
  • Individual contributors: Natural or legal persons who contribute source code to open source products not under their responsibility are not covered by the Regulation.

Practical Steps and Ongoing Concerns

Even with these clarifications, developers may struggle to determine their obligations. Resources are emerging to help: the Eclipse ORC Working Group connects open source organizations working on CRA-related standardization, and Linux Foundation, OpenSSF, and others are co-hosting workshops and publishing guidance for stewards and manufacturers preparing for compliance.

The lighter burden on some developers does not guarantee companies won't reach out with requests about CRA compliance. Ideally, these interactions will lead to constructive partnerships where manufacturers take responsibility for improving security of the open source software they use. The CRA supports this through provisions allowing manufacturers to finance voluntary security attestation of open source software and requiring them to contribute fixes for vulnerabilities in open source components back to the original project.

Less ideally, companies may send demands to overworked maintainers who, after spending hours with lawyers, discover they have no legal obligation to assist. GitHub's policy team is engaging with the European Commission and cybersecurity agencies to help craft the guidance that will make these determinations straightforward. A particular priority is the guidance required under Article 26(2)(a) to help every open source developer assess whether they face obligations under the CRA.

The goal is rules that support open source projects rather than burden them—an approach that should yield better security outcomes and a more sustainable open source ecosystem.