Lessons from the CRA standardization effort

This talk covers the challenges and progress in the standardization effort of the Cyber Resilience Act (CRA), emphasizing the complexities of developing standards in a fast-evolving tech landscape. The speaker, August Borik, shares his experience working with Etsy to create these vertical standards, highlighting the relationship between free and open-source software (FOS) and compliance with the CRA. He discusses the structure of the standardization process, which involves extensive collaboration among industry delegates, and the challenges of drafting over 50 standards simultaneously. Borik draws parallels between historical railroad regulations and current tech standards to underline the need for adaptable, iterative processes in standard development. He advocates for deeper engagement with open-source communities as a vital element in shaping effective regulations and ensuring that the necessary expertise is harnessed.

[music] We'll continue with the next session with August Borik. >> Works for me. >> Good enough. >> And yes, said before it's um the lessons from the series standardization effort. So yeah, I was >> so yes uh yeah uh that is what I'm going to be presenting on. It's in interestingly uh having just heard Teimmo's presentation I feel like I'm giving a very similar presentation but not

really from the other side I'd say but but sort of from a different angle looking at the same thing. Um I have been working with Etsy for the last 10 months now to write CRA vertical standards and uh it's been an interesting process. So, we're going to go through some of the some of the things that I I've thought about this and um effectively this is just

me complaining for 45 minutes at you. Thank you for lending me your ears. Um I'm going to go through a little introduction. We'll try to breeze through that because a lot of it's covering some of the stuff Teemo talked about. Obviously, I have a slightly different take on it. Then we're going to look at problems because like I said, I'm here to complain. Uh and then we're

going to look at the relationship between FOS and standardization. And I'm actually kind of joking when I say I'm here to complain that I think as much as there are problems in the process, it's moving forward. Uh maybe not as fast or as well or without hiccups in a way that we'd all like it to as we're working on it, but it is moving forward and it

is I think doing an okay job. uh you know it is a very very tricky set of problems uh associated with creating these standards for the CRA because the CRA itself is an incredibly novel piece of legislation. Um and you know I I do want to talk about last about how it relates to FOS. So let's start with my introduction here. Uh effectively this is who I

am. Uh I am uh am August Bernik. I'm a US licensed Amsterdam based attorney. I have been working on the CRA standards as a special reperator for SEAM um for about 10 months, but the group I work with right now there's only three of us uh have also are also doing several of the other standards as well. And we're kind of working collectively. So you can ask

me about how the network interfaces, network management systems, seam and VPN standards are fairing. And if you want gossip about how the operating system standard was fairing, I can give you that, you know, 3 months ago, but that's been shifted. We had some change in our staff since it's been shifted. I uh prior to working with Etsy and moving to Europe about 3 years ago, I was

a um just sort of a general generalist attorney working a lot with um small technology startups and nonprofits in the in the technology space primarily on user safety and issues of sort of compliance around that. Before that I was a litigator and even before that back when I don't even remember what I was doing because it was 15 20 years ago I worked in the insurance industry

as an underwriter and you know other risk management scurrying about uh I because I am a lawyer and because this is what we are trained to do I have to give you a disclaimer and that disclaimer is that this presentation is not legal advice it's merely information and I am not your lawyer. So, whatever I say here, uh, talk to your own lawyer if it freaks you

out or if you're like, I can't believe that's true. And if your own lawyer tells you differently, trust them, not a random guy who's up here. Even if he has good hair, it doesn't matter. Trust your own lawyer because most importantly, they know your situation. Um, and also this presentation, it's me. It's there's nobody else backing this. My clients aren't backing this. No organization is backing this.

Whatever terrible things I say about the CRA process, that's just me. Don't go, "Oh, I heard Etsy said this." Because I am not Etsy. I'm just talking for myself. Um, so introducing the CRA standards. I'm going to go through this quick because we already went through this and also it's obviously written in a way to to annoy you. Uh, the CRA, Cyber Resilience Act, we all know

