The Cyber Resilience Act in practice: One regulation, many ecosystems

This talk focuses on the implementation of the Cyber Resilience Act (CRA) and its implications for cybersecurity across various sectors in Europe. The speaker emphasizes the importance of collaboration among policymakers, industry leaders, and open-source communities to successfully translate the CRA into actionable strategies. Key challenges highlighted include the long lifecycles of products in sectors like rail transport, the complexity of existing systems, and the need to prioritize practical guidance for compliance. The discussion also addresses the role of open-source software, the necessity of industry readiness, and the urgency to establish conformity assessment bodies. Overall, the session aims to foster a collective approach towards building a safer digital landscape in Europe under the CRA.

[music] >> For our final keynote here in Brussels, we wanted to bring together a diverse panel of experts to discuss the practicalities of the Cyber Resilience Act. The CRA is set to transform how cybersecurity is approached across Europe, but truly I think it's not just across Europe, but because it's Europe, the leading market, we will see other countries and other regions following these regulations because the Cyber

Resilience Act tries to solve something which is good, building more secure products. Um So, what does it mean in practice? So, you have heard about maybe have joined open uh community for compliance sessions. What does it mean in detail in the practical What What does it mean for organizations to be compliant with Cyber Resilience Act? From policymakers to industry leaders and open source communities, implementing the CRA

requires aligning very different ecosystems, each with its own realities and challenges. So, let's explore together how we are moving from policy to practice, what challenges lies ahead, and how collaboration across stakeholders will be the key for making European's digital landscape more secure and resilient. Please help me in welcoming on stage Maika Föhrenbach from the European Commission. Maika. I think it's Maika, not Maike. Sorry for that. Um

John Klykens from the Belgium Markets Authority. >> [applause] >> Lola Fernandez from Knorr-Bremse. Mike Milinkovich, the executive director of the Eclipse Foundation. >> And last but not least, my colleague Juan who will moderate that panel. Juan, take it from here. >> I don't know what to Thank you, Michael, for the introduction. Yes, Michael said we are going to explore how we can further collaborate on on the

CRA. We have gone in the last couple of years through a list of challenges, issues, a cooperation as well. And yeah, today we work we want to explore how how we can move forward, how we can take the CRA from nice conceptual thing into a success improving the security posture of everything that is done in in Europe. And yeah, I would start with Michael because the Commission

has already done a significant work launching the FAQ, the CRA website, yeah, public consultations. A lot of different activities trying to target all the stakeholders that are impacted by by the CRA. And yeah, I want to know from from your perspective given the situation that we have today, what are the key priorities that yeah, we need to ensure to translate this consistent this situation into into a

consistent and and workable implementation across all different sectors. >> Yes, thanks a lot for the question and very much looking forward to the interaction today on on the panel. So, obviously indeed the Commission has has done a lot, but implementation of the CRA is a multi-stakeholder effort. So, obviously we need to to work closely together with the member states, with with the industry, with the open community,

also with our agency ENISA. So, it's truly a joint effort. In terms of the the role of the European Commission, so one of the main milestones we are we are looking now is indeed the finalization of a first package of guidance that is really meant to address some of the practical challenges that you know we heard from from different sectors and communities. So the public consultation has

closed on 13th of April. The guidance the draft guidance is still online if you want to to to continue reading it and we are now processing all the comments received and seeing you know what are the areas where further clarifications are needed. So for instance one of one of the areas that stands out of the public consultation is the concept of substantial modification and the relationship for

instance to the support period. So just to give one example where indeed we we will we will reflect further upon. And we we think that obviously there's still a lot of work to do for us. So we have now we are working on the first guidance package but during the second half of of the year we also envisage that there will be more guidance coming for instance

also addressing the interplay with other legislations. We discussed a lot about AI this morning and the interplay with the AI Act for instance for high high risk AI system is is still an important question also where we where we are trying to provide further clarifications on. What we expect also from others and obviously where we can kind of play a bit a driving structuring role but you

