Good morning, everyone.
So this is our European Commission presentation about the Cyber Resilience Act, somehow
reporting to the community about how we have tried to engage with you.
In 2024, we gave also a talk called, the regulators are coming.
Well, two years later, the regulators are here.
My name is Philippe Morão.
I am a policy officer in DG Connect in the CRA team.
I'm joined on the stage, actually.
I'm joined on the stage by Lucia Lampri from Sen.
That's a European standardization organization, Luach Pursan from Etsy and other European
standardization organization.
And Carl Daniel Helfinger from the German BSI, who will be a market surveillance authority
under the CRA.
So in case some people are not yet very familiar with the CRA, we will cover some basics,
and we will give you an update of where we are, what we've been doing, and how you can
still get involved.
I hope you can hear me well because the microphone is, okay.
So in a nutshell, the CRA is asking manufacturers to remove vulnerabilities from their products
before placing them on the market.
It's nothing against Swiss cheese, it's just against vulnerabilities in products.
And it uses the logic of EU product legislation with the C-marking to define horizontal
requirements for products that apply in a risk-based way across the product lifecycle.
That means also once the product has been placed on the market, manufacturers are asked
to do vulnerability handling.
It uses harmonized standards to help manufacturers comply.
And the enforcement of the legislation happens exposed by market surveillance authorities.
That's the general logic.
The scope of the CRA is quite broad.
It covers both software and hardware products, including the remote data processing solutions,
the remote parts of our products more and more prevalent every day.
There are some important exclusions, though, in particular, non-commercial products are excluded
from scope, which of course includes all non-commercial open source.
There's also an exclusion for standalone services, exclusively web-based websites, things
like that.
And there's also some sectoral exclusions, products that are regulated by other legislation,
like medical devices, automotive, aeronautic marine equipment.
The CRA, because it covers this broad scope, one of the things that really I think will
do, is it will foster supply chain cooperation.
It's really the first time that manufacturers essentially have to speak to their suppliers
and to their downstream integrators in order to get more information about what's happening
so that that will help them to comply more easily.
So the CRA creates the conditions for large-scale cooperation along the supply chain.
And the approach to open source, which I think is probably the most important slide today,
is that only directly monetized open source products are subject to the CRA.
That means only those that are being properly commercialized.
If you just provide development and you charge for your time or for your resources,
that might not even be a form of commercialization.
If it's free and open source, we don't want to prevent you from doing your work.
We don't want to put extra burdens on you.
On the other hand, if you are providing support services, branding and placing this on the
market and their trademark, then you are considered like any other manufacturer.
Then the CRA also creates the open source steward, not anyone can be a steward.
You have to be a legal entity, non-profit.
And for those, it creates a kind of lightweight approach where steward's have to set out
a policy basically kind of setting out best practices for a community.
So this is the general logic of the CRA, and for us, the most important message is that
the CRA does not regulate non-commercial open source.
So for instance, all of the very useful tips that were provided by the previous speaker,
all of those I think are much more useful for an open source company, an open source manufacturer
who is in scope of the CRA.
But if you are just an open source developer who is not commercializing your code, well,
yeah, you can do those things and that might be good for the world, but you don't have
to.
And the CRA doesn't ask you to do them at all.
That's, I think, a very important message that we wanted to remind everyone of.
So anyway, quick point on the timeline.
The CRA was adopted end of 2024, and we are in the transition period.
That's a three-year period.
We've been busy on standards, we've been busy on guidance, there's a CRA expert group.
We're just a few details on that.
The expert group includes open source representatives, it includes open source, the CMEs,
it includes foundations, and we are quite happy with the variety of stakeholders.
There's also been work that we have done in terms of implementing legislation with the
technical descriptions of important and critical product categories.
And there's being published, the CRA website with FAQs.
So please check those out if you're curious to understand better about the legal reasoning
behind the CRA.
And coming up this next year, there will be more CRA guidance, in this case, it's a lot
about the FAQs becoming more official guidance, including guidance on the definition of open
source and the definition of open source stewards, notions such as the monetization or the
commercialization.
So a lot of the questions that you might still have about what is the nitty gritty details
of when the CRA applies or doesn't.
We hope that this will go a far way to answering those questions.
But even if they don't, bear in mind, we see this as a living document that we will continue
to update.
We will continue to engage with the community, collect your questions, and try to answer
them.
There's also a study ongoing on voluntary security attestations.
This comes from the CRA article 25.
We hear a lot of interest from the community as a way of developing these attestations
in a way that will actually support developers and manufacturers going forward on open
source.
And we are also working with Anisa, who will be setting up a single reporting platform
because CRA reporting obligations, again, just for manufacturers, they kick in from September
2026.
There's a standardization request.
It was adopted early last year.
There's a lot of standardization effort has been going on.
This image represents visually a little bit the architecture of the standardization request.
And basically, there's a framework standard, some horizontal standards.
And then the type C standards that you see at the bottom, these are product specific or
product category standards that we'll be able to go into the details sufficiently to receive
a presumption of conformity.
That is the objective of harmonized standards.
So participation of open source, how has this happened in the CRA?
I tried to summarize that in this slide.
Essentially, we heard you during the legislative process.
The commission came out with a proposal, and maybe it was not as clear as many of you
would have liked the exclusion on open source.
So I think that that was improved in the text.
Then during the standardization, we've made efforts.
And we will hear a little bit more about that from the standardization bodies who are here.
There is participation, even in the CRA expert group, there is participation for the development
of guidance.
And of course, we have some proactive engagement from the commission with the open source
communities, case in point.
So that's my part of the presentation.
Thanks everybody for listening.
I want to say that there are pins and stickers that have been floating around.
So please come and collect your pins and stickers for the CRA.
And then I will pass the microphone to Lucia for the sense-analytic part of the presentation.
Thank you very much, Philippe.
So I'm Lucia Lampri.
I'm from Sen and Senelik.
And we are two out of the three European SADization organizations.
And we have members in third four countries, that's how we work, members base, country
by country.
So if you read your country here, probably you will see also the race representative.
And then you can Google and you can read more about it.
How to join, for example, underworld that they are doing.
We are also working in many, many sectors, not only ICT, but a lot of sectors.
We have over 90,000 experts in our network of experts and 482 technical bodies.
So that was a little bit of facts and who we are.
How we work.
So we have expert working groups.
We have experts nominated by the national members.
So we have European partners, including the commission and an
experience organizations that are in ICT, international level, affiliates,
partners organizations and in particular for the cyber activities.
We have received requests from the foundations.
We have the Eclipse Foundation and the current request from the Linux Foundation.
As it was mentioned in the pyramid that Philippe was showing, we have different technical
bodies.
So we are developing standards at the J13, 10cm, 224,
10LX 47X and 65X.
So those are the names of our technical bodies.
We have a lot of technical bodies.
And so if you want to know more, remember that slide of the pyramid that shows
the structure of standardization request.
So this is a very important slide.
It's the final slide that I have before handing out the floor to my colleague.
Where were we before in the past?
So we come from a long-standing trusted system.
The European standardization organizations and elect,
it's from their side, they are a little bit different than us.
And we were always based in the international frameworks.
And we had then the decades of following the ISO and I seen international levels.
And we were largely and long and known to the open source communities.
And there they were also unknown to us.
Where are we today?
So we found that not only for the CRA, but the broader ICT context,
the open source communities become more and more relevant to our work.
So there is growing engagement to the open source foundations to us.
But also we noticed that there are barriers.
There are limited access.
We have a cultural gap.
I think this one is a very important one,
because we see that there are different needs and languages
from our stakeholders and from your communities.
And now we're trying to shift towards a more agile development
of our specifications, trying to incorporate different tools.
And we identify the dissacrution moment,
because the mutual learning has become.
So this is good, not perfect.
And where are we going now?
We are trying to have a structured dialogue.
And engage more with the open source communities.
We're seeking input from our technical committees
and trying to do experts interviews.
I have my wonderful colleague, Jenny, who is handing out the stickers.
He's helping us with collecting this information.
And we are trying to prepare the ground for a stronger collaboration.
And we are trying to engage management and different kinds of inputs.
So this is where we are today.
We are learning.
We are wanting to hear from you.
And this is in behalf of both Sensen and Eganetsi.
We have multiple stakeholder involvement at events.
And if you want to stay tuned, follow our events, please.
And there is an any second, friends, also coming up in March.
So thank you.
And I give the floor to Laura.
Thank you.
Thank you, Lucia.
Can you hear me?
Yes.
OK.
So Etsy is also a European standardization organization.
Together with Sensen and Alec, we have the task
to develop the standards to implement the CRA.
In Etsy, the stakeholders participate directly
in the development of the standards.
We are a non-for-profit organization.
And our membership includes very diverse organizations.
We have big industry players, but we also have SMEs,
micro-enterprises, we have associations, academia,
governments, and public bodies participating on an equal footing
to the development of the standards.
The membership is not limited to European companies.
We have 900 members coming from 60 different countries.
And maybe most importantly, to this audience,
Linux Foundation, Eclipse Foundation, OSI, Mozilla,
and many other companies involved in open source software
development are our members, and they can nominate delegates
to participate in the work of the technical groups.
So you're welcome to join the technical groups
to develop the standards.
In order to implement the CRA standardization request,
we created a specific group within a technical committee
on cybersecurity and this group is named EUSR
for EU standardization request.
A good fast, because this is basically a specific technical group
that we have created.
And I come to the subject matter.
In this group, we are developing a 17 and a 19
bonus harmonized standards.
So what are harmonized standards?
There are technical specifications that translate
the essential requirements of the regulation
into a practical requirements that you can implement
in your product, practical security measure,
that reflect the state of the art.
And also the harmonized standards include assessment criteria
that can be used to verify in an objective manner
that these technical requirements are met.
You can see here the list of product categories
for which we develop standards.
There are 17 of them.
I let you read.
We have browsers, password managers, anti-virus, VPN,
et cetera.
I want to stress the fact that many of our reporters,
meaning the people who are in the leading role
to draft the standards, in fact, the majority of them
are people coming from the open source community.
And many of them are present in the room.
So if you want to have a chance to exchange with them, please do so.
That's my message.
So you're welcome to talk to the reporters
and you're also welcome to contribute to the standards.
So how can you contribute?
Throughout the startup development process,
we've tried to follow a very open and transparent process.
We have started open consultation back in November.
And we have basically made our draft standards
publicly available in an open area, as well as in a GitLab
repository, since November.
At this moment, we have mature drafts posted
in the open area in GitLab.
And we invite you to review those and to submit your comments
in the GitLab platform.
I will show the link on the next slide.
The other thing we have organized together with Lucia
deep dive sessions.
But then over where we held basically webinars
open to the public, weather reporters,
where I'm explaining the content of the standards.
And offering people the opportunity to engage.
And these webinars have been recorded.
And you can listen to them and replay.
Another important point is the fast track base
at which we are working.
So the opportunity to comment on the draft standards
is now between now and the end of March.
Please submit your comments, please review.
Because after that stage, the final drafts
will go under a formula approval, the public and query
that will be led by the national or standardization
organization.
So you will no longer have the opportunity
to influence directly, but you
will have to go through your national delegation
to submit your comments.
But comments will still be received,
until roughly the middle of this summer.
OK, so I think the main message was this.
So please join us.
Please take this opportunity to influence
and contribute to the standards.
You can read them at this link,
where the QR code is pointing to.
At this moment, we have 13 standards available there
for you to review.
Next week, there will be all 17 of them.
So please do so.
And we'll welcome your input.
Thanks a lot.
APPLAUSE
Hi.
So yeah, I first wanted to say thank you.
You can unmute me?
Excellent.
So thank you.
Thank you for pouring your heart into developing
free and open source of fear.
You sacrificed your time for the common good.
You created digital building blocks of our society.
And you helped build our future.
So if you see that small temple in the right,
in these bricks, it's written false.
You can probably can't see that on the screen.
And we appreciate this gift you're giving to a whole society.
We want to say thank you.
I heard that thank you.
And we promise to see our able help here.
We also know, birds are nice.
Practical help is a lot better.
So obligatory comic time.
And this is intended to be a stick figure, carrying a huge rock,
written with pressure and demands.
And so is the series just in the burden?
The final start to make you call laps and kill you.
No, of course not.
The series intended as your sword and shield.
She'll shield you against demands against pressure, against obligations.
And also your sword.
So you can take that sword and force a seller
of projective digital elements containing your project
to give you the back fixes for free, of course.
So because people have asked obligations
of a non-commercial fear and open source software developers
are zero.
There are no obligations.
You do not need to join any steward or whatever
if your fear and open source developer
not earning money with that and your out of scope of the CRA
and everybody telling us something else
can please go away and read the law.
So next point, not even if somebody is using your project
in their commercial project, that's their problem, not your problem.
And you have no obligation for backfakes
and software bill of materials, reaction time or whatever.
You can just tell them, go away and by the way,
at the investment page for this talk,
there is a list of unofficial answers
quoting the law why this is correct.
So you can just copy and paste those answers.
If anybody tells you, hey, you must do,
you can just say, go away, not my problem.
So next, writes of upstream fossil developers.
The manufacturers using your project must report
all vulnerabilities to you.
They must give you their security fixes
if they have any for free.
Of course, it's the law.
And the idea is to shift the burden
from female open source developers to the manufacturer.
Yeah.
Sorry, I think this is a good one.
So manufacturers, on the other hand, subject to CRA,
they must report actively explosive vulnerabilities.
They must report severe incidents, affecting products
of digital elements.
And everybody else has voluntary reporting.
It's your choice if you do it or not.
You can report pretty much anything, which is a problem.
If it has security implications,
and there's also the single reporting platform mentioned
by Philippe, which makes it easier to report.
So if you don't know how to contact your cybersecurity
authority or authority elsewhere in the EU,
you can use that single reporting platform.
CRA, we, as BSI, are also market surveillance authority,
which means we ensure 11-paying level paying field.
That means in less than friendly worlds,
you're taking the trash out.
So anybody having a product which is trash,
we won't have the level in playing field.
We also, as a market surveillance authority,
the support communication along the supply chain,
the support fuel and open source developers,
as much as we can, and also consumers.
The manufacturers as well, so we're not anti-manfectures.
You're going to help them as well.
And we help you understand the CRA and exercise your rights.
Next, please.
So BSI is also cybersecurity authority.
We have to maintain data to improve IT security for everybody.
Even also for free and open source software.
We are active in CRA, a sanitation,
I myself am active in the operating systems standard,
and food management standard.
Sorry.
We are also paying for security features
and free and open source software, for example,
document signing and we do outreach.
And, well, admittedly, I'm also free of open source software
developer and maintainer have been doing that
for the last 24 years.
So I know solving tech problems is easy.
Getting paid or getting taken seriously
or even getting supported is way more difficult.
And I hope that the CRA will be that helping hand
for those boring techs.
Toss, thank you.
Thank you.