what it is. it was. But I think I do want to go over the timeline a little bit because it is very important to why we have the problems we have and also why we have the solutions that we're getting to those problems. The CRA was adopted in 2024. That's not that long ago, at least for me. I mean, you know, once you get past like 40,

that's not much time. Uh standardization began in early 2025. That's when the request for standardization was issued by uh the EC to the ESOs and it really didn't get rolling until you know a few months into 2025 we'll say. Uh I started working on it in June 2025. It's not even June 2026 yet. Uh what's even more shocking is that the the CRA itself will come into

effect. you will have to be complying. Well, maybe you won't, but someone will have to be complying with it. Starting late 2026, that is when the vulnerability handling requirements kick in. If if you are selling a product on the European market and something bad happens, you need to tell someone at that point or you could have liability issues. If you're doing an open source project, again, probably

not your issue. Might be, but but probably not. >> And then the full regulation comes into effect December 2027. which is not that far away. Uh I think what's particularly shocking here is it's not that far away in the context of product development timelines. And this is a product safety regulation. It is not a regulation about you know what the processes in your company are. It's a

regulation about what security features exist within a product. So when you're developing the product, you have to address that, right? So, it's interesting that people haven't been as active, I think, in trying to comply with the CRA as possible. Part of that is because the standardization effort is still happening. It's, you know, we have a couple drafts out. We don't even have a final draft out. Uh,

and the standards were designed to help manufacturers comply with the the CRA. The the CRA is structured in a way that most products most manufacturers can look at their product and do a self assessment and say okay it meets the essential security requirements and it's safe enough to sell now and if you document that and you keep your technical documentation say why you think it's safe in

these various ways uh why it has these features and not these features theoretically something bad happens you have a vulnerability you know the MSA decides to take a look at your product make sure you you weren't cutting corners, thinks about finding you. Um, if you went through use the standards, which is the other way to do it, you get a special, you know, you get you get

you get more protection uh in the form of what is called uh presumption of conformity. If you have conformed to the standards, it is presumed that your product is safe is it it it meets the requirements of CRA. And this is actually it's not it's a it doesn't shift liability, but it shifts the burden of proof from you having to prove as the manufacturer and I should

stop saying you because I don't want to scare people, but um the manufacturer having to prove that they met all the essential security requirements to the MSA, the regulator, market surveillance authority, having to prove no, you didn't. harder to prove that means you're probably not going to be the people that the MSAs are going to go after first thing if you follow the harmonized standard unless something

really bad happens. So the way standardization works we just little you know uh Teemo covered this pretty well. um the these private organizations, European standard standardization organizations which are are nonprofit um and are made up of primarily delegates from industry uh the regulated industry gets together, pays fees, joins these organizations and then can send delegates to the various standardization groups, working groups and stuff to provide input

and and this is not a shocking way of doing this. This is a very common way of writing standards and goes back, you know, to the 19th century. Um, because that's where the expertise is and those are the people that theoretically know what the best mitigations are for the security in the moment for that product and hopefully there's enough of them in the same room that nobody

gets it all their way. So, this has worked quite well. Obviously the work of the the delegates is reviewed as well by the EC if it's a harmonized standard to get harmonization and be published by the European Union and by the standardization professionals within the organization. So currently there are over 40 CR standards being written. Uh, I think it's a little bit more than what Teemo put

up because I think Teemo's diagram doesn't count several new standards that are kind of being mumbled about that have I've only heard rumors of from inside this this magnificent beast that is Etsy. But, um, it's a lot of work. It's a lot of standards. Uh, the standards are currently in draft phase. I would say this is particularly important right now and I do mean in like the

next 10 days. You can still comment on the public standards. You can still go to Etsy Labs. I mean, if you type it into Google, you'll get it. I sign up, you know, and use effectively a Git interface to say, "I don't like this. This is wrong. This is right. Oh, more of this." Whatever. Whatever you know, your technical expertise tells you, please limit it to technical