know the the work obviously is impossible to to be done alone is first on conformity assessment where member states have an absolutely crucial role to play also in ensuring that sufficient conformity assessment bodies will be available before the end of the year. Second I would mention a where we need all the industry and also open source community to engage in making sure that the standards will not

only be timely available but also of good quality and practicable for being implemented for for the different sectors. But of course there's not only standards. So I think another area where we really need the communities to engage is to make available technical guidance, tools to facilitate you know implementing the security by design approaches and we already mentioned the great work done also by Eclipse Foundation on on

the open compliance group where indeed you know material is made available also for open source community and everyone to better get acquainted with the CRA. We have different sectoral associations who have come out also now UNIFE with a practical guide for the CRA. And and ENISA is also now conducting a public consultation on a security by design playbook. So I think all these tools I mean that

are maybe more in a way grassroots projects are equally important to get everyone on board on on the CRA. And lastly I also wanted to mention the supply chain cooperation and of course manufacturers have co-obligations under the CRA but the CRA is also about open source of course with the different regimes and many open source projects are not covered as such by by the CRA but the

CRA has direct incentives to and maintain important open source projects. I mean, 99% of products are open source, so this cooperation with the open source community is absolutely crucial. So, we also want to prioritize tools like the voluntary attestation for open source components and to really, you know, incentivize this transparency and and cooperation across across the supply chain. >> Good points. Yeah, you mentioned the role of

open source, of course, and I think we are pretty good engaging with the IT industry. But, we have the rail sector, which is a completely different space in which we are not that good in in terms of engagement. We know they have their challenges. We have spoken several times with some of the members of UNIFE. And, Lola, I want to know in in the rail sector, where

safety, legacy systems, and long life cycle play a major role, where do you see the first practical challenges when translating CER requirements into operational practices? >> Thank you for the question. Um Um I would like to highlight maybe three primary practical challenges. Indeed, life cycles are very long in in rail, but it is not only the time that the infrastructure of or the trains are in operation.

It is also the time that it takes uh from the start of a project. The project is start with a request for proposals from an asset owner. Then, the project is awarded and the design starts. Trains or infrastructure systems are tested, validated. They all go through homologation. So, until they get into operation, it might take up to a decade. So, current projects uh were contracted and designed

years ago, and they are going to be delivered in batches or in units years after December 2027. And, those projects were designed and the specifications were frozen years ago when the CRA was not accounted for. The second challenge would be the complexity of the systems and the complexity of the supply chain. If we are talking about the train at the end of the day a PDE for

us could be up to a train or a complete interlocking system. This is not a single device. This is a massive integration of hundreds of of devices structured in different subsystems linked together. Most of them are designed according railway specific regulations and standards for hardware and for software. Most of them are safety related. So that means having their own uh homologation process as I said before and

then many of them are tailor-made. And this means that the intended purpose of those PDEs is just to work for that specific project. They are not like commercial off-the-shelf uh components. And maybe the third is interoperability in This is not only the interoperability that is required for trains to run through different European countries. It is also the interoperability with legacy systems or with pre-existing infrastructure which might

require to yeah, maybe not being able to be fully compliant with all the CRA essential requirements. >> Good. Thank you. Um Mike Mike I said before that open source somehow present in some products. Um yeah, but the way the different industries interact with open source is completely different. There is a huge diversity in how companies get engaged in projects, how they use the technology, they take it.

And I wonder one of the questions I have is where do you see the main challenges in aligning the CRA framework with how software is actually developed and maintained. >> Uh where do I start? there's there's I'm going to touch on a couple of different things. Not necessarily like sort of somewhat disjoint but in terms of the way the CRA is rolling there's still uh Um Mike

also mentioned standards and simple fact of the matter is they're not done. >> They're coming. >> Where's my freaking standards? >> [laughter] >> It's it's and and I think but I know they're coming. >> [snorts] >> Um >> Coming. >> Let's just say they could be faster. They and that's that's ultimately going to be a problem because there's a lot of things which are awaiting those Uh

