Published: January 6th, 2025
Last modified: January 6th, 2025
Are you aware that the Cyber Resilience Act will require “secure by design” for all software and hardware products sold in Europe?
During the summer of 2024, the Open Regulatory Compliance Working Group hosted by the Eclipse Foundation held several webinars on the subject. One of them, “The CRA Obligations: Identifying the Relevant Obligations for the OSS Community,” is one that I think all developers should watch.
So, what is the CRA?
The CRA’s objective is to make vendors of software/hardware products take security more seriously, and this will happen by extending the CE framework.
You have the CE logo on all electrical equipment, starting with your phone charger. It certifies that the product complies with all relevant European regulations, and this will remain the same when the CRA enters into force.
The CRA also covers a product’s whole lifecycle. Manufacturers (the term the EU law uses for “vendors”) will need to provide updates for their products and report exploited vulnerabilities and security incidents.
Who will enforce the CRA rules? There will be a market surveillance body in each member state.
What is the scope of the CRA? “Everything that is directly or indirectly connectable,” including both hardware and software products and their remote processing (cloud apps) if they have it.
Some categories are out of scope:
- hobby products
- websites and web apps – NIS2 covers them
- specific exclusions that have their regulations (cars, medical..)
What would a device vendor need to do under the CRA?
They will need to do due diligence on all the components they include.
Then, for their product:
- In the general case, they will do a self-assesment
- If their product is on the list of “important” products, they will either need to follow standards or do a third-party assessment
- If their product is on the critical list, they will need to undergo a third-party assessment and possibly be certified in the future.
- FOSS (Free and Open Source Software) products do self assessments except for critical products
Vulnerability reporting and Open Source
After covering the bases of the CRA, the second part of the talk starts by discussing the vulnerability reporting of open-source components of a product.
When they discover a vulnerability in their open-source component, the manufacturer is legally obliged to notify the project’s maintainers. They also need to patch the issue in their project and provide that patch upstream. Of course, the maintainers are not obliged to integrate the fix as is.
Another topic is the definition of the roles of different parties: which organization is a manufacturer, an open-source steward, or has no specific role at all?
For the answer, see the flow chart diagram taken from the talk above.
- If you are only contributing: no specific role under the CRA (no responsibility)
- If you are providing to the public and not a commercial activity in the broad sense (example: hobby): no specific role under the CRA (no responsibility)
- If a traditional manufacturer monetizes the open-source project directly, they are the “manufacturer” under the CRA.
- If you are not directly monetizing the project but have commercial activity in the broader sense and are a legal person providing sustained support to that project, you are the “open source steward.” A typical example is open-source foundations.
- If there is a decentralized collaboration, with wider commercial activity, but no one formal organization, no specific role under the CRA (for example, multiple vendors team up together and develop software without a foundation)
What are the open source stewards?
They are supporting their open-source projects in a sustainable and long-term way. Under the CRA, there will be a specific “light-touch” regime for open-source stewards:
- They will be required to develop a cybersecurity policy.
- Collaborate with market surveillance (if they reach asking questions, for example)
- Report incidents and exploited vulnerabilities to the extent of your involvement in the development. Example: not required to report if you do not write any code and are not aware of the vulnerability, but required to report security incidents related to the hosted infrastructure
Open-source stewards might be foundations, but they also include companies that develop open-source projects that are not directly monetizing or not-for-profit entities.
The CRA timeline
- The Parliament and the Commission will confirm the final version of the CRA “after the summer” (December 2024)
- Publication in the official journal “till the end of the year” (happened in December 2024) and entry into force, starting the three-year transition period
- Publication of standardization requests, guidelines, and definitions (as of 2025, guidelines haven’t been published yet)
- A new round of consultation of the definition of the “important” and “critical” products on the website of the Commission: everyone could provide their written feedback (expected by the end of 2024, but hasn’t happened yet)
- The Commission will request product-specific standards for all “important”/”critical” categories of products.
- ENISA (the European security agency) will set up a single reporting platform (needs to be ready within 21 months): reporting obligations kick in earlier than other obligations, at 21 months from the entry into force
- All the guidance and standards will be ready within two years into the transition period (which means end of 2026)
- One year will be left for compliance after the standards are ready (end of 2026 to end of 2027)
Questions and answers
I have reordered the order of questions and reformulated them for readability.
Q: What is the appropriate due diligence? Some manufacturers are already building devices that will be put on the market in 2027.
There is no obligation only to include CRA-compatible components. Checking for the CE marking will be the best practice, but only one of the ways. Due diligence means looking into risks associated with that component, integration in the product, and the product’s environment. Based on that analysis, you must decide how far you go with the analysis. The examples mentioned are checking the changelog to see if you will get updates in the future, checking if it is actively maintained, and running static or dynamic code analysis.
Q: Are there requirements for tracking end-to-end supply chain?
Yes, you need to keep track of all components. You’re even required to generate an SBOM (Software Bill of Materials). However, you do not need to make it public (even if it is recommended). Market surveillance organisms may ask for it, and the manufacturer should use it to track vulnerabilities.
Q: Where do you find a legal definition of “commercial activity” and “monetizing”?
The CRA does not explicitly define anything but reuses the “new legislative framework” from product regulations. The Blue Guide explains those rules for physical products. The CRA also provides examples of recitals that have legal value. There will also be guidelines—the commission will give additional ones if necessary.
Q: Who decides if a legal person is a manufacturer or steward?
You decide by looking into the law.
Q: Can there be multiple stewards for the same project?
Possible. It is possible to be a manufacturer for one product and steward for another.
Q: Could you expand on “intended for commercial use”? Do you need to state what the intended use of your project is?
You only need to specify the intended purpose if the product is placed on the market—there is no need to do that for open-source projects. If it has been designed from the start as a hobby, it is not intended for commercial use, even if it has grown bigger.
Q: If you develop something, then it gets picked up for commercial activity. Are you liable?
The CRA does not establish liability, it creates obligations. There is a separate liability law, the PLD (Product Liability Directive), that was developed at the same time.
Q (follow-up): If you only develop something, do you have obligations?
No.
Q: What about a definition and use cases for remote data processing?
Remote processing is special in the CRA, the term does not exist in earlier legislation. The Commission received many questions about where data processing ends and starts. There will be more guidance on the subject.
Q: What is the role of organizations that manage packets, like Debian or FreeBSD? Can they be importers?
It depends on the distribution. If monetized, it is a product, and the entity is a manufacturer. If it is not monetized, the entity might be considered a steward. The analysis should be case-by-case.
Importers are companies that place a product on the EU market, it does not apply here.
Q (follow-up): What if the entity that packages software a non-profit?
Benjamin could not give legal advice, but he gave explanations. If the project exists and is run by volunteers building a product with a “widely commercial” nature, then the product should be considered commercial. The entity then might be regarded as a steward.
Q: If you put a project on the market using a different trademark, does it impact your classification under the CRA?
The CRA has no impact on trademarks. If you can integrate a project into your product and the trademark does not prevent it, the same CRA rules apply as in any other case.
Q: In a large corporation, distributing to another branch might trigger distribution requirements according to the copyright law. Is this also the case when placing it on the market?
Probably not, it can be a tricky legal question. In this case, there is no placing on the market. However, it might be more complex in the case of subsidiaries partially owned by the company.
Q: As a manufacturer, you need to provide a support period. How do you calculate it for software?
The CRA has the concept of “substantial modifications .”If a modification impacts the risk profile, then it is “substantial.” A substantial modification is considered a new market placement and a new product, and the clock starts ticking afresh.
The “Blue Guide” and recitals explain the idea; the Commission will also provide more guidance.
Q: Why is audio and sonar excluded in contrast to radio TX?
Both speakers needed clarification on what the question addresses (and there was no direct follow-up). The main scope of the CRA is connected or potentially connected products. An audio interface can be considered a data connection. On the requirements side, there’s no difference.
Q: Can we contact Benjamin (and the Commission) for more questions?
It is possible. It is difficult for them (the Commission personnel) to answer in writing now, but they can set up calls. They like formats like this one because they allow them to reach a wider audience.
Summary
To sum up, we have learned that:
- The CRA defines legal obligations on hardware/software products in terms of security
- The CRA applies to all products sold in Europe, no matter where they are produced or designed, nor the size of the company that produces them
- Manufacturers will have to analyze all components they use for cybersecurity risk, and provide a way to update their product; there will be also a mandatory minimal support period
- The CRA applies to all connected or potentially connectable products, not covered by other legislation.
- The CRA will apply completely by the end of 2027, with all necessary standards available one year before
Are you ready? More about the Open Regulatory Compliance Working Group and on how to participate: https://orcwg.org/participate/
Note: all images come from the presentation
Leave a Reply