WEBVTT 00:00.000 --> 00:10.000 So, hi everyone, I hope you can hear me, I'm going to try to give a very old school 00:10.000 --> 00:11.000 top. 00:11.000 --> 00:16.000 Can you hear me? 00:16.000 --> 00:17.000 I see. 00:17.000 --> 00:19.000 So, you need to talk to the road. 00:19.000 --> 00:20.000 Okay. 00:20.000 --> 00:24.000 And the mic is just for all the, there's about 30 people walking you on video. 00:24.000 --> 00:25.000 Okay. 00:25.000 --> 00:26.000 Good morning, everyone. 00:26.000 --> 00:27.000 My name is Philippe Modell. 00:27.000 --> 00:31.000 I'm a policy officer in the European Commission. 00:31.000 --> 00:35.000 I work in DG Connect in the cybersecurity policies unit. 00:35.000 --> 00:40.000 And today I'm here to talk to you about the implementation of the Cyber Resilience Act. 00:40.000 --> 00:45.000 So, because my slides, I couldn't get my slides to work, I'm going to try to use the board, 00:45.000 --> 00:47.000 like old school professor. 00:47.000 --> 00:54.000 So, the Cyber Resilience Act. 00:54.000 --> 01:00.000 The Cyber Resilience Act came into force in December 2024, after a two and a half year process 01:00.000 --> 01:06.000 of negotiations in which the open source community has participated to unprecedented extent. 01:06.000 --> 01:11.000 And we're now excited to start the actual work of making this happen. 01:11.000 --> 01:19.000 And the way we're doing that is by as much as possible setting up the conditions for stakeholders 01:19.000 --> 01:25.000 to participate in a process of discussion of all of the relevant legal topics. 01:25.000 --> 01:31.000 Before a show of hands does anybody not know what the Cyber Resilience Act is in this room. 01:31.000 --> 01:32.000 Okay. 01:32.000 --> 01:33.000 Okay. 01:33.000 --> 01:34.000 That's enough people. 01:34.000 --> 01:40.000 So, the Cyber Resilience Act is the first European legislation, perhaps even the first global legislation, 01:40.000 --> 01:43.000 to mandate product security requirements. 01:43.000 --> 01:46.000 So, it's the first time that product security becomes mandatory. 01:47.000 --> 01:51.000 And the scope is products with digital elements. 01:51.000 --> 01:56.000 So, that includes hardware and software, also the smart products. 01:56.000 --> 02:01.000 So, it's a sort of legal scope of a product that includes the remote data processing part, 02:01.000 --> 02:04.000 the cloud service associated to a product. 02:04.000 --> 02:07.000 So, of course, all of these things start to raise questions, 02:07.000 --> 02:13.000 since it's a relatively new that regulation touches on software for instance, 02:13.000 --> 02:15.000 or the cloud services associated to a product. 02:15.000 --> 02:17.000 So, there's a lot of discussion. 02:17.000 --> 02:20.000 So, there's discussions on how to cover open source. 02:20.000 --> 02:23.000 Open source was largely excluded from scope, 02:23.000 --> 02:27.000 but there's also other things like what does this remote data processing solutions. 02:27.000 --> 02:29.000 What does it actually mean? 02:29.000 --> 02:34.000 How do different companies interact when they provide a smart product? 02:34.000 --> 02:37.000 If I'm a manufacturer of the hardware, 02:37.000 --> 02:44.000 but I'm contracting the software as a service or platform as a service with Amazon or Microsoft or anyone else. 02:44.000 --> 02:51.000 And how do we contractually arrange compliance to cybersecurity requirements that are horizontal? 02:51.000 --> 02:54.000 So, this is really the main thing about the CRA. 02:54.000 --> 02:57.000 It's horizontal cybersecurity requirements. 02:57.000 --> 03:01.000 There's about 12 of them just for the products, 03:01.000 --> 03:04.000 and then another 10 or so for vulnerability handling. 03:04.000 --> 03:09.000 And they, in theory, apply in a risk-based way to any product. 03:09.000 --> 03:12.000 So, that means risk-based is really important. 03:12.000 --> 03:19.000 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. 03:19.000 --> 03:22.000 Even if you can't find the indisensual requirements, 03:22.000 --> 03:26.000 you're still going to have to cover that risk, but really the essential requirements. 03:26.000 --> 03:37.000 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. 03:37.000 --> 03:41.000 So, this becomes really kind of both the theoretical and the practical question. 03:41.000 --> 03:47.000 And the way we're trying to help everyone to do that is with this figure called harmonized standards. 03:47.000 --> 03:56.000 So, the CRA is, as I said, EU product legislation, and EU product legislation has been around for some 40 or 50 years. 03:56.000 --> 04:03.000 It underpins the EU single market, and it uses this legal concept of harmonized standards. 04:03.000 --> 04:08.000 Harmonized standards are regular European standards, but they have been published. 04:08.000 --> 04:12.000 The reference has been published in the official journal of the EU. 04:12.000 --> 04:19.000 And that's because they should only be published, so there should only be harmonized when they meet the requirements of the legislation. 04:19.000 --> 04:25.000 So, of course, it becomes crucial to understand, first of all, what are the requirements, and then how do we meet them? 04:25.000 --> 04:31.000 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, 04:31.000 --> 04:38.000 has been to try to clarify what does it mean to meet these essential requirements, the cybersecurity requirements. 04:38.000 --> 04:46.000 And a lot of it revolves around identifying risks, even a use case or the legislation calls it the intended purpose, 04:46.000 --> 04:51.000 the reasonably foreseeable use, and then defining mitigations for those risks. 04:51.000 --> 04:59.000 And if you can define a mitigation that everyone agrees is sort of the state of the art mitigation, then we're happy. 04:59.000 --> 05:08.000 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. 05:08.000 --> 05:17.000 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, 05:17.000 --> 05:25.000 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. 05:25.000 --> 05:33.000 So we've been trying to engage with standardization bodies in order to push out these standards, that meet state of the art, 05:33.000 --> 05:40.000 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. 05:40.000 --> 05:47.000 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, 05:47.000 --> 05:53.000 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 05:53.000 --> 06:00.000 when it comes to the cybersecurity practices. This is one of my main interests in engaging with the open source community. 06:00.000 --> 06:07.000 Okay, but there are problems in the open source participation, and we've been trying to address those in a number of different ways, 06:07.000 --> 06:12.000 by sort of supporting the engagement of the community, several different communities. 06:12.000 --> 06:19.000 So we had to get some action grants to the standardization bodies, the European standardization bodies, 06:19.000 --> 06:29.000 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, 06:29.000 --> 06:36.000 and those are going to be happening, by the way, I'm going to just put this here, from April May onwards. 06:36.000 --> 06:47.000 So if you wish to participate in this process, you can, and you should get ready because it's going to happen quite soon. 06:47.000 --> 06:56.000 First drafts should be publicly discussed from April or May onwards. 06:56.000 --> 07:07.000 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. 07:07.000 --> 07:30.000 That means probably until July August, 2025, for the verticals that's products, specific standards, probably until October, November. 07:30.000 --> 07:43.000 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. 07:43.000 --> 07:58.000 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. 07:58.000 --> 08:02.000 And that's the sort of the tip of the pyramid. 08:02.000 --> 08:11.000 And then you have sort of the product diagnostic description of different security mechanisms like access control, encryption, or the vulnerability handling. 08:11.000 --> 08:18.000 We call those the type B standards, and these in principle could be used for any product, or for large families of products. 08:18.000 --> 08:27.000 So if it's just for a large family, we call it a broad vertical, so I could put that here, a broad vertical. 08:27.000 --> 08:37.000 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. 08:37.000 --> 08:45.000 It's open ended pyramid that can be filled with type C standards, I put the vertical lines to make the visual point. 08:45.000 --> 08:56.000 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. 08:57.000 --> 09:05.000 And again, if there's a consensus process around defining the risks, defining the mitigations, everybody agrees it's the state of the art. 09:05.000 --> 09:10.000 We're good to go, we can have presumption of conformity, make compliance easy for everyone. 09:10.000 --> 09:16.000 And as I say, so this is the sort of horizontal framework, and then here would be the verticals. 09:16.000 --> 09:25.000 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. 09:25.000 --> 09:38.000 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. 09:38.000 --> 09:46.000 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. 09:46.000 --> 10:00.000 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. 10:00.000 --> 10:09.000 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. 10:09.000 --> 10:26.000 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. 10:26.000 --> 10:36.000 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. 10:36.000 --> 10:47.000 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. 10:47.000 --> 10:53.000 Good, so that's the standardization track of this implementation of the CRA. 10:53.000 --> 11:06.000 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. 11:06.000 --> 11:17.000 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. 11:17.000 --> 11:24.000 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. 11:24.000 --> 11:32.000 We want to find out like through a process of societal consensus building, what should be good clarifications to give to these questions. 11:32.000 --> 11:45.000 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. 11:45.000 --> 11:56.000 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. 11:56.000 --> 12:03.000 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.