you know for example attestations and all of the other things that have to come together. And it's you know we're we're choreographing a a very complex dance that's going over a couple of years of work. Uh and [clears throat] if you know one one key element is out of step with the rest it it makes everything makes everything a lot harder. Uh so that's that's one this

one thing is just cuz they implement this The other second point I want to make is that um and it again it touches on attestations a little bit but there's still some things in terms of guidance that are a little bit unclear. So the you know the CRA talks about open source software stewards. Um they're now at the first time that that that role has been recognized

in regulation. Um are software stewards an economic actor or a non-economic actor? Uh and you know I think we would all people those of us who think of ourselves as stewards think of ourselves as we're not in the business of placing products on the market. We're not an economic actor, and yet we're seeing in some early drafts of national national laws implementing the CRA, fines for open

source software stewards that would be relevant only if we were an economic actor. Um so, I think some clarity that the role of stewards as a that we have a role to play in the ecosystem. Um but if we as stewards, as non-profit stewards in particular, are being forced to take on liability, then that's a really fundamental change to the to the equation. And somewhat related, you

know, voluntary attestations from open source projects are only going to be forthcoming if it is clear that they do not incur liability. >> Yeah. >> Uh so, if a if you want maintainers to do the attestations that the manufacturers need, and there's even the slightest hint that in doing so they're taking on liability, you're not going to get them. It's that simple. Uh so, I think you

know, some clear those are some very very fundamental clarifications that I think need to happen. fundamentally, and it's my last point is we need to pick up the pace somehow. I mean, everybody I know I know Juan and the team and everybody that's involved in ORC are working fast and furious. Um but December 2027 is not that far away, and one of the things that concerns me

the most is that we have this somewhat odd situation at the moment where I actually think the people in the open source community at large know more about the CRA and are more con- convicted in terms of doing the things that are necessary to implement the CRA than the manufacturers are because when I go to talk to manufacturers they're like ah 2027 and that's the compliance department's

problem and the GDPR really wasn't that tough. It's like how bad could this be? Right? And in my my humble opinion if you're a manufacturer and you're not like already you know, neck deep in implementing the CRA you're late. Um there is no sense of urgency in industry that I can discern that matches the sense of urgency in the open source community. And I think that's like

that is the elephant in the room because if the manufacturers don't move um there's really nothing that we can do in the open source community that's going to fix the problem that the CRA simply it can't be implemented unless the manufacturers conform and the right now there's no sense of urgency. >> Thank you Mike. Um Johan Mike mentioned about the role of the member states and yeah

I wonder from from your perspective how do you approach ensuring a consistent interpretation and enforcement of the CRA especially given the the diversity of products and and technologies that are impacted by the >> I think we we face a number of challenges throughout the whole spectrum of collaboration. I think first of all the approach to the CRA at the scope of the CRA is that big and

sorry is that holistic that I like it a lot. In a way it is simplified legislation because it sets a common target. On the other hand it complicates a number of translations into the technical aspects. Uh you indicate that some of the guidance is not sufficient. We actively collaborate with manufacturers that are fully aware and fully busy with the CRA implementation and based on that we see

that uh some of the horizontal standards that are developed are very valuable, but there's still remaining gap perceived by the manufacturers. They say, "Tell me what to do and I'll do it." >> Mhm. >> So, this is also one of the reasons why we together with not not alone, together with our German colleagues are building a voluntary IoT scheme for the default category to help them. Um

so, this is part of the the exercises that we try to do as regulators because as a regulator, you can add a layer of trust to a lot of the activities which are initiated. And we collaborate on that with with every community. a specific difficulty on bringing things into practice is that throughout the outline of the CRA, we use the framework of safety regulation with the blue

guide, with all the all the elements, and we translated that into security. And safety and security are different. Uh and where I see the the major difference in is that when you put a safe product on the market, it remains safe. When you put a secure your digital you're quite sure that it won't stay secure. So, on vulnerability management, we still have a lot to learn, a