expertise. I have to read these comments and respond to them. So if it's just, you know, saying that the the the standardization guy that was at OCX had, you know, a funny accent, it's not going to be helpful. But and if it's just a general comment, it's not going to be helpful. We can talk about that more. I think it is probably something that if you're interested

in commenting, I am happy to tell you how to do the most effective comment you can that will actually probably have an impact because we do want those comments. Um, anyways, I've been rambling about that. We've already gone over the types of standards. There's horizontal standards that are being provided mostly by sensor like vertical standards lots of them. They were meant to build off the horizontals which

is where we start getting to the problems but we're not going to talk about the problems yet. This is all the ideals here. Uh this is the standardization process. U the standards you know the vertical standards are meant to build off that. They're drafted by both ESOs. There's a lot of them. Some of them are more open some of them are not. Like the industrial ones it's

very hard to get a draft from. they they have legal requirements that don't allow them to um the process itself. So they're they're as I mentioned drafted by industry members primarily. Now we have some open source members as well. Um the drafts are reviewed then by the ESO and the EC. In the old way it was all delegate drafted as Teemo mentioned. It's it's these meetings. You

know I've been in multiple days of 12-hour meetings online. It's I I feel for school children during the pandemic now. Um, and it's consensus based, but it is a slow iterative process of people sitting in meetings, reading documents, saying, "Well, I don't like this. What about this wording? Maybe this isn't how we do it." And it goes back and forth, and over time, you get a general

agreement. Nobody's happy. Nobody's super unhappy. Everybody's exhausted. You've been in there for 12 hours. But that seems to work pretty well. as as demo mentioned again. Um the problem is that that doesn't work for the CRA because there's I don't know 50 standards being written at once and uh you know the time is running out. Speaking of which, um the uh the the next thing I'd want

to mention is that they've introduced some novel elements. The public comments and it's new as far as I know and contract reperators like myself. They brought in people from the outside who they are theoretically paying to to draft these standards and there's a digital platform that's being used which previously it was an excel spreadsheet uh or no it's a word document that looks like an excel spreadsheet

but now there is a get that we are using so this has created problems um and it's all very novel this is an incredibly novel process but I feel like I'm losing the audience so I'm going to talk about my real interest which is railroad regulations from 1830 to8 1895. It's a transformative industry that completely changed the way modern life and the 20th century worked. It it

built these powerful economically powerful engines that made people enormously gratuitously wealthy that were sometimes so successful that they had more money than the people trying to regulate them. And it was also destabilizing because of that. Um we have this quote from Charles Francis Adams Jr. who is the the founding father of United States railroad regulation that says progress at any price is the watch word of the

present. He's talking about the very recent 1871. Um the issue with railroad regulation actually the real reason I'm bringing it up is because when we look at railroad regulation I think and railroad development we can see an echo of many of the issues we're facing now with tech. You have this allencompassing new technology. Everyone's trying to make money with it. People are making huge amounts of money

with it. They're not working together. There's competition and attempts to regulate it. No one knows what to do. There's a lot of bad ideas floating around. For example, England tried to regulate it by saying you can only have 10% profit on your rail industry based on your value. So what happened? We had the invention of stockwatering, which was a big word in the 19th century. I don't

know if it happens anymore. I'm not a finance guy, but basically, you say, "My company's not worth this. Look at all my stock." You make a bunch of, you know, stock that artificially inflates the value of your company, and then your 10% profit is all the profit you're going to make anyways, you know, 130% or whatever. So, that that form of regulation didn't work. Um, we're in

Belgium right now. It's one of the first countries to begin regulating railroads or to have railroads, passenger railroads. It did so an entirely different way than the United States and England, which is to say monopoly, state monopoly, creating state monopolies to form roads. This worked sort of over throughout most of continental Europe. Um, it didn't work for some things. It worked for other things. It's still something

that's, you know, NS still in in the Netherlands still owns the rails, but not the rolling stock or maybe it's the other way around. I can't remember. But there's a lot of legacy of this. And so whatever regulation decisions we make now about technology, about regulating software may be still something that people are annoyed by because they can't get to Einhovven when it snows in over a

