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 |
|---|---|---|
| No answer yet | ❓ | No answer has been drafted yet. |
| 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 process described in Annex 1 below.
Details
tmp-154. What is the Cyber Resilience Act (CRA)?
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.
Details
tmp-155. Where is the official text of the CRA?
The final text of the CRA can be found on EUR-Lex (English HTML version).
Details
tmp-10. When does the CRA enter into force and when does the regulation start to apply?
The CRA enters into force on December 11, 2024 (Article 71). The notification of conformity of assessment bodies (Chapter IV) start to apply on June 11, 2026. Reporting obligations of manufacturers (Article 14) and stewards (Article 24) start to apply on September 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
Notification of conformity of assement bodies (June 11, 2026): milestone, 2026-06-11, 5m
Reporting obligations (September 11, 2026): milestone, 2026-09-11, 5m
All other obligations (December 11, 2027): milestone, 2027-12-11, 5m
Application phase: 2026-09-11, 2029-06-30
Details
tmp-2. What kinds of products are regulated by the CRA?
The following types of product are "in scope" (i.e., their design and production may be regulated by) 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 those solutions 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.)
Details
tmp-156. What is NOT in scope of the CRA?
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.
Details
tmp-124. What criteria determine whether an open source project is in scope of the CRA?
Status: ❓ No answer yet | GitHub issue(s): #124
Details
tmp-157. 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.
Details
tmp-133a. I am worried about how the CRA might impact me, and so I am considering shutting down my open source projects. Should I do that?
The CRA should have zero or minimal impact on most open source developers, so you should probably not shut down your open source projects because of the CRA. There are several reasons for this:
First, the CRA likely does not apply to you.
- If you're just a contributor, the CRA explicitly exempts you. For more detail, see tmp-17.
- If you're a maintainer, and you do not "monetise" your FOSS codebase, the CRA explicitly exempts you. For more detail, see tmp-133b.
- If you're a maintainer, and you do monetise your FOSS codebase, you may still be exempted, depending on exactly how you are monetizing the codebase and your participation in it. For more detail, see tmp-133c.
Second, even if the CRA does ultimately apply to you, penalties for solo and small-team maintainers are unlikely to be severe. For more detail, see tmp-133d.
As a result, we would strongly urge you not to shut down any open source projects (or your participation in those projects) just because of the CRA.
Details
tmp-17. Am I subject to the CRA if I only contribute to an open source project?
No. Contributions to an open source codebase 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.
Details
tmp-133b. Am I subject to the CRA if I maintain, but do not monetise, an open source project?
If you are the maintainer of an open source codebase, and you do not monetise it, then the CRA does not require you to do anything.
The CRA applies
only in relation to products... supplied ... in the course of a commercial activity (Recital 15, emphasis added)
And it states that
the provision of ... free and open-source software that are not monetised by their manufacturers should not be considered to be a commercial activity (Recital 18, emphasis added)
Details
tmp-133c. Am I subject to the CRA if I maintain and monetise an open source project?
If you are the maintainer of an open source codebase, and you do monetise it, then the CRA may apply to you, since you may be participating in a "commercial activity".
However, there are at least two significant exceptions that may allow you to take money for your work without being subject to the CRA.
- If you monetise your software only by accepting donations that cover the "costs associated with the design, development, and provision" of the product, then the CRA says your participation is not a "commercial activity" and so it does not regulate you or your codebase. (See Recital 15 for more details.)
- If you monetise your software by charging for a security attestation programme, that may also not be a "commercial activity" for purposes of the regulation. The exact nature of that exemption is still to be determined. (See [Recital 21][] for more details.)
Details
tmp-133d. If I maintain an open source codebase, and am treated as a "manufacturer" or "steward", what penalties could I face for violating the CRA?
If you are a solo or small-team maintainer of an open source codebase, but do get treated as a manufacturer or steward for some reason (such as monetisation), you may be subject to some penalties. However, the penalties should be limited. In particular:
-
If you are regulated because you are a steward, stewards are explicitly exempted from any fines, though you may still be required to take corrective actions for any problems that are uncovered. See [Article 64][].
-
If you are regulated because you are a manufacturer, penalties must still be constrained. Specifically, all penalties must be "proportionate" ([Recital 120][]; [Article 64][]). In addition, when imposed on a natural person, the penalties must take into account "the economic situation" and "size" of the entity ([Recital 121]; [Article 64][]). As a result, while it is not formally required, most regulators will likely to request corrective action before imposing a fine.
tmp-70. I am NOT subject to the CRA, and want to make this clear to downstream users. What should I say?
Reply to their requests, stating the following:
- On the basis of Recital 18 of the Cyber Resilience Act, I do not fall within the scope of the regulation, and cannot be considered as a Manufacturer or an Open source software steward under the Cyber Resilience Act.
- On the basis of Recital 15 of the Product Liability Directive, I cannot be held liable for your use of my code.
- While I don't have obligations towards you, you may have some towards me:
- On the basis of Article 13.6 the Cyber Resilience Act, if you believe you have found a security flaw in this code, you are responsible for reporting it by following the vulnerability disclosure process here: << project link >>. You are also responsible for fixing it within your product and providing the fix upstream.
Details
tmp-1. Can an solo maintainer be considered to be an open-source software steward?
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.
🛑 CAUTION: Pending confirmation through European Commission Guidance that legal persons do not include natural persons in the context of the CRA.
Details
tmp-15. Can a loosely organized group of maintainers be considered to be an open-source software steward?
No. As defined in Article 3(14), an open-source software steward must be a legal person, which in the context of the CRA means an legal entity such as a business or nonprofit.
🛑 CAUTION: Pending confirmation through European Commission Guidance that legal persons do not include natural persons in the context of the CRA.
tmp-170. Do all open source projects have an open source software steward?
No. Most open source projects will not have a steward.
A steward must be a "legal person" (Art. 3), such as a company, and most open source projects are not supported by a company.
The stewarding organization must also have "the purpose or objective of systematically providing support on a sustained basis" (Art. 3) and their software must be "ultimately intended for commercial activities" (recital 19). Organizations who do not meet those tests will also not be considered stewards.
Details
tmp-127. What is an open-source software stewards?
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
Details
tmp-159. What are the obligations of open-source software stewards?
Open-source software steward are subject to a "light-touch and tailor-made regulatory regime" (Recital 19), defined in Article 24.
Details
tmp-11. How do open-source software stewards demonstrate that they meet their obligations?
Status: ❓ No answer yet | GitHub issue(s): #11
Details
tmp-158. What happens when an open-source software steward doesn't meet its obligations?
Status: ❓ No answer yet | GitHub issue(s): #158
Details
tmp-152. Does a steward bear the cost of translating and maintain its policy documents in many of the EU languages?
Status: 🛑 Pending Guidance | GitHub issue(s): #152
Details
tmp-59. What is a manufacturer?
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;
Details
tmp-30. Can a manufacturer also be an open-source software steward?
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.
Details
tmp-56. What is a harmonised standard and why does it matter?
A harmonised standard is a standard adopted by one of the European Standardisation Organisations (ESOs). Certain (but not all) harmonised standards are referenced in the Official Journal of the European Union by the European Commission. Harmonised standards referenced in this way provide products that conform with them a presumption of conformity with the requirements covered by those standards. Harmonised standards may be referenced with restrictions, in which case they only provide partial presumption of conformity. The presumption of conformity provided by harmonised standards referenced in the Official Journal of the European Union is why it is expected that most organisations will choose to implement such standards when they exist, to comply with the CRA.
However, not all harmonised standards are referenced. Those that are not referenced are often foundational standards upon which other standards build. In general, only the vertical (product-specific) standards are referenced, though sometimes horizontal standards that cover generic requirements may be referenced with restrictions.
The ORC WG maintains a list of harmonised standards requested by the European Commission to the ESOs.
Details
tmp-4. What is the Blue Guide?
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.
Details
tmp-57. What is the New Legislative Framework (NLF)?
Status: ❓ No answer yet | GitHub issue(s): #56
Details
tmp-55. What is a legal person?
In the context of the CRA, a legal person means an legal entity such as a business or nonprofit.
🛑 CAUTION: Pending confirmation through European Commission Guidance that legal persons do not include natural persons in the context of the CRA.
Details
tmp-72. What is a security attestation in the CRA?
Security attestations in the CRA are an optional extension that do not exist yet. They may exist in the future, should the European Commission choose to establish them, with a legislative process called a "delegated act". Until such time, any resemblence with concepts elsewhere by the name of "attestation" is coincidental and should not restrict their future design in the CRA. For example, the "Secure Software Development Attestation" as a concept in the US is unrelated to the CRA.
The following people have contributed to this document either directly or indirectly (e.g. by raising questions): Adrian O'Sullivan, Aeva Black, Alberto Pianon, Alex Lennon, Alistair Woodman, Chris Jenkins, Christopher "CRob" Robinson, Daniel Appelquist, Daniel Stenberg, Dick Brooks, Dirk-Willem van Gulik, Felix Reda, Florian Idelberger, Gesine Freund, Hermann Seuschek, Ilonka Sievers, Jakub Zelenka, Jan Westerkamp, John Ellis, Jordan Maris, Juan Rico, Lars Francke, Luis Villa, Maarten Aertsen, Marta Rybczynska, Mattias Dahlberg, Maxim Baele, Mikaël Barbero, Mike Bursell, Nils Adermann, Olle E. Johansson, Pete Allor, Piotr P. Karwasz, Poul-Henning Kamp, Ria Schalnat, Roman Zhukov, Ruth Suehle, Salve J. Nilsen, Seth Michael Larson, Simon Phipps, Stefane Fermigier, Timo Perala, Timothée Mazzucotelli, Tobie Langel, and Victor Roland.
If you have contributed to this document and aren't properly acknowledged or if you want to edit or remove your name, please let us know by opening an issue and we will fix this right away.
Maturity level statuses are assigned using the following process. All answers start with a maturity level status of "No answer yet".
flowchart TD
start[Status: No answer yet ❓]
A[Status: Draft ⚠️]
B[Status: Pending Review 👀]
C[Status: Approved ✅]
D[Status: Pending Guidance 🛑]
start -- Add draft answer --> A
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
<details>
<a name="PREVIOUS_ANCHOR_SO_WE_DONT_BREAK_EXTERNAL_REFERENCES"></a>
<summary><strong><a name="faq-tmp-GITHUB_ISSUE_ID" href="#faq-tmp-GITHUB_ISSUE_ID">tmp-GITHUB_ISSUE_ID.</a> QUESTION</strong></summary>
ANSWER
> Status: ICON [MATURITY_LEVEL][]
| GitHub issue(s): [#GITHUB_ISSUE_ID](https://github.com/orcwg/cra-hub/issues/GITHUB_ISSUE_ID)
</details><details>
<a name="PREVIOUS_ANCHOR_SO_WE_DONT_BREAK_EXTERNAL_REFERENCES"></a>
<a name="faq-tmp-GITHUB_ISSUE_ID"></a>
<summary><strong><a name="faq-FINAL_ID" href="#faq-FINAL_ID">FINAL_ID.</a> QUESTION</strong></summary>
ANSWER
</details>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 ↩