So, hi everyone, I hope you can hear me, I'm going to try to give a very old school
top.
Can you hear me?
I see.
So, you need to talk to the road.
Okay.
And the mic is just for all the, there's about 30 people walking you on video.
Okay.
Good morning, everyone.
My name is Philippe Modell.
I'm a policy officer in the European Commission.
I work in DG Connect in the cybersecurity policies unit.
And today I'm here to talk to you about the implementation of the Cyber Resilience Act.
So, because my slides, I couldn't get my slides to work, I'm going to try to use the board,
like old school professor.
So, the Cyber Resilience Act.
The Cyber Resilience Act came into force in December 2024, after a two and a half year process
of negotiations in which the open source community has participated to unprecedented extent.
And we're now excited to start the actual work of making this happen.
And the way we're doing that is by as much as possible setting up the conditions for stakeholders
to participate in a process of discussion of all of the relevant legal topics.
Before a show of hands does anybody not know what the Cyber Resilience Act is in this room.
Okay.
That's enough people.
So, the Cyber Resilience Act is the first European legislation, perhaps even the first global legislation,
to mandate product security requirements.
So, it's the first time that product security becomes mandatory.
And the scope is products with digital elements.
So, that includes hardware and software, also the smart products.
So, it's a sort of legal scope of a product that includes the remote data processing part,
the cloud service associated to a product.
So, of course, all of these things start to raise questions,
since it's a relatively new that regulation touches on software for instance,
or the cloud services associated to a product.
So, there's a lot of discussion.
So, there's discussions on how to cover open source.
Open source was largely excluded from scope,
but there's also other things like what does this remote data processing solutions.
What does it actually mean?
How do different companies interact when they provide a smart product?
If I'm a manufacturer of the hardware,
but I'm contracting the software as a service or platform as a service with Amazon or Microsoft or anyone else.
And how do we contractually arrange compliance to cybersecurity requirements that are horizontal?
So, this is really the main thing about the CRA.
It's horizontal cybersecurity requirements.
There's about 12 of them just for the products,
and then another 10 or so for vulnerability handling.
And they, in theory, apply in a risk-based way to any product.
So, that means risk-based is really important.
If you have a risk, then you're going to have to try to find a way for the essential requirement to cover that risk.
Even if you can't find the indisensual requirements,
you're still going to have to cover that risk, but really the essential requirements.
Really the essential requirements are meant to be a way of sort of focusing the attention of manufacturers that they really have to look at this requirements and see how can I apply it.
So, this becomes really kind of both the theoretical and the practical question.
And the way we're trying to help everyone to do that is with this figure called harmonized standards.
So, the CRA is, as I said, EU product legislation, and EU product legislation has been around for some 40 or 50 years.
It underpins the EU single market, and it uses this legal concept of harmonized standards.
Harmonized standards are regular European standards, but they have been published.
The reference has been published in the official journal of the EU.
And that's because they should only be published, so there should only be harmonized when they meet the requirements of the legislation.
So, of course, it becomes crucial to understand, first of all, what are the requirements, and then how do we meet them?
And I think one of the key things that we've been working on already for a year and a half, almost two years on this standardization process,
has been to try to clarify what does it mean to meet these essential requirements, the cybersecurity requirements.
And a lot of it revolves around identifying risks, even a use case or the legislation calls it the intended purpose,
the reasonably foreseeable use, and then defining mitigations for those risks.
And if you can define a mitigation that everyone agrees is sort of the state of the art mitigation, then we're happy.
We can say yes for this risk, there's that mitigation, and if you apply that standard or that mitigation, you receive a presumption of conformity.
And the presumption of conformity makes your life a lot easier, because you can just claim very easily, I comply with the CRA, and nobody's really going to argue about that,
unless there's a problem in the future that could happen, but in principle, the presumption of conformity as a legal figure makes it a lot easier to comply.
So we've been trying to engage with standardization bodies in order to push out these standards, that meet state of the art,
and as open source practitioners, you probably know that the work that's done by the open source community is often state of the art.
So a lot of this also are interesting engaging with open source is really to see, you know, you are the real experts out there,
so please come and participate in this process, so we can all learn from you, and we can all make the market a little bit more transparent
when it comes to the cybersecurity practices. This is one of my main interests in engaging with the open source community.
Okay, but there are problems in the open source participation, and we've been trying to address those in a number of different ways,
by sort of supporting the engagement of the community, several different communities.
So we had to get some action grants to the standardization bodies, the European standardization bodies,
since senilek and Etsy, and as a requirement for that money to be given to them, they have to agree to hold additional external stakeholder consultations,
and those are going to be happening, by the way, I'm going to just put this here, from April May onwards.
So if you wish to participate in this process, you can, and you should get ready because it's going to happen quite soon.
First drafts should be publicly discussed from April or May onwards.
And then it's going to be relatively short window, by the way, because it's only until depending on the standard, so we have two types of standards for horizontals.
That means probably until July August, 2025, for the verticals that's products, specific standards, probably until October, November.
Thank you for the question. So the way that the standardization work is set up, that we have proposed it to the experts, and this is sort of the architecture that is underpinning all of this work, is that we have two types of standards.
The horizontal standards kind of a framework approach, the sort of very product diagnostic, very abstract statements about what does it mean to have a risk-based approach, or risk management in your product security lifecycle that we call that the type A standard, by the way.
And that's the sort of the tip of the pyramid.
And then you have sort of the product diagnostic description of different security mechanisms like access control, encryption, or the vulnerability handling.
We call those the type B standards, and these in principle could be used for any product, or for large families of products.
So if it's just for a large family, we call it a broad vertical, so I could put that here, a broad vertical.
And then finally you have the type C standards, this is going to be the really product specific standards, and it's going to be like this open ended.
It's open ended pyramid that can be filled with type C standards, I put the vertical lines to make the visual point.
So these are going to cover specific product types, or even specific use cases of products, so that you can really easily identify what are the risks and state what are the mitigations that you propose.
And again, if there's a consensus process around defining the risks, defining the mitigations, everybody agrees it's the state of the art.
We're good to go, we can have presumption of conformity, make compliance easy for everyone.
And as I say, so this is the sort of horizontal framework, and then here would be the verticals.
So the idea is that you can just use the horizontal framework to produce more verticals, meaning for more product types, or for more use cases.
Over time, you can add more verticals to this library of standards to make it easier and easier and easier to comply, because the scope of use cases and products that are covered will grow with time.
So the idea is that this will become a kind of an ecosystem of product security standards, this already exists by the way for machine safety.
There's currently something that they also have a type A, they have some 200 type B standards for different safety mechanisms, product diagnostic, and then they have some 600 working standards that are used for product compliance out there in the market.
And so the idea is that we could we could arrive at somewhere similar over time, but we started with the first standardization request with 25 products.
These are the important and critical products are identified in the cyber resilience act as important and critical, and this is really because in the CRA being an important or critical product means that you need to go to a third party for your conformity assessment.
We know that this kind could be a bit of a bottleneck, right? Companies are used to having their internal processes, but then if they have to go to an external to have it all checked, this can take some extra time.
And so to facilitate that we're really prioritizing having type C standards for those product types, product categories, but again over time this would be open.
Good, so that's the standardization track of this implementation of the CRA.
Okay, so there's a few other things we're also doing, how times are ready up. So we have guidance and I just want you to know that there's really really interested to hear the open source communities voice in all of this, there's going to be guidance about a lot of these topics.
In general, if you know about this CRA or discussions on this CRA and you think, you know, there's some concepts here that are really not well explained, well we hope to be able to come out with guidance to clarify those things.
It's really important that we can engage constructively in dialogue, because we want to hear your questions, we want to hear your proposed answers to them.
We want to find out like through a process of societal consensus building, what should be good clarifications to give to these questions.
That's going to be the guidance. Then there's a number of other implementation steps for going through, and basically they're broadly open, so that you have this better regulation process, we're always we have to consult stakeholders, there's always public consultation.
So just wanted to flag to you guys, if anybody wants to get involved in this, I really recommend you to get involved, it's quite exciting. Again, first time that software is being kind of regulated at least in the product security side.
So a lot of stuff happening, we need to make it good, and I think we count on the engagement of stakeholders to make that happen. So thanks very much.