hundred years. >> Um, so I just wanted to bring that up because I think a lot of times when we talk about CRA regulation, we talk about tech regulation, talk about emerging technology, there's this idea of like, oh my gosh, this is impossible. This is all new. Well, yes, it's new, but needing to deal with new problems isn't new. So, back to the CRA and its problems.

Um, the first problem I would say is scale. And I've mentioned this briefly a little bit. We have 50 standards. They're all being written at once. Like, literally, there are meetings every week. I could be in I think about 40 because we kind of used to do bi-weekly meetings but now they're I could be in 43 hour meetings a week if I wanted to know the entire

scope of the vertical standards and they'd let me into them all and I can't go to some of them. So that's impossible. One, I'm not being paid to not sleep. And two, I have to write my own drafts or respond to my own comments. So even the people who are paid to do this work don't have the time to have a great awareness of all of it.

And yes, the rapid tours talk to each other and we have our DMs and we send documents back and forth. But coordinating this is an enormous problem. And not just coordinating it, but it's very new. This is this software regulating software as a product is a new idea. We heard someone talk about how oh it's it's process regulation. This is not process regulation. These are product requirements.

So many of the existing standards and this is one of the ways modern standardization works. You go oh there's an ISO standard that does this. I'll just refer to that normatively. Yeah, do this this and this and also then just go do what ISO says. You can't do that because there's no standard to say this is the you know this type of network interface if you're using

it for this needs to be written in a in a you know memory safe way. Uh it has to have memory safety features. Maybe that's a memory safe language. I don't know that's something for someone who knows a lot more about how to make safe network interfaces to tell you than me. But I need to talk to that person and I know there's different ideas about that.

I I know that from a meeting last week. Um, but you have thousands of those little problems because this is all new and there are there's very little reference material that you can use that applies to it directly. So, not only is it 50 it's 50 standards dealing with things that are more technical and more novel than a lot of stuff in the past. These are free

standards. So, you know, many standards are paid. Uh this has created some issues that aren't really worth getting into, but it makes things more complicated in how the two organizations that are writing them interact because they have different models of how they use their standards to get funding. Um it also means that we can't you even if we could find ISO standards, it's very sketchy to refer

to them because there's ongoing litigation in the European Union that says, well, a standard that is implementing a EU law has to be free. And um that might include this is the might is the important part here that might include the standards that it refers to normatively. So if you do the thing where you say this standard do this one thing and then go look at ISO

ISO doesn't want to be free that's not something they will do but the European you know high court is saying they might have to. So in the meantime we can't refer to anything if we have any expectation of getting these published and getting these harmonized which means me getting paid. Um, so I care a lot about that part. But anyways, it's also a rapidly evolving area of

commerce. I mean, the the CRA stand the CRA act was written in finally in 2024. It was, you know, started in 2022. Um, already in 2026. There's some things in it that feel really antiquated because it does not really address sort of the emergence of safety related to uh you know machine generated code and and and you know stuff like that which is obviously a huge thing

but but there's a lot of little things too uh just in the definitions of what the verticals are. Um the second issue second problem we have is speed. Standards don't normally take a year to get written. They normally can take a couple years or five to six years if they're a really important one. And this is why that iterative in-person meeting fly to I mean luckily Etsy

is located in the south of France so you know it's not the worst place to go and spend a week in a small dingy conference room. Well they're not dingy they're they're quite lovely but not compared to outside. Um but that is the process or has traditionally been the process. It doesn't. You can't get all the people you need in the room, even online, all the time

in one year, especially if what you're doing is pulling delegates from industry. And the delegates that you need are highly technical people. There's only a few companies that have the resources to send their technical lead to spend 10 hours a week working on standards. How much money does that cost? Right? And if there's 50 of those standards all at once, I mean, I don't know. I mean,

