Before we start, I have two announcements.
First is for the people who are going to the open-ended workshop tomorrow.
Check your email for the new location. It has changed.
The second announcement is related to this talk.
Those are the chocolates. Who has been to two of my previous talks at first
them? What was yesterday? In the other words, this morning.
Not too many. It didn't work. But there are still people.
So I'm going to give those chocolates.
The first person I've seen who attended three talks,
then you organize yourself to the show chocolates.
People who attended two talks qualify also. Who was that?
It was you.
And then you start passing the chocolates to other people.
Thank you.
So, formally you haven't attended the first talk.
But we are going to start, right?
And there are people coming in.
So, this is going to be a personal selection of events that happened during the last year
in the embedded space.
Even with a few categories like regulation, cryptography, and so on.
Maybe I'm not giving exact dates because that's not that important.
But you will have in the slides later on
that you will be able to download links to various talks, events, and the like.
So, I was thinking a long time what I'm going to start with.
If I'm going to start with regulations or I'm going to finish with regulations,
in during my talks, finishing with regulations usually means that then I have an hour talking about regulations in the question and answer section.
So, I'm going to start with regulations that hopefully are going to forget all your questions.
So, but who am I?
I'm Marka, I do embedded security and I don't have a lot during all of those conferences.
So, where do we start?
We are going to start with regulations.
Yeah, regulations.
So, the regulations, the big regulations that we have going on for the embedded space in this is the cyber resources act.
Most of people here are in Europe.
So, I'm going to test it again.
So, who knows the cyber resources act well right your hand?
Okay?
Who has heard about it?
Way better.
Okay.
So, cyber resources act mandatory cyber security requirements for all of them.
But the product, it's already in place, but all of the conditions apply in December 27.
And what happened in 25, about all of that?
There was a work on standards and first set of standards have seen, have been seen by people other than people working.
So, the big reminder is that standards are not mandatory, but in practice, especially in some categories, you will actually need them.
So, there was the first review round for quite many of them and still continuing for the vulnerability management horizontal.
And there is a common problem going on with the serious standards affecting especially embedded in small companies that it is still not clear if they are going to be available for a fee or not.
Especially taking account that you have three horizontals that apply to everything.
And then you have 40 something verticals.
If you want to buy them it's 150 Swiss francs.
So, this budget, so the discussion is going on and some people do not want open source people to talk about this anymore.
But we do.
Then the second subject is the European vulnerability database.
So, this is even more funny because there is an obligation to report exploited vulnerabilities and security issues in all products starting September 26.
That's this year.
And the really funny thing is that the site where you will be doing that is not that part is not even embedded.
So, that's interesting.
The database itself.
That's basically assumes you are going to use to check your products for vulnerabilities.
It is in preview.
Yeah, but that's still the work on it.
And then in December last year, the commission has released a fact answering some of the questions that the community was asking them to clarify for a very, very long time.
And it's long.
Important clarification for embedded people.
It is on the support period.
The support period is the number of years during which you need to release security updates for free for all of your products.
And the clarification is that the start of that support period comes from the moment the manufacturer sells the product.
Not from the end of design.
Not from the moment you fork the object or build root to support that vote.
But it starts from the invoice date of the manufacturer.
So if you have one batch, there's a part of the batch on the shelf.
So later, the support period for that part of the batch runs from the moment they are actually sold and not put in the warehouse.
So that's a pretty important and they confirm that the risk assessment is the only line of defense that you have.
The specificity of CRA is that it's a risk based approach.
So there's no checklist of the features you expected to have.
We expected to have a risk assessment and it's the risk assessment that will be giving you the checklist.
And a lot of responsibility that comes from.
So I did the presentation about risk assessments.
But I do not think it, okay.
But I think I think to the fact so that you can have a look, there will be at least one more on open source, but I don't know why.
So what also happened in 2025 on the embedded markets now.
There's more alone awareness about the series that's really really clear.
And if you work on embedded products.
As I recommend you to do a try and ask your vendors to provide their CRA plans.
Because if in 2027 they are unable to fix the C mark on the product.
The new C mark with the cybersecurity requirements.
You have a pretty supply chain problem because you cannot integrate that product that component anymore into your product.
Better to ask them before if they are preparing.
And so vendors are even starting to provide S-bombs on their websites.
That's the real revolution.
This advantage of the fact that companies are starting to be aware about the CRA is them misinformation.
So I've seen basically all false informations about the CRA online.
Including presentations of certain features as mandatory under the CRA where they are not.
So be really really careful about what your vendors tell you.
And there are some vendors that are claiming CRA compliance already.
I do not claim series compliance for my product yet because at least I do not know how to report those them exploited when I beat this to any site.
I'm missing at least that.
So if someone is claiming that that's orange orange getting into red sign.
I check it for you to check if you are ready.
We are not going to play with hands.
At this stage next year.
The first important thing is if you have an update system for your products because that's one of the basis of the components.
And then if you can receive vulnerabilities of your products easily by users and then you know how to handle them.
That includes updating your products.
And if you have started thinking about risk assessment, I guess that people will start writing those things this year.
I, I, I, I, he is the link to my to my talk last year about the basic of of risk assessment.
Find that.
Okay, now a little bit lighter.
Subject cryptography.
That apparently is a really controversial, even even more controversial than CRA.
It seems when I posted on social media. So the quantum computing.
As a background.
Algoriths for post quantum cryptography has been standard.
What it means that they are normalized.
They could be used and what is what is post quantum.
You've probably heard about quantum cryptography.
If and when cryptography shows up, it will be all the public key algorithms that you have including your SSH keys.
They will be really easy to break.
But with the current knowledge, it doesn't break symmetric algorithms like I, yes.
This is that subtlety that it does break certain things, but not everything that we have.
The current estimations about when it can happen, they vary.
The optimistic people are saying in a few years.
So less optimistic people say in a 10 to 15 years.
And so people are saying that it's never going to happen.
That is a nice risk assessment scenario because when it happens, you are going to have devices in the field.
And many of you are already working on devices that will be in the field in 15 or 20 years.
The question is what do you do?
You may already reserve RAM and flash space for those extra libraries that will have those algorithms to eventually update.
They should further or you already link them cryptographic libraries in assuming that for product that you ship today,
there's no hardware acceleration for those things.
It's going to show up in a few years problem.
From the good site also on the post quantum, open SSH support from the current LTS of basically everything.
And they missed the window for one of the parts for the signature validation that is available only in 36.
So if you want to add post quantum to your products, you can.
They are all the cryptolibrary working on the support of post quantum at different stages.
So post quantum is a risk assessment exercise.
What do you do either you do nothing and you may wake up with devices in the field that have completely broken.
Outerizations for example, or you start adding those libraries in your products.
And here I will play with with hands who has already looked in the post quantum.
Oh really nice nice nice nice.
So on the two side.
First on the typical tools on the compiler side and my security side.
There is now F-houdent option in GCC.
That is combining some of the nice hardening options that you have.
So why not to use it?
There are also hardening improvements on different platforms in LLVM.
LLVM doesn't have F-houdent yet, but they are discussing.
The second big subject of course in the field is the move to memory safe languages.
Also coming to embedded.
So with the notable even being the end of the Linux rest experiment.
And I know some vendors of embedded products that they are rewriting their stacks.
It memory safe languages.
And then we also have AI.
That can be used to accelerate development.
It can be used to find vulnerabilities in the products.
Or submit completely bugger reports.
Depends.
And there are talks about the subject all around the first them.
So I'm not going to get into the details more on that.
All the dependencies and as well.
What do we have here?
Of course, I'm going to ask a question.
Who is already generating an as well?
Okay.
Less than a half.
Okay.
So it is currently working in the Octoproject.
It's working in Zephyr.
It's working for some air tosses.
Even some SDK vendors do provide.
As well, I haven't looked yet.
How accurate they look.
But the end result problem in embedded.
I did a whole talk about the subject this morning.
So if you try to merge as bombs.
For example, for multiple processors.
Into one.
To analyze this on that.
That's becoming those.
They're really complicated still.
And we have a result of problems on in the S bomb land.
One of them is how do we handle patched software.
It's pretty common in a bit.
And how we handle naming or false.
There's no good solution.
In there.
Another tendency that we have a lot in embedded is that.
People copy code like libraries.
Or just files somewhere.
And then other developer needs to deal with that ten years later.
Because of course those files haven't been updated for the last ten years.
And nobody was aware that it was there.
And then.
We have our favorite Wi-Fi bluetooth and all the stacks that are running.
Processos internally with big software stacks on them.
That have a lot of other software libraries on them.
And we would like sometimes to.
Have a nest bomb to have an idea what.
How much of a number they are.
Especially if they are providing connectivity.
And that's that's also a very interesting and unsolved problem.
Um, this year I have also seen a lot of.
Attention on bootloaders.
A bootloader is something that is very close to your hardware.
And it can write to the memory.
Wherever it was right.
And they can.
If you can confirm if an attacker can compromise a bootloader.
Then they can compromise the whole of your embedded system.
So there are two interesting talks.
I recommend you to have a look at this at the slide deck.
One above hardening variables and other about finding vulnerabilities in your boot.
And I think that this is going to count as a tendency over the next year too.
Because there's a lot of work to do.
And also on those lower level.
In parts of the stack.
And then on the vulnerabilities side.
I wanted to show you a tendency.
A choice of three vulnerabilities that affect.
That was discovered last year and effect embedded.
If you have a look at the short descriptions.
All of them are related to the code.
Parts in data that comes either from remote service.
Or is given by the user.
So those are not memory safety issues.
Those are issues of parsing actual messages.
That could be controlled by attacker.
We've known many embedded devices that we're trusting everything that is being sent to it.
Not, not, not a good choice.
So to wrap up.
There's a lot of going on.
We have regulations.
We have changes in cryptography.
And I see more and more interest in security subjects.
For example, at the ERT version, we have a separate track on security.
Something I've never seen before.
So that's pretty interesting.
And a lot of security docs are different embedded conferences.
That's, I find that's good.
I will be doing series of setups to resemble information from different subjects.
If you have something that should show up in a future edition of such a talk,
I'm easy to find online.
Let me know.
So do we have time for questions?
Maybe.
Thanks as ever, Marta.
Just going back to manufacturing and risks and obligations.
If we produce OEM hardware with the software stack,
it might be October's effort on top of that.
We sell that into vertical markets as our product to them.
And then they sell on box it up and sell it as part of their service.
Does that mean we're both manufacturers.
And we both have manufacturing obligations.
Or how does that split out?
And what do we need to be doing as we sell on before something actually hits,
as an end product into the market, if that makes sense?
So first, I'm not a lawyer.
A lawyer is somewhere else in this room.
So the situation correctly, there is new manufacturing devices,
and selling them to your customers,
then they are repackaging, adding stuff and selling that again.
In my opinion, they are both manufacturers,
because you are putting devices on the market,
and they are also putting devices on the market.
So in my opinion, they are both manufacturers.
I didn't manage to stop thinking about Syria.
Maybe another question.
We are out of time.
We are on time.
Thank you.
Thank you all for coming.
Thank you.