What I learned in Brussels: the Cyber Resilience Act

What I learned in Brussels: the Cyber Resilience Act
Photo by Muha Ajjan / Unsplash

Last weekend I co-organised an EU policy devroom at FOSDEM, marking the end of a wild ride in EU policy land working on the Cyber Resilience Act. In this post I want to contribute to a shared understanding of how the CRA will most likely affect developers of open source software.

by Maarten Aertsen

With the results of the negotiations (trilogue) public since December, we now know what to expect at a high level from the Cyber Resilience Act. I’ll link high-quality resources for those that want to understand what the CRA is about. I'll also tell my personal story of starting FOSS policy engagement in Brussels because of the CRA and share the lessons I learned.

This is a follow-up to a November 2022 post, which expressed concerns about unintended consequences for developers of open source software. These concerns have been heard and are being addressed in the final text.
The negotiated text discussed here is still due for a plenary vote in the European parliament, to be polished and translated, to be published in the official journal of the European Union, before 36 months to full entry into force (perhaps summer 2027). So, like my previous post, this post will be 'historical context' in due time.

Does the CRA affect me?

Benjamin Bögel (European Commission, responsible for the CRA’s implementation) returned to FOSDEM's main stage to give a 10-minute explainer of how CRA affects FOSS. I recommend watching it.

Using a flow-chart to get a rough sense

In his presentation, Benjamin uses a flow chart to help you figure out if the CRA affects you. That’s no substitute for reading the law (when it is formally published, likely in Q2 2024, don’t waste your time just yet), but it may help you to get an intuition.

Using a flow-chart to guide further reading

Seeing his flow-chart reminded me that I had made one myself while trying to wrap my head around the CRA scope, which has a bit more detail with pointers to the relevant recitals and articles:

Yes, condensing legal text into a flow chart is imprecise. If this is important to you, read the text yourself and/or get qualified assistance (ie. not from an engineer).
The above image contains an embedded XML version of the diagram that you can import into draw.io to make modifications. Contributions, corrections or other feedback is most welcome.
It would be helpful if someone made a similar diagram that maps out obligations for open-source software stewards, to similarly guide reading.

Other introduction-level resources I recommend include:

I want to learn what's next. Where do I go?

FOSDEM featured an ”EU policy devroom” this year, that I contributed to as co-organiser. The first block was dedicated to the CRA and (sadly less known) updated Product Liability Directive (PLD):

Some CRA details less frequently discussed

Manufacturers downstream will need to send fixes upstream

In my original article, I wrote about responsibilities for integrators under the CRA. Article 10(4) requires integrators 'to excercise due diligence when integrating components sourced from third parties [..] They shall ensure that such components do not compromise the security of the product [..]'.

There is now a copyleft-inspired added obligation for manufacturers that find a vulnerability in a component they use to send fixes upstream:

Where manufacturers have developed a software or hardware modification to address the vulnerability in that component, they shall share the relevant code or documentation with the person or entity manufacturing or maintaining the component, where appropriate in a machine-readable format.

This is nice.

Manufacturers can always use self-certification for FOSS

One of the biggest concerns in my November 2022 blog, was the compliance burden for so-called critical products (since renamed to important products). An exception has been introduced for manufacturers that allows for self-certification for important products, under the condition that the technical documentation is made publicly available.

Quoting a European Commission presentation at FOSDEM2024 (11min54):

When it comes to FOSS, we have a special provision in the CRA that says that irrespective of whether your product is important or not, you will always be allowed to undergo a self-assessment. You will not have to submit any FOSS that is in the scope of the CRA to a third party.
And the reason behind that is that when it comes to open source it is a transparent product and anyone including the users or integrators they can check for themselves if this product is secure. So you do not need a third-party that vouches for the product.

This seems useful. It will empower all users, not just notified bodies or economic actors with sufficient market power to inspect the security of the products they rely on. Perhaps it will incentivize some manufacturers to open up their products.

Learning FOSS policy engagement from scratch

This blog concludes a 17-month journey to understand the EU's attempt to regulate software with the CRA. I engaged in this policy process in an effort to minimise damage to the practice of free and open source software development. I looked back upon this process at FOSDEM, in a lightning talk "FOSS policy engagement: a CRA retrospective" with Enzo Ribagnac (Eclipse). It features my struggle to understand how Brussels works, roughly on a chronological timeline.

I am grateful to everyone who helped me along; it was quite the rollercoaster. Some lessons I learned:

  1. We were too late. The proposal was already out when we noticed and had to try to influence its contents after the fact. Like chasing a train that has already departed, you are much better off being at the station ahead of time, so you can get boarded before it departs. Chasing required us to spend much more effort than would have been necessary had we been involved (update: or consulted!) on time.
  2. We cannot expect the FOSS community to organise as an industry organises (in trade organisations). If it turns out that FOSS appears nicely organised to a policy maker, then they are probably not talking to the whole community but just to the industry part of it. Simon Phipps wrote about this more eloquently than I can.
  3. We need the process for the digital dossiers in the EU to change, or figure out better mechanisms to do advocacy from the FOSS community. For all the EU's digital dossiers software is relevant, and for software FOSS is relevant. In hindsight; we got lucky on this one.
  4. We should be talking more to parliament as a community; they are the people most accessible to us. On a more general note, European elections coming; they are important; please go vote if you are eligible.
  5. It turns out that even if you don’t have any EU policy experience, you can figure out the landscape and make a difference.