maybe Google has a person for every one of those. I I I don't think so, but it's a lot of expertise and it's very hard to do. Um, the CRA is also emerging at the same time as a whole bunch of other laws like the AI act, which you have to comply with both. And that's not one I've really wanted to touch or think about because the

AI act is very long and very confusing. But you have these places where the laws, they're not in conflict, but there's definitely some friction there where where someone who's trying to comply with all of the with a CR standard and a another set of laws may be faced with some issues. And as someone who's writing a standard, I want to minimize that. Um, but we don't know

what all those concurrent laws are yet or how they're going to be interpreted because they're all new and it usually takes, you know, two to five years for a law to even have some idea how it's going to be interpreted. Um, but we're drafting these standards concurrently. Uh, I'm going back to another problem. I'm just see now I'm just complaining like I said I would. Um, concurrent

drafting of standards that are meant to inter interact with each other. It's like I think the metaphor that that a couple people have used a few times is like we're building this airplane as we're going down the runway, you know, and and there's some other team who we can't talk to that's working on the engines, you know, it's it's it's very hard to create standards that interact

even within the various vertical standards that interact with each other in a good way that follow the same structure. uh when you're so busy working on your own that you don't have time to, you know, check the guy down the halls. Um and that that is a problem and it's a problem. It's a I think it was a lack of vision in the beginning of saying, "Oh,

wait. We do need to begin with a set of, you know, skeletons or something that are specifically about writing a vertical CRA standard as opposed to this is what a hen looks like. this is what a harmonized standard looks like because it's a whole new kind of standard. So we've been struggling with that. We've been struggling with cross crossvertical issues. There's also so many parts of these

standards where elements of the product are shared across a whole bunch of products. So for example, cryptography, right? You have a lot of products that should encrypt data at some point and they probably are going to use similar algorithms, similar systems if we want them to be safe. So, it makes sense to have a crossvertical group get together and say, "Let's work on cryptography." And that's where

the cryptography experts are. And I don't understand anything they're saying, but theoretically, they're going to give us something that says, "Just pop this into the bottom of your of your vertical standard." And then of course we're going to have to analyze and say, "Well, maybe it's not right for our product." But again, this gets to the big problems. I think a lot of the little things I've

been talking about are just me complaining. The big problems, the big structural problems are again that because we're li relying on on volunteers. I mean, these folks coming in from industry, yes, it is to the advantage of a large company to have a say in the standards it's going to have to follow, but it still means getting your, you know, getting your boss to say, "Yeah, you

can give x hours a week to this project. And if if the demand is for you got other things to do, you might not be able to do that." And the company might not be comfortable with that. And particularly if you're a much smaller company, there's a lot of talk about bringing inmemes. Oh, we want the small and medium enterprises, microenterprises to have their say here as

well. And they should because one, that's where a lot of the innovation is happening. And two, those are the most people most likely to use the standards for various structural reasons. But I mean, I I know from personal interaction that if you have a company with four engineers, you can't send one of those engineers halfime to work on standardization efforts because you're not going to get you're

not going to have any money coming in because you're not producing anything anymore. Um, so that's a real problem and and and even if it wasn't a problem, even if all the industry was on board, and this is not to say that industry has not been helpful, um, the delegates that that are able to show up and there's a few for each of these groups, each of

these 50 groups have been helpful and they are doing their best as far as I can tell. I mean, I don't like what some of them have to say or, you know, some of them annoy me because I'm easily annoyed, but I don't think I can say anyone in this process, whether they're Etsy employees or the raptors like myself who have been hired from outside or the

delegates or representatives from open source groups that have come through in through a strange workaround that Etsy has allowed or the EC staffers have been trying intentionally to disrupt things or derail things or engaging in any sort of you know malfeasants I guess I would say but maybe that's too legal of a word but you know everyone's trying really hard uh and there's just not enough people

there is not enough expertise as far as I can tell to do this many standards at once and it's even trickier because it's not just expertise in technology it's not just finding the person who knows the most about cyber security for operating systems or for a particular type of operating systems then you need to find three more and you need to get them to agree. Uh it