lot to go, and I think that's where the open source community really plays a crucial role because when I talk to manufacturers, there's practically no software anymore available that doesn't contain some uh of open source. So, we have to build trust within the complete chain. >> And that process we're very far from that. And that's not a deadline for December 27. That's a deadline for September >>

this year. >> Am I right, Mike? So, that's yesterday. Um and that's my most worrying part. But we have and with that I'm going to add, we have one crucial advantage compared to the safety environment. In security, we only have one adversary. That's a cyber criminal. And we can start collaborating, and we can also start regulating from the principle that all others are our partners. And that's

a that's a crucial difference with a lot of other domains. And we have to explore that, and that's the way in which we collaborate with all the European level to to business level. >> I just want to point out that I there's a uh new project at the Eclipse Foundation called the Trustable Software Framework uh that I think you would find very illuminating uh because you actually

just mentioned the word trust. You like you mentioned security, safety, trust, and and uh basically the Trustable Software Framework is exactly about that. And and but one thing I'll you mentioned um I think I I think your exact words was, you know, when you when deploy a safe product, it stays safe. Um I actually think that that's given the fact that uh all products, pretty much all

products today, contain software, whether it's proprietary or open source or a mix of the both. Um I I believe that the assumption that that that a project stays safe is no longer true. Uh because because of the security implications. And we have this So, like one of my all-time favorite sayings is there are no solutions, there are only trade-offs. And security and safety is once upon a

time they were isolated regimes that were quite independent and siloed from one another by design. It made point It made It made sense at a point in history. But now safety and security are effectively two dials or knobs that you you have to trade off because if you lock down a system to keep it safe forever as as you know as the norm has been the norm

for a long time, um then you're probably threatening the security of the of the system over time. And that And ultimately if a system becomes insecure, it's going to become unsafe. You can have You can have safety You can You can have security without safety, but you cannot have it the other way around. >> You You You have mentioned a couple of things that are quite interesting.

The first one, of course, is the deadlines. We are really close to everything. And most of the people is trying to do the right thing. And my question is maybe for Maika, Johan, from from an authority point of view, how a good implementation would look like? Because I guess that we are in the time of starting with the trade-offs. And what are the key aspects that should

be prioritized or how companies can can get prepared for for being compliant in time? No, things I I I really like the this this this question because obviously um there is a lot to be done in a in a limited time. And um I think um yeah, we also need to see the the CRA implementation as an iterative process, meaning that we have to start from somewhere

and probably it's not going to be perfect in December 2027. And obviously, there's a lot at stake and we understand that manufacturers are concerned about fines, their liability. But the message we we try to bring and I think member states as a market surveillance authorities also support support message is that the CRA is fundamentally about being honest about your risks and about mitigating your risks and the

fact that risk transfer is no longer a business strategy as such. So, the manufacturer has to to show that assessing the risks, mitigating the risks, monitoring the risks throughout the the life cycle and of course vulnerability handling management is is a crucial part of that. So, I think it's it's really not necessarily trying and probably it's easy for me to say, but not trying to to reinvent

the wheel, but sometimes also starting from you know, existing security standards, practices, certification that you also know. And of course, standards will gradually be available and for many standards actually also drafts, you know, can can already been either publicly accessed or via national standardization organizations. But there is already in a way a lot of material out there to start the the compliance work and indeed it's absolutely

urgent to define your your your compliance strategy now. So, we cannot afford to wait for for final standards and I think this brings me a bit also to a you know what type of maybe trade-offs or we need to to to consider in order you know to get on on track for for the CRA. And there is a real sense of urgency to do so. I think

every day we are we are reminded about how critical software software's in our supply chain. So some of the trade-off is for instance and we are discussing that with the member states is to start accreditation of conformity assessment bodies without having necessarily final standards available. So we are discussing of course you know what what can be the requirements and making you know alternative guidance available also to

the national accreditation bodies so that they can start the work with a fair degree of of legal certainty. Also in terms of addressing some of the practical challenges that were mentioned by the railway sectors and also by other sectors like how does the CRA applies to legacy system legacy products. Here also in the guidance we have tried I don't I don't know if I should say flexibility

