This document represents a community effort to collect and answer frequently asked questions about the Cyber Resilience Act (CRA) as it relates to open source.
The purpose of this document is twofold:
- to consolidate community understanding of the CRA, and
- to outline areas of the CRA which remain unclear and would benefit from guidance from the European Commission.
Warning
Nothing contained in this document constitutes legal advice. If you have any legal questions about the CRA, you should consult with an attorney.
This is a draft document and may be updated, replaced or obsoleted at any time. It is inappropriate to cite this document as other than a work in progress. Publication of this document as a draft does not imply endorsement by the Eclipse Foundation, Open Regulatory Working Group Members, or contributors.
Open issues, pull requests, and untriagged FAQs can be found on GitHub.
Frequently asked questions which would benefit from guidance from the European Commission are indicated with the following callout:
Caution
Pending confirmation through European Commission Guidance that [REASON].
The maturity level of the answers contained in this document are indicated using the following system:
| Maturity level status | Icon | Description |
|---|---|---|
| Draft | Hasn't been reviewed by SIG. Answer may be incomplete or incorrect. | |
| Pending Review | 👀 | Ready to be reviewed by the SIG. |
| Pending Guidance | 🛑 | Identified by the SIG as requiring input from the EU Commission. |
| Approved | ✅ | Has been reviewed by the SIG. Represents community best effort to provide an actionable answer. |
Maturity level statuses are assigned using the following process. All answers start with a maturity level status of "Draft".
flowchart TD
A[Status: Draft ⚠️]
B[Status: Pending Review 👀]
C[Status: Approved ✅]
D[Status: Pending Guidance 🛑]
A -- Ready for review --> B
B --> SIG{"Passes SIG Review?"}
SIG -- YES --> Q{"Requires EU guidance?"}
SIG -- NO --> A
Q -- NO --> C
Q -- YES --> D
D -- Guidance received --> SIG
The Cyber Resilience Act (CRA) is a new EU Regulation that aims to safeguard consumers and businesses who use software or products with digital components. It creates mandatory cybersecurity requirements for manufacturers and retailers that extend throughout the product lifecycle and the whole software supply chain (including all open source dependencies and transitive dependencies) and helps consumers and business identify such products through the CE mark.
The final text of the CRA can be found on EUR-Lex (English HTML version).
The CRA enters into force on December 11, 2024. Reporting obligations of manufacturers (Article 14) start to apply on September 11, 2026. The notification of conformity of assement bodies (Chapter IV) start to apply on June 11, 2026. Everything else starts to apply on December 11, 2027.
%%{init: {'theme':'base'}}%%
gantt
title CRA Implementation Timeline
dateFormat YYYY-MM-DD
axisFormat %Y-Q%q
tickInterval 3month
Drafting phase: 2024-01-01, 2024-11-20
Publication in the Official Journal of the EU (November 20, 2024): milestone, 2024-11-20, 5m
Entry into force (December 11, 2024): milestone, 2024-12-11, 5m
Implementation phase: 2024-12-11, 3y
Reporting obligations of manufacturers (September 11, 2026): milestone, 2026-09-11, 5m
Notification of conformity of assement bodies (June 11, 2026): milestone, 2027-06-11, 5m
All other obligations (December 11, 2027): milestone, 2027-12-11, 5m
Application phase: 2026-09-11, 2029-06-30
The following types of product are in scope of the CRA:
- Hardware products (e.g. laptops, smart appliances, mobile phones, network equipment, CPUs, etc.)
- Software products (e.g. operating systems, word processing, games or mobile apps, software libraries, etc.)
- Remote data processing solutions for any of the above, as far as they are necessary for a product to perform its functions (e.g. cloud-based services that allow control of a smart lock at a distance, remote database that backs-up user preferences, etc.)
The following types of product are NOT in scope of the CRA:
- Products already covered by other regulations or directives: civil aviation equipment (2018/1139), marine equipment (2014/90), medical devices (2017/745 and 2017/746), motor vehicles (2019/2144), and software as a service (SaaS) (NIS 2)
- Products exclusively designed for national security or defence purposes
- Products specifically designed to process classified information
It is worth noting however, that the intent of the EU legislators is to harmonize the various regulations mentioned above with the CRA in the near future.
Q: Is distributing binaries or container images of an open source project considered as making it available on the market?
No. Monetization by the original manufacturer is what determines whether a product is made available on the market. As per Recital 18, merely supplying open source components isn't indicative of a commercial activity:
Furthermore, the supply of products with digital elements qualifying as free and open-source software components intended for integration by other manufacturers into their own products with digital elements should be considered to be making available on the market only if the component is monetised by its original manufacturer. […] In addition, the mere presence of regular releases should not in itself lead to the conclusion that a product with digital elements is supplied in the course of a commercial activity.
No. Contributions to an open source project are explicitely not in scope of the CRA. See Recital 18:
This Regulation does not apply to natural or legal persons who contribute with source code to products with digital elements qualifying as free and open-source software that are not under their responsibility.
Open-source software steward is a term defined in Article 3(14) of the CRA, to subject specific organisations to a subset of CRA obligations because they exist to support free and open source software that is intended for commercial activities (by others):
‘open-source software steward’ means a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products;
Recital 19 states "Open-source software stewards include certain foundations as well as entities that develop and publish free and open-source software in a business context, including not-for-profit entities." At [FOSDEM 2024][FOSDEM24], the European Commission provided three examples of entities the co-legislators had in mind 1:
- Foundations supporting specific FOSS projects
- Companies that build FOSS for their own use but make it public
- Not-for-profit entities that develop FOSS
Open-source software steward are subject to a "light-touch and tailor-made regulatory regime" (Recital 19), defined in Article 24.
No. As defined in Article 3(14), an open-source software steward must be a legal person (e.g. a company, an organization, etc.) in contrast with a natural person (i.e. a human being). The obligations of open-source software stewards described in Article 24 therefore do not apply to solo maintainers. It is worth noting however, that natural persons are subject to the same obligations as legal persons would be should they monetize their poject.
Q: Can a loosely organized group of maintainers be considered to be an open-source software steward?
In Article 3(14), the CRA defines open-source software steward as a legal person which whould exempt loosely organized groups of maintainers from the obligations of open-source software stewards. However, in certain European jurisdictions, groups of people acting in concert have been considered as a legal person in certain cases, even though their relationship wasn't formalized by creating an organization of any kind. So it is possible that in some cases, a loosely organized group of maintainers might be considered as an open-source software steward and therefore be subject to the obligations described in Article 24. It is worth noting that not complying to those obligations doesn't carry penalties as per Article 64(10)(b).
The term Manufacturer is defined in Article 3(13) of the CRA:
‘manufacturer’ means a natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under its name or trademark, whether for payment, monetisation or free of charge;
Yes, a manufacturer can also be an open-source software steward, but it cannot be both the manufacturer and open-source software steward of the same project.
The Blue Guide is one of the main reference documents of the European Commission explaining how to implement legislation based on the New Legislative Framework (NLF). Unlike the CRA, the Blue Guide does not have legal force. It predates the CRA and only discusses software as something embedded into a physical product, not as standalone. For this reason, until an updated version is available, the Blue Guide's guidance should be read in light of the CRA's wider scope and take into account the nuances introduced in the CRA for software. For example, on the concept of "commercial activity", Recital 18 CRA provides more specific guidance on "monetisation" and "non-profit organisations" than is available in the Blue Guide's "Making available on the market" section.
Footnotes
-
https://fosdem.org/2024/schedule/event/fosdem-2024-3683-the-regulators-are-coming-one-year-on/, at 18 min 10 seconds into the recording ↩