is finding a person who knows that or enough about that and also knows how to read law or how to standardize, how to read standards, how to draft standards, how to interpret them. And this can all be learned but it's very hard to train up a core of people to do that whether they're delegates hired you know staffers or contractors to do it in a year and

also produce the documentation or two years or three years and produce the documents you need. So there that has been a struggle that has been a huge struggle. Um and then there's the structural friction which I think Teemo mentioned a little bit. I'm not going to go too into it. Uh where the traditional draft standards drafting system relies on slowly building consensus. We don't have time to

slowly build consensus. Uh we have trouble gathering expertise etc etc. Some of the specifics of this are the lack of early efforts to create shared structures that I mentioned the sort of lack of crossvertical stuff. the fact that neither the EC nor the ESOs seems to have employed small groups of technology consultants before that is to say individuals or uh consortiums of ex paid experts. So it's

been hard for them to keep us and it has annoyed us and it has caused a lot of delay over contractual issues and things like that. And I I'm not going to go into that, but I think both the EC and the ESOs are still learning that and hopefully it will improve. And that is actually gets to a point I want to have later about what FS

and standardization you know can do together or how it can work together because I think that is the future of writing CRA standards at least. um EC input has been difficult as well because the EC after publishing the wasn't ready with all the guidance or the delegated acts on what various things within the CRA mean. People had different ideas. It's taken till I mean this month there

was a release of a set of guidance on the CRA that was very helpful and covered some of the technical problems uh that I'm going to get to in a little bit. So the thing is though with all these problems I did say I wanted to make this a more positive presentation. These aren't insurmountable problems and it's not that they haven't been surmounted or aren't being surmounted.

Um there have been there's been a lot of change since I started you know less than a year ago in how the process is working in how the meetings are being run in in how consensus is being obtained in working asynchronously on commenting on using some of these platforms that have been put together to make the standardization process more efficient and I have a lot of hope

that that can be perfected over time. Um the EC has also started saying well maybe we should allow ANISA to provide expertise into some of the standardization efforts. That's that's new but it's more experts coming in with more ideas and more knowledge. Public comment is huge and I hope it will continue in European tech regulation and standardization because you know who knows more about software than the

entire public that includes everybody and there have been a lot of barriers to entry for standardization for good reason. I also am not so excited about the amount of AI slop that I've already started getting but please don't do and there have been efforts to bring in and engage with previously excluded groups particularly open source but alsomemes and and and you know some of that has been

us some of the the hired rapid rapids desperately looking for some expertise somewhere but some of that has definitely been Etsy and Etsy certainly has allowed it the EC has encouraged it. Um, I think one of the other things that is extremely important that is moving forward positively is looking at the CRA standards less as a we're going to get these standards out. They're going to be

fixed. They're going to sit there maybe in 15 20 years by the time the equipment rusts and we will we will have a new standard come out. Now there is at least from what I've heard talking with people in the commission there's the hope and within within the ESOs there's the hope that this will be something that can be done iteratively on a you know at least

a fiveyear basis a rolling five-year basis because technology is moving so fast the only way you could do a software standard right um and that this acknowledging that so acknowledging also that the first set of standards we get might be like that terrible standard for uh English railways that was absolutely a mistake and you know someone figured out a stock scheme to get around it. Well, that's

not the last regulation that went on European railways. They don't derail and explode nearly as often as they did in 1840. And that's part of the reason why. Um, so hopefully software will not collapse into a ravine, catch fire nearly as often as it does now or as it will in the first few years after the CRA standards and CRA um enforcement begins. Uh, there's still a

lot to do though. I think it is still a very opaque process. The fact that even someone who has been involved in standardization, you know, Teemo here has been involved in standardization longer than I have by a long long time, works for, you know, a huge corporation or is involved with a huge corporation and still has trouble getting access to the standards as they are being produced.

And that shouldn't be the case because if the goal is to get as much input as possible and the best technical input as possible, which it is, you need to give people things to read or to know what's going on. So I think there's a lot of room there still. I think the EC and the ESOs need to develop a workable model for engaging both with the

