The European Union (EU) Cyber Resilience Act (CRA) is a law that applies to software, hardware, products containing them, and their backend services, if they are made available on the European market. The law applies regardless of where its developer(s) are located. This is a brief guide about basics of the CRA’s applicability for those who develop open source software (OSS).
Note that this guide is not legal advice, it’s just an overview to help you understand a few key CRA concepts. If you are looking for advice on your specific situation, please consult your own legal counsel or other detailed CRA guidance.
In short, if you are contributing to others’ Open Source Software (OSS) projects, or just publish your OSS code in your own repository and you are not trying to monetize it, you do not have to worry about the CRA at all. As soon as you try to monetize the software as a product (such as by trying to commercially profit from the sale or support of the software product), things change.
The European Union (EU) Cyber Resilience Act (CRA) is a law that applies to “products with digital elements” (PDEs) made available to the European single market. A PDE is defined as a “software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately.” In many cases software is a PDE. The CRA also covers the backend services to the products (these are called “remote data processing” solutions).
You may have heard things about the CRA (especially its early drafts) that made you worried. The published law is what matters, and for typical individual OSS contributors, there’s no need to panic:
Many typical activities of OSS projects aren’t considered a commercial activity under the CRA. Examples of such typical activities are: receiving financial support from manufacturers (without a profit), manufacturers contributing to its development, performing regular releases, being hosted on an open repository, accepting donations without the intention of making a profit, and being supported by a not-for-profit organization. We strongly encourage all OSS projects to develop secure software, and the CRA can be a useful guide even when CRA compliance is not required. Yet complying with the CRA isn’t required by activities like these.
If software or any other product with digital elements (PDE) is put on the market in the course of a commercial activity, the CRA does apply. Generally “commercial activity” means some attempt to monetize it. Commercial activities under the CRA include:
If you’re putting a PDE on the market in the course of a commercial activity, then you’re considered a manufacturer and the CRA applies. This is true even if the PDE is open source software. That’s not a disaster. The CRA has a set of requirements that take work to achieve, but the requirements are intended to be achievable.
Manufacturers may integrate OSS components into their product that is put on the market. The CRA does apply to manufacturers, because they are putting PDEs on the market with commercial intent. The manufacturer is responsible for all parts of the product, including components from third parties. The manufacturer must perform “due diligence” to determine what components to use, and must also report component vulnerabilities to the component maintainer and upstream fixes if they have any. Using an OSS component in a product makes the manufacturer responsible for its use. As a result, it’s expected that some OSS will be more thoroughly assessed, and it’s likely that there will be a preference for more secure OSS. Manufacturers may sometimes change how they interact with non-commercial OSS due to the CRA. So even developers not directly subject to the CRA should learn more about the CRA and work to create more secure software. These manufacturer requirements may generate more interest in your software and your practices, which may spawn requests to the project for documentation, patches, or other artifacts such as a Software Bill of Materials (SBOM).
Organizations that systematically provide sustained support for developing OSS intended for commercial activities, but don’t fill another role like “manufacturer”, may be considered “Open Source Software Stewards” under the CRA. It’s known that an organization can be a steward for one program and also a manufacturer for a different program (Benjamin Bögel, FOSDEM 2024, time 18:10). Stewards have fewer obligations than manufacturers, but they have a few obligations such as providing a coordinated vulnerability disclosure (CVD) policy, cooperating with market surveillance at their request, providing certain kinds of documentation, reporting known actively exploited vulnerabilities, notifying about severe incidents, informing impacted users, and providing mitigation. There is no requirement for an OSS project to have a steward. However, an OSS project may choose to be supported by a steward (who must then meet its obligations).
The CRA is part of a broader set of product legislation that applies to many kinds of products traded in the European Economic Area (EEA). These products must meet certain criteria, and a manufacturer has to apply CE marking confirming this, before they are allowed to be put on the market. CE stands for the French expression “Conformité Européenne,” and translates to “European Conformity”. The CRA is basically “CE marking for software” because it adds CE marking requirements for products with digital elements (including many cases of standalone software). The Blue Guide explains how EU product legislation works more generally. At the time of this writing, the Blue Guide has not been updated to reflect the CRA. Nevertheless, reading the Blue Guide can help you better understand the CRA and how it fits into European legislation. CE Marking is for commercial products.
To learn more, we encourage you to take the free express course “Understanding the EU Cyber Resilience Act (CRA) (LFEL1001)”; you can earn a digital badge by completing it. You can also see the OpenSSF EU Cyber Resilience Act (CRA) related resources. Most developers want the software they create to be secure; to learn how, we encourage you to take our free course “Developing Secure Software (LFD121)”. The Open Source Security Foundation (OpenSSF) has multiple working groups where you can discuss issues with peers. You can also gain knowledge, tools, documentation, and training to assist in making OSS more secure.
This guide was developed by the OpenSSF Global Cyber Policy Working Group (WG) CRA Readiness+Awareness Special Interest Group (SIG) and the OpenSSF Best Practices WG. David A. Wheeler led its development. Contributors include (sorted by last name): Harald Fischer, Christian “fukami” Horchert, Olle E. Johansson, Goetz Martinek, Christopher “CRob” Robinson, David A. Wheeler, Steve Winslow, and Roman Zhukov. We thank the many contributors!