CEC – Secure MCUs and RTOSs
Many embedded systems today must be secure. Many of these devices also have complex timing requirements that also require an RTOS. In this course, we will explore the capabilities of modern secure microcontrollers and how to select them. We will explore their hardware isolation mechanisms, and software stacks like trusted firmware for cortex-m. In addition, we will explore how to keep applications secure by exploring secure real-time operating systems and how they fit into the secure system ecosystem.
There are no hardware requirements for this course.
Registration and Playback are located here (May require login to access)

May 26 – Day 1 – Threat Model Security Analysis (TMSA)
The selection of secure microcontrollers and RTOSs depends on the security requirements of the system being designed. Teams will often jump to part and software stack selection before fully understanding their security requirements which can put the quality of their security solution in jeopardy. In this session, we will explore how to analyze the security needs of a system using a technique known as a Threat Model Security Analysis (TMSA).
May 27 – Day 2 – Secure Microcontroller Solutions
There are a wide variety of hardware solutions developers can leverage to secure their embedded systems. In this session, we will explore secure microcontroller technologies such as memory protection units, secure and unsecure memory and processing, secure peripherals, multicore solutions, and more.
May 28 – Day 3 – Arm TrustZone
A common solution for securing microcontroller applications is to use Arm TrustZone. In this session, we will explore how to configure TrustZone and design secure applications. Attendees will learn how TrustZone works, how to configure secure and non-secure memory, peripherals, and actions developers can take if a security incident is detected by the processor.
May 29 – Day 4 – Secure Boot and Firmware Updates
A key component in securing an embedded system is securely booting the system and performing secure updates. In this session, we will explore the secure boot boot and update process. Attendees will learn the various techniques that can be used to securely boot their system, gain insights into open source solutions, and other techniques they can apply to their own designs.
May 30- Day 5 – Secure RTOSes
Secure products that use a microcontroller often still require deterministic real-time behaviors. In some applications, a standard RTOS might do, but a secure RTOS can make a big difference. In this session, we will explore the capabilities of secure real-time operating systems and the role they play in secure embedded systems.
Course Resources
Jacob’s General Embedded Software Resources
- Sign-Up for the Embedded Bytes Newsletter here
- Book: Embedded Software Design here
- Developing Reusable Firmware – A Practical Guide to API’s, HAL’s and Drivers here
- MicroPython Projects Book here
- Jacob’s YouTube Channel – here
Additional Course Resources
Struggling to keep your development skills up to date or facing outdated processes that slow down your team, raise costs, and impact product quality?
Here are 4 ways I can help you:
- Embedded Software Academy: Enhance your skills, streamline your processes, and elevate your architecture. Join my academy for on-demand, hands-on workshops and cutting-edge development resources designed to transform your career and keep you ahead of the curve.
- Consulting Services: Get personalized, expert guidance to streamline your development processes, boost efficiency, and achieve your project goals faster. Partner with us to unlock your team's full potential and drive innovation, ensuring your projects success.
- Team Training and Development: Empower your team with the latest best practices in embedded software. Our expert-led training sessions will equip your team with the skills and knowledge to excel, innovate, and drive your projects to success.
- Customized Design Solutions: Get design and development assistance to enhance efficiency, ensure robust testing, and streamline your development pipeline, driving your projects success.
Take action today to upgrade your skills, optimize your team, and achieve success.
Just on the project involving secure firmware. The SW is Open Source but the HW docs comes with NDAs so really I am muzzled about details, unfortunately.
My impression is that the crypto and security specialists in most part should be forbidden from writing any code or writing the user documentation. The situation somewhat improved from the times of SSL debacle (where you could find a macro called “n” :-/ .. among other “flowers” ), but not that much considering the sizes of libraries exploded with the proliferation of the embedded system targets.
The build system concept and implementation is just ridiculous and awful, this opinion is shared across the team, which is compromised both with internal (us, as contractors) and external (client personnel) engineers, so you cannot blame the team/company cultural bias.
The code is full of comments where the code is documenting itself sufficiently, and lacking any comments where they actually would be helpful.
The HW documentation should be “decrypted” by some bona fide technical writers, unfortunately I think this profession is dying on the false assumption that Doxygen and HW engineers technical notes are good enough (they ARE NOT).
Of course all these problems will be solved soon by the AI so why worry … (BTW: AI == Artificial Idiocy).