technology industry specifically with software uh which also means with open source and with hired consultants because that's one way to do it. But you know they need better processes and there needs to be a better process for rolling out huge standards like this rather than having it be a bottom up. the industry gets together, says, "Okay, in order to make things work a little bit better, we

need to figure out what components should work with what components, how to make them interoperable or how to make them safe so that your junk doesn't, you know, hurt my my customers." And that's been the traditional model when an issue has come up and industry itself has said motivated to do something. But in this case, because we're dealing with a a a regulation, which is exciting because

it means it's a EUwide immediately effective. It doesn't has to be transposed or or translated into national law, union member law. It it is the CRA is the CRA. And yeah, it's translated in a bunch of different languages. And I've talked to some people say, well, that's not what that means in German. That might be what it means in English. So, there's still issues there. But, you

know, that's a that's a European Union. uh one of the amazing things about the European Union. but it is this it is this real sort of unionwide regulation which is which is great. Uh but there needs to be a corresponding process to build up the standards release the most important ones or start producing um structures and slowly roll out so that the expertise is not overt taxed.

If we were only working on 10 vertical standards or five vertical standards my meetings would be full. I would have so many technical I I like to imagine this, but I don't know if it's true. People might just use that time to go on vacation. Um, we'd be able to go on vacation. Um, and then finally, the ESOs and the EC must actually engage with the technical

communities where they're at, which means FOS. Um, and and I think that there's a couple technical issues I was going to talk about a little bit. I think I'm going to skip, but these are this is sort of an example of some of the problems that you have, specific problems you have. aggregate product has been something that delegates from in your from manufacturing have been worried about

since day one which is I don't produce a network interface and sell it. You don't go to the store and be like give me that network interface. It look I mean some people do mostly because they're building another product and sticking that component in. But the vertical standard is for a network interface, not a product containing a network interface or uh you know like a router that

contains a VPN, a network management system and a network interface. What standard do you use for that? How does that product obtain presumption of conformity? Do you have to run it through five different vertical standards that are all being written by different teams that may be contradictory or just confusing? And luckily the EC has started addressing this. This has been a problem since day one. We only

got guidance on it the end of March. I like the guidance. It's not final, but you know, totally worth reading. Attestations are another issue, particularly a supply chain issue, which means they're an open source issue. So I would say that if you want to make an impact uh help OC help uh open SFFF anybody who's working on attestations try to make sure they they have a good

idea how to do that and uh influence the um standardization effort because verticals aren't touching at test stations it's not an area that we deal with but it is a huge area so standardization f I've got nine minutes left it's actually the short section I think the CRA and European technicalation needs foss foss is where the expertise is that is available in on this continent. I mean

companies have it as well but there's a lot of unutilized knowledge technical knowledge uh that is in the open source community that needs to be mobilized if the European Union is going to have these vast technology regulations and again back to railroads you actually need those regulations because it is a huge part of our lives uh and to have product regulations for CRA and similar you know

there's other things coming down the line as well. Having people who are stakeholders, who are developers in the open source community is essential because I mean I don't know what is that 90% of software 85 I hear different numbers but you know around have have an open source component at least and the people writing that need to be aware of these and they may not need to

comply with them but they need to have a say and have a seat at that table because that's the only way Europe is going to get the standards it needs to enforce these because there's not enough expertise otherwise. So anyways, you know, that's sort of a oraoris argument, but you know, whatever it it it's true. Um, also I think the FS model works a lot better for

standardization than it might first appear. making some decent money, but people aren't producing standards necessarily because they're trying to get super rich and people aren't producing open source software necessarily because they're trying to get super rich. And so I think there is a values connection there and there are some methods connection there that needs to be elaborated on because the old ways that that standardization are using

aren't fast enough or efficient enough for software standardization. They may be great and they may be much better at getting rules for you know uh machinery heavy machinery and and telecommunications equipment which has a much longer shelf shelf life much longer operational span but but software is changing so fast that the standard needs to evolve with it and so I think using asynchronous tools using a more