but at least to be you know pragmatic about what how the the obligations of the CRA would translate to to to to certain sectors. And we don't want to have supply chain disruptions obviously so there is I think a genuine effort to to address you know some some challenges faced faced by by certain sectors and really support them in the implementation path and I think member states

are also playing a crucial crucial role in in there. So I think all that uh should also show to the manufacturers, to the community, um that uh you know, it's not about uh being uh perfect uh in terms of your security practice from day one, but actually showing an honest effort uh that uh that you are uh that you are embracing uh the security by design um

uh culture. >> Still want to It's not all good news. I I'm going to contradict Michael a little bit on this topic. Um She talked about getting the uh accredited uh bodies. Well, let this be me a little bit my field of expertise for the last 25 years. You won't have them. Uh why? And because the standards are crucial, a crucial element to reach to the accredited

bodies, but next to that, when you're not talking about testing or inspection, but you're talking about product certification, you also need a scheme. And once you have a scheme, you can start the accreditation process of an accreditation body. And that body that process when it goes swift and when the uh certification body is prepared, it takes half a year. if we don't have it now, it will

not be here by the end of this year. Uh and that's just looking at the past and knowing that they the the accreditation world will will Well, it's not just the standard. The standard has to fulfill the accreditation requirements. It has to be reproducible. It has to have have some some outcomes. So, there are still a couple of challenges, but what I'm certainly will join my account

is that it is a journey. And we have to start. And we are starting as fast as we can, and we are jointly working on that. Um so, not doing anything that will lead into into an issue once once we reach uh full support. And to react on that, when you talk about well, I'm in Belgium the one that's uh has a sanctioning uh authority for a

number of these elements. When you think about the sanctioning process, you always take all the considerations into account. You take a look at proportionality. You take a look at the impact. what was your personal gain? What is your personal loss in being non-compliant? When you look at all those elements, I think this is also something that will gradually start. And where and that's a little bit a

Belgian position, but that's at least my conviction is that every euro that goes to a sanction and that didn't got a chance for remediation is a euro that doesn't go to cybersecurity. we're ready to play the game. We're ready to play along. Uh you have my trust. Make sure you don't lose >> It would It's nice you mentioned the the fact that CRA is a journey. I

remember when we started uh late 2024 that every presentation about the CRA is was like you should start yesterday. We are still at the same uh stage. Um >> But many are starting. I think There is a There is a big momentum, and uh we see that uh even in some sectors uh for instance uh if I can mention the the semiconductor sector because you you might

have also heard about you know the challenges and concerns there. We actually now see some of these industry promoting that they're actually on track, that they're actually getting compliant with the CRA. And of course, the discussions are not over, concerns remain, but I think well, I hope at least that there's a bit of of the of a shift in in thinking about the the CRA, you know.

>> No, indeed, that that was my question to Lola and Mike. I think what is super clear now is the need of cooperation. There are gaps that are well identified. And actually, what we need is to promote this cooperation to happen. So, Lola, from from your point of view, how we can improve that that part? >> Okay. Well, I think that CRA, at least in our sector,

has been a catalyst for a more mature conversation on security. And one example is Mike had mentioned before. Last Monday, the railway sector with UNIFE, UITP, CER, and the >> [clears throat] >> ERTMS user group has launched a guidance on the application of the CRA to the railway sector for main lines and public transport. this has been a collaboration effort because we were the the asset owners,

the infrastructure managers, and the public transport authorities and operators. this guidance is it advocates for a progressive and pragmatic approach to implement the CRA based on the risk assessment, especially for these projects I told you before that are still ongoing and will be in the around 2027. through the risk assessment, we determine what could be the needs to be secure compliant system level, even if integrate these

legacy products, or we need to interface uh other systems that may prevent uh the the compliance to all of the requirements, and then define um additional countermeasures. Uh it also recognizes the B2B context and the need for a mutual agreement, which is not a transfer of risk. It's just having a good understanding of the security context and the operational environment, because on the one hand, suppliers need

