Firmware security
Embedded firmware security for RTOS and bare-metal devices
Embedded firmware security means knowing which components run on a microcontroller or RTOS device and keeping them free of known vulnerabilities, even when there is no operating system to inspect. KROMSE covers Linux-based firmware; it does not cover bare-metal and RTOS images or hardware parts.
Free plan, no card required.
Why RTOS and bare-metal firmware are hard to scan
Linux-based firmware carries a file system with package databases and separate binaries, so a scanner can unpack it and read what is inside. Bare-metal and RTOS firmware is usually one statically linked blob: the application, the RTOS kernel (FreeRTOS, Zephyr, ThreadX, NuttX and others), network stacks such as lwIP and cryptography libraries such as Mbed TLS or wolfSSL are compiled together without names or version files.
Identifying components in such an image requires signatures of known code or build metadata from the vendor. Without either, an honest scanner can only say that nothing could be extracted.
Responsible for a connected device? See security for connected devices.
Start from the build, not the binary
For embedded products the most reliable inventory usually comes from the build system, because the manufacturer has it and a scanner looking at the binary does not.
- Zephyr: the west manifest (west.yml) pins modules and their revisions.
- ESP-IDF: idf_component.yml and the dependencies lock file list managed components.
- PlatformIO and Arduino: platformio.ini, library.properties and sketch files name libraries.
- Conan and vcpkg: lockfiles record C and C++ package versions.
- Yocto and Buildroot: image and licence manifests list every package in a Linux build.
What the Cyber Resilience Act expects
The CRA makes no exception for small devices. A microcontroller product with a network connection is a product with digital elements; its manufacturer needs an SBOM covering at least the top-level dependencies, a vulnerability-handling process, security updates for the support period and Article 14 reporting.
Several component types appear in the Regulation's lists of important products, such as microprocessors and microcontrollers with security-related functionalities in class I, and tamper-resistant microprocessors and microcontrollers in class II, which brings stricter conformity assessment.
Hardware parts are part of the picture
Vulnerabilities are also published against hardware: processors, radio chipsets, secure elements. A hardware bill of materials lets a manufacturer check which of its products use an affected part. The CRA's SBOM requirement concerns software, but vulnerability handling covers the whole product.
Updates for devices in the field
Finding a vulnerable component is only half the obligation. The CRA requires security updates to be distributed securely and without delay for the whole support period, which must be at least five years unless the product is expected to be used for less, and each update must stay available for at least ten years or the rest of the support period.
For microcontroller products that means planning the update path at design time: a secure boot chain, signed images, enough flash for a fallback image, and a way to reach devices that are rarely connected. Retrofitting these after launch is usually impossible.
Practical steps now
Until tools can read every image, the manufacturer's own records carry most of the weight.
- Keep the build manifests and lockfiles for every released firmware version.
- Record the RTOS, network stack and crypto library versions per product.
- Subscribe to the security advisories of each RTOS and library you ship.
- Plan how devices in the field receive security updates for the support period.
Available in KROMSE today
What KROMSE covers for embedded products today:
- Linux-based firmware images: unpacked, inventoried and checked against known vulnerabilities.
- Embedded build manifests are listed in the inventory (Zephyr west.yml, ESP-IDF, PlatformIO, Arduino, Conan, vcpkg, CMake, Yocto and Buildroot); most are not matched to advisories.
- Yocto and Buildroot manifests can be uploaded like an SBOM; their components carry no package identifier, so they are listed in the inventory and not checked against OSV.dev.
- Bare-metal and RTOS images are reported as not analysable, never as clean.
Frequently asked questions
Can KROMSE scan FreeRTOS or Zephyr firmware?
Not as a binary image. KROMSE lists Zephyr and other embedded build manifests in its inventory, but component identification inside bare-metal and RTOS images is not supported. A scan of such an image reports that nothing could be extracted.
Does the CRA apply to microcontroller devices?
Yes, if the device is a product with digital elements with a direct or indirect data connection. Size does not matter. Microprocessors and microcontrollers with security-related functionalities are listed among the important products in Annex III.
What is a hardware bill of materials?
A list of the hardware components in a product, such as processors, radio chipsets and secure elements, with part numbers. It lets a manufacturer find out quickly which products use a part that has a published vulnerability.
Does the support period apply to small devices too?
Yes. Every product with digital elements needs a support period that reflects its expected use time and is at least five years unless the product is expected to be used for less. Security updates must be provided for that period, so the update mechanism has to be designed in from the start.
How do I build an SBOM for RTOS firmware?
Start from the build system: the Zephyr west manifest, ESP-IDF component lock files, PlatformIO configuration or Conan and vcpkg lockfiles record what went into the image. Convert them into CycloneDX or SPDX and keep one per release.