Published: December 29, 2025
Last modified: December 29, 2025
It has now been more than a year since I started running the “Embedded Security| course, and this feels like a good moment to pause and reflect.
First and foremost, thank you. Thank you to everyone who attended a session, asked hard questions, shared real-world constraints, and brought concrete examples from your own products. These courses were never meant to be a one-way transfer of knowledge. And they never were.
While participants came to learn about embedded security, regulations, tooling, and practices, I learned just as much from you.
I learned how teams really work under pressure, in domains I have never worked in.
I learned where theory meets reality when you are not a security person – and where it breaks.
I learned which security advice is actionable, and which remains aspirational when faced with deadlines, legacy hardware, or supplier constraints.
This continuous feedback loop is precisely what made the course evolve.
Why Embedded Security Still Feels Hard
Many participants arrive with the same underlying frustration: building secure embedded systems feels disproportionately hard.
And that feeling is legitimate.
Embedded security is difficult because products are often developed under tight budgets and immovable deadlines, using legacy building blocks that were designed at a time when security was not a primary concern. In many organizations, shipping a prototype that slowly turns into a product has become the norm. Security is then expected to be “added” later, usually when it is already expensive and disruptive. And when you can’t change your assumptions anymore.
In that context, secure-by-design can sound unrealistic.
A Different Way to Look at the Problem
However, the courses repeatedly show something else.
If you value quality and gradual improvement, embedded security does not have to be an all-or-nothing effort. You can start improving a product in a matter of days, not years, and then keep building on those improvements week after week.
Past participant tell me that it worked for them, all the time!
This is where the Pareto principle applies remarkably well. Roughly twenty percent of the changes can bring eighty percent of the impact. Clarifying your threat model, fixing basic configuration issues, adding hardening, or simply knowing what software you ship already changes the security level significantly.
You do not need massive investments to get started. What you need is clarity on where to start, and a shift in mindset: from “security as a blocker” to “security as an engineering discipline that can be incrementally improved.”
It isn’t 0 or 1. It is a gradual process.
A Course That Evolves With the Ecosystem
The course itself has evolved alongside these discussions.
We worked on the content, updates examples, adjusted tooling, added entire sections based on your feedback and changes in the ecosystem. This will continue in 2026.
Some evolutions are obvious, such as the move to the next Yocto Project LTS. Others go into other areas like secure boot, bootloader security, setting up your own vulnerability management practices, and how embedded products are assessed and maintained over time.
And there is more planned.
Looking Ahead to 2026
If embedded security is something you want to tackle seriously in the coming year – not as a checkbox, but as a sustainable engineering practice – this might be the right moment.
Early 2026 “Embedded Security” sessions are now open. Following repeated requests for better long-term planning, sessions are scheduled through April 2026, giving teams time to plan, budget, and convince your boss align internally.
If this resonates with your own ambitions, you can find more details and registration information here: https://ygreky.com/embedded-security-yp/
I look forward to continuing this shared learning journey.
See you in 2026!
Marta with team
20261229-Embedded-Security-Early-2026