to understand what capabilities are provided by a by the upper system they're going to be integrated in. From the other side, um suppliers need to communicate to the acquirer what might be the residual risk, and what uh we call them security related application conditions, so what uh measures they need to take when a system cannot fulfill everything. And uh we also think that this is a good

opportunity to establish some uh procedures in the B2B context for SBOM and vulnerability um disclosure that brings uh true value, operational value, and enable real-time monitoring. We also think we need to engage with the notified bodies and the uh MSAs, um so market surveillance authorities, uh to better explain what are the differences between uh consumer and B2C and this B2B context with everything that we've been discussing

before. And uh we also recognize that uh we need to uh all the big players in the in the railway industry, who are also using open source, maybe not as much as in other industries, but we also use it. We need to provide funding to the open source as to what uh in the in the railway there are also a lot of small uh medium companies who

might not have the financial muscle to to fund. Maybe they can collaborate technically uh by providing fixes fixes upstream, but they cannot uh fund. So, this is the role for uh big integrators, big manufacturers, and even the the operators. >> Yeah. Johan and I will ask because we are getting close to the final of the panel a final statement from all. >> Just very short. I think

on the railway sector this is a very nice example because bringing security into the railway sector the CRA will play an important role which will only gradually grow for the coming 20 to 30 years. But uh the combination with NIS2 which is also of application to the railway delivers us also the insight on uh the risk factors and and the the the elements that have to be

uh integrated into that process. And I think we cannot look at CRA as a standalone legislation. We have to look at it at an ecosystem uh where all these systems interact and where we understand the needs and we tailor what we do to where the needs are. >> Any final thoughts? >> Um from my perspective uh the next So, I I guess my closing thought is the

next 18 months is going to be a one heck of a ride. Um and I think that there's so many different moving parts that have to come together uh all at once. I think that uh from the perspective of the open source my fear and this has been around for a while is my fear is what's going to happen is sometime I know between now and the

middle of 2027 open source projects and open source software stewards are going to be literally inundated with requests and demands of you know very you know, some will be worried worded nicely. Some of them will be like effectively legal demand letters. And we we've experienced this like when the log for shell vulnerability happens. Right? We had, you know, so many emails show up in our inbox where

like we demand that you tell us and we're like we've never heard of you and you're not a customer. Um, and you're or not a member. And and it's just like the everything that we can do to set expectations and automate those flows uh so that feeling from the open source community at large is not one of being overwhelmed um is I think is going to be

really really key. Um, because if you think about it, we've gone the open source community has gone 20 30 years depending on how you want to count um where the manufacturers that used our open source technologies in their products never talked to us. Right? They just thanks for all the free stuff suckers. We're going to build a product. Right? And now they have a legal obligation to

pay attention to the upstream projects that they rely upon. And I think what's going to happen is it's like it's going to flip a bit to we don't care to we want to know everything about you. Right? Um, and that's going uh that's going to be um let's just call it that's going to be fun. >> Where where do you think how this discussion will take place?

I mean indeed I think now there are two communities who will, you know, communicate differently uh with each other. Do you think the discussions about the for instance the voluntary attestation would be one uh channel to actually, you know, have this discussion on how you would how you will cooperate >> [sighs] >> Oh, we're already at time but like uh I have like experience that we've had

in the past. It's like it's really it's really super interesting. Sometimes we'll get an email like let's just stick with the log for shell example, right? We get an email saying hi, you know, we use this Eclipse project. We would really like to know if you could help us out to understand what's in there and then the other one, you know, signed by the general counsel. We

demand that by this day you tell us this, right? And and sort of like and and so there's this sort of, you know, dimensions set of dimensions of responses and I think one of the things that we need to do is to a certain degree is train the manufacturers and their compliance departments how to be nice. humans being humans, my expectations are low. >> I think this

is a perfect way of so I want to thank you the four of you for sharing with us your your thoughts your views of such an important topic for all of us and yeah, thank you very much. >> Thank you. >> [music]