WEBVTT 00:00.000 --> 00:10.560 Good morning, everyone. My name is Philippe Modell. I'm a policy officer in the European 00:10.560 --> 00:15.760 Commission. I work in DG Connect in the cybersecurity policies unit. And today I'm here 00:15.760 --> 00:21.200 to talk to you about the implementation of the Cyber Resilience Act. So, because my slides, 00:21.200 --> 00:26.880 I couldn't get my slides to work, I'm going to try to use the board, like old school professor. 00:26.880 --> 00:36.480 So, the Cyber Resilience Act. So, the Cyber Resilience Act came into force in December 00:36.480 --> 00:42.480 2024, after a two and a half year process of negotiations in which the open source community 00:42.480 --> 00:48.640 has participated to unprecedented extent. And we're now excited to start the actual work of making 00:48.640 --> 00:57.520 this happen. And the way we're doing that is by as much as possible setting up the conditions 00:57.520 --> 01:03.920 for stakeholders to participate in a process of discussion of all of the relevant legal topics. 01:05.440 --> 01:10.560 Before, a show of hands does anybody not know what the Cyber Resilience Act is in this room? 01:11.760 --> 01:17.200 Okay, okay, that's enough people. So, the Cyber Resilience Act is the first European legislation 01:17.200 --> 01:23.280 perhaps even the first global legislation to mandate product security requirements. So, it's the 01:23.280 --> 01:30.960 first time that product security becomes mandatory. And the scope is products with digital elements. 01:30.960 --> 01:37.360 So, that includes hardware and software. Also, the smart products. So, it's a sort of legal scope 01:37.360 --> 01:43.760 of a product that includes the remote data processing part, the cloud service associated to a product. 01:43.760 --> 01:48.480 So, of course, all of these things start to raise questions since it's a relatively new 01:48.480 --> 01:55.360 that regulation touches on software for instance or the cloud services associated to a product. 01:55.360 --> 02:00.560 So, there's a lot of discussions. So, there's discussions on how to cover open source, 02:00.560 --> 02:04.560 open source was largely excluded from scope. But there's also other things like 02:04.560 --> 02:08.880 what does this remote data processing solutions, what does it actually mean, 02:08.880 --> 02:14.480 how do different companies interact when they provide a smart product, 02:14.480 --> 02:20.800 if I'm a manufacturer of the hardware, but I'm contracting the software service or platform 02:20.800 --> 02:26.960 as a service with Amazon or Microsoft or anyone else. And how do we contractually arrange 02:26.960 --> 02:33.040 compliance to cybersecurity requirements that are horizontal? So, this is really the main thing 02:33.120 --> 02:40.800 about the CRA. It's horizontal cybersecurity requirements. There's about 12 of them just for 02:40.800 --> 02:46.720 the products and then another 10 or so four vulnerability handling. And they, in theory, apply 02:46.720 --> 02:52.160 in a risk-based way to any product. So, that means risk-based is really important. 02:52.160 --> 02:57.520 Is that if you have a risk, then you're going to have to try to find a way for the essential 02:57.520 --> 03:01.760 requirement to cover that risk. Even if you can't find the in-decentre requirements, you're 03:01.760 --> 03:04.960 still going to have to cover that risk, but really the essential requirements. 03:06.800 --> 03:11.520 Really the essential requirements are meant to be a way of sort of focusing the attention of 03:11.520 --> 03:16.320 manufacturers that they really have to look at this requirements and see, how can I apply it? 03:16.720 --> 03:21.680 So, this becomes really kind of a, both with theoretical and the practical question. 03:21.680 --> 03:28.000 And the way we're trying to help everyone to do that is with this figure called harmonized standards. 03:28.000 --> 03:35.200 So, the CRA is, as I said, EU product legislation and EU product legislation has been around 03:35.200 --> 03:42.080 for some 40 or 50 years. It underpins the EU single market. And it uses this legal concept 03:42.080 --> 03:48.560 of harmonized standards. Harmonized standards are regular European standards, but they have been 03:48.560 --> 03:52.880 published. The reference has been published in the official journal of the EU. And that's because 03:53.520 --> 03:57.760 they should only be published, so there should only be harmonized when they meet the requirements 03:58.000 --> 04:02.640 of the legislation. So, of course, it becomes crucial to understand, first of all, what are the 04:02.640 --> 04:07.280 requirements and then how do we meet them? And I think one of the key things that we've been working 04:07.280 --> 04:12.160 on already for a year and a half almost two years on this standardization process has been to try 04:12.160 --> 04:18.080 to clarify what does it mean to meet these essential requirements, the cybersecurity requirements. 04:18.080 --> 04:24.720 And a lot of it revolves around identifying risks, even a use case or the legislation calls it 04:24.800 --> 04:31.120 the intended purpose, the reasonably foreseeable use. And then defining mitigations for those risks. 04:31.760 --> 04:37.360 And if you can define a mitigation that everyone agrees is sort of the state of the art mitigation, 04:37.360 --> 04:43.200 then we're happy. We can say yes for this risk, there's that mitigation. And if you apply that 04:43.200 --> 04:49.440 standard or that mitigation, you receive a presumption of conformity. And the presumption of conformity 04:49.440 --> 04:54.560 makes your life a lot easier, because you can just claim very easily, I comply with the CRA, 04:54.560 --> 04:59.040 and nobody's really going to argue about that unless there's a problem in the future that could 04:59.040 --> 05:04.160 happen, but in principle, the presumption of conformity as a legal figure makes it a lot easier to 05:04.160 --> 05:10.080 comply. So, we've been trying to engage with standardization bodies in order to push out these 05:10.080 --> 05:16.400 standards that meet state of the art. And as open source practitioners, you probably know that the 05:16.400 --> 05:21.760 work that's done by the open source community is often state of the art. So, a lot of this also 05:21.760 --> 05:26.720 are interested in engaging with open source is really to see, you know, you are the real experts out there. 05:26.720 --> 05:31.280 So, please come and participate in this process. So, we can all learn from you. And we can all 05:31.280 --> 05:35.920 make the market a little bit more transparent when it comes to the cybersecurity practices. 05:35.920 --> 05:40.800 This is one of my main interests in engaging with the open source community. Okay, 05:40.800 --> 05:45.920 but there are problems in the open source participation. And we've been trying to address those in a 05:45.920 --> 05:51.680 number of different ways by sort of supporting the engagement of the community, several different 05:51.680 --> 05:57.840 communities. So, we had to get some action grants to the standardization bodies, the European 05:57.840 --> 06:03.680 standardization bodies, since senilek and Etsy. And as a requirement for that money to be given to them, 06:03.680 --> 06:10.000 they have to agree to hold additional external stakeholder consultations. And those are going to be 06:10.000 --> 06:17.280 happening, by the way, I'm going to just put this here, from April May onwards. So, if you 06:17.280 --> 06:25.760 wish to participate in this process, you can and you should get ready because it's going to happen 06:25.760 --> 06:35.520 quite soon. First drafts should be, start to be publicly discussed from April or May onwards. 06:36.400 --> 06:40.880 And then it's going to be relatively short window, by the way, because it's only until 06:42.320 --> 06:48.000 depending on the standard. So, we have two types of standards for horizontal. That means 06:48.880 --> 06:58.080 probably until July August, 2025. For the verticals, that's product, specific standards. 06:58.080 --> 07:13.200 Probably until October, November. Thank you for the question. So, the way that the standardization 07:13.200 --> 07:18.880 work is set up, that we have proposed it to the experts and this is sort of the architecture that 07:18.880 --> 07:24.080 is underpinning all of this work, is that we have two types of standards. The horizontal standards 07:24.080 --> 07:29.360 kind of a framework approach the sort of very product diagnostic, very abstract statements about 07:29.360 --> 07:34.400 what does it mean to have a risk-based approach or risk management in your product security 07:34.400 --> 07:40.000 lifecycle that we call that the type A standard, by the way. And that's sort of the tip of the pyramid. 07:42.000 --> 07:47.760 And then you have sort of the product diagnostic description of different security mechanisms, 07:47.760 --> 07:53.520 like access control, encryption, or the vulnerability handling. We call those the type B standards. 07:53.520 --> 07:58.400 And these in principle could be used for any product or for large families of products. 07:58.400 --> 08:03.120 So, if it's just for a large family, we call it a broad vertical. So, I could put that here, 08:04.160 --> 08:10.800 a broad vertical. And then finally, you have the type C standards. This is going to be the 08:10.800 --> 08:14.560 really product-specific standards. And it's going to be like this open-ended, 08:14.560 --> 08:23.200 is open-ended pyramid that can be filled with type C standards. I put the vertical lines to 08:23.200 --> 08:28.560 to make the visual point. So, these are going to cover specific product types or even specific 08:28.560 --> 08:34.240 use cases of products so that you can really easily identify what are the risks and state 08:34.240 --> 08:39.520 what are the mitigations that you propose. And again, if there's a consensus process around 08:39.520 --> 08:44.160 defining the risks, defining the mitigations, everybody agrees it's the state of the art. 08:44.800 --> 08:49.440 We're good to go. We can have presumption of conformity, make compliance easy for everyone. 08:49.440 --> 08:54.560 And as I say, so this is the sort of horizontal framework, and then here we'll be the verticals. 08:55.680 --> 09:00.960 So, the idea is that you can just use the horizontal framework to produce more verticals, 09:00.960 --> 09:08.480 meaning for more product types or for more use cases. Over time, you can add more verticals 09:08.480 --> 09:13.280 to this library of standards to make it easier and easier and easier to comply, 09:13.280 --> 09:18.000 because the scope of use cases and products that are covered will grow with time. 09:18.000 --> 09:23.360 So, the idea is that this will become a kind of an ecosystem of product security standards. 09:23.360 --> 09:27.760 This already exists by the way for machine safety. There's currently something that they also 09:27.760 --> 09:32.240 have a type A. They have some 200 type B standards for different safety mechanisms, 09:32.240 --> 09:36.720 product diagnostic, and then they have some 600 working standards that are used for 09:36.720 --> 09:41.360 product compliance out there in the market. And so the idea is that we could 09:41.360 --> 09:46.880 arrive at somewhere similar over time. But we've started with the first standardization request 09:46.880 --> 09:53.600 with 25 products. These are the important and critical products are identified in the cyber-resillian 09:53.600 --> 10:00.720 fact as important and critical. And this is really because in the CRA being an important or critical 10:00.720 --> 10:04.960 product means that you need to go to a third party for your conformity assessment. 10:06.000 --> 10:10.160 We know that this kind could be a bit of a bottleneck, right? Companies are used to having their 10:10.240 --> 10:13.920 internal processes, but then if they have to go to an external to have it all checked, 10:13.920 --> 10:19.440 this can take some extra time. And so to facilitate that, we're really prioritizing having 10:19.440 --> 10:26.080 type C standards for those product types, product categories. But again, over time, this would be open. 10:26.960 --> 10:31.040 Good. So, that's the standardization track of this implementation of the CRA. 10:33.200 --> 10:35.600 Okay. So, there's a few other things we're also doing, 10:35.680 --> 10:40.080 but times already up. So, we have guidance, and I just want you to know that there's really, 10:40.080 --> 10:43.600 we're really interested to hear the open source communities voice in all of this. There's 10:43.600 --> 10:48.080 going to be guidance about a lot of these topics. In general, if you know about this CRA, 10:48.080 --> 10:51.920 or discussions on this CRA, and you think, you know, there's some concepts here that are really 10:51.920 --> 10:56.640 not well explained. Well, we hope to be able to come out with guidance to clarify those things. 10:56.640 --> 11:01.040 So, it's really important that we can engage constructively in dialogue because we want to hear 11:01.040 --> 11:05.200 your questions. We want to hear your proposed answers to them. We want to find out like through 11:05.280 --> 11:12.080 a process of societal consensus building, what should be good clarifications to give to these questions. 11:12.080 --> 11:15.680 That's going to be the guidance. Then there's a number of other implementation steps we're going 11:15.680 --> 11:20.880 through. And basically, they're broadly open, so that you have this better regulation process, 11:20.880 --> 11:25.120 where always we have to consult stakeholders, there's always public consultation. So, 11:25.120 --> 11:29.200 just wanted to flag to you guys. If anybody wants to get involved in this, I really recommend you 11:29.200 --> 11:33.600 to get involved. It's quite exciting. Again, first time that software's being kind of regulated, 11:33.600 --> 11:38.160 at least in the product security side. So, a lot of stuff happening, we need to make it good. 11:38.160 --> 11:42.160 And I think we count on the engagement of stakeholders to make that happen. So, thanks very much. 11:42.160 --> 11:52.160 Thank you very much.