transparent and open process are going to be the ways to go forward with standardization I think open source can teach a lot to both government and the uh ESOs to do that. I think there's like I said a shared value between them shared set of values in there and I also think that the CRA particularly benefits FOS there are a lot of protections written into the CRA

and this is because open- source groups and individuals got involved early on when the first drafts of CR came out and they were very scary. Um, I believe that future uh tech regulation in Europe and hopefully elsewhere will take into consideration the benefits that open source technology provides and that open source communities provide and expand those protections across you know other regulations and I think the CRA

acts as a model for that which is why I think the more involvement in the CRA that uh open source communities can have now and can continue to have the better it will be in the future because this is the law people are going to look at when they're writing the next one where they're saying oh open source is bugging us what do we do to make

them happy what do we do to make this law better um there's also the creation of the open source steward this is a new form of economic actor that exists in CRA that is specifically for organizations that support development of open source products well open source projects uh potentially products it could be a source of income come for well not income maintenance money right you're not make

you're not getting rich off off even off an open source stewardship but it does mean that it may be a way to create more maintenance funds or regularize the way maintenance funds are delivered uh I think because the EC has been a little bit uh shifted its interest into other parts of the CRA stewardship right now is something that if you have good ideas for and if

you work through one of the open source uh foundations particularly and you can get you can get those ideas in front of the commission or you can just start being like okay we're a steward this is our steward model this is how it works and if it works that'll become the norm because there's no one else well other than other people in open source foundations trying to

do it so if you have the one you know you get you get to get engage in a little bit of competition around what the future of um open source foundations is going to be um and I think I think that I am seeing a lot of this effort already in the open source community. I mean OC particularly the Akos Foundation has been very impressive in the

amount of work it's been doing to provide tools for for project uh for projects and developers. It's still obviously a little bit in the beginning and maybe it stumbles here and there but it's better than uh a lot of stuff I see and that includes you know people who want to charge you to do their uh to do their open s you know to to make your

product compliant that you know I think and I think there's more space for open source tools and um instruction on working with the CRA and because there's going to be ongoing vertical development uh mult new verticals can be proposed theoretically. This is another area where open source foundations and open source projects can get involved. I mean theoretically I've heard it said I don't know we'll see how

it actually works out in the future but if a group of you know industry representatives went to Etsy and said hey we think there needs to be a standard for this particular type of software or hardware this digital product. Etsy would be open to be like okay form a TC we'll you know form a technical committee and or a or a working group and we will if

we like the standard and it follows the structures that have been laid down we'll see if that can be turned into a hen uh and I don't know why that has to be you know industry that could be open source as well so that is sort of my um my take on this and my take on the existing problems and how they're being solved and how they

are going to persist. But I do want to end positively and and say I would much rather have the people in this room at this conference and in the open source community generally deciding what the future of cyber security looks like than and and also the EC and and and many of the industry delegates that we have then no one deciding that or it being decided by

what makes the most money for the biggest company. uh and this is the opportunity to do that because the problems that I've mentioned are also creating a crisis which compounds with the crisis the crisis of for so for technology generally and uh for you know the global kind of multinational technology digital sovereignty kind of concerns that we hear voiced a lot by by the government in in

the European Union. So getting involved with the CRA and getting involved with the process, now is really the time for people to come in from the outside and and have their say. So do what you can. Uh if you have any questions about that, I have some ideas, but if I knew exactly, I'd tell you what to do. Um I don't yet, but I'll think about it.

Maybe next year. Uh so if you have any questions, uh feel free to ask. These are me. This is my name. This is my LinkedIn. This is my website that I don't have time to update anymore. Um so thank you very much. I appreciate your time and I have 1 minute and 40 seconds. So, quick question. Uh, you know, I'm I'm happy to do any answer anything

you may wonder or talk to me later. I'll be around all week. All right. [applause]