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 today; bare-metal and RTOS images and hardware parts are on the roadmap.
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.
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 yet matched to advisories.
- Yocto and Buildroot manifests can be uploaded like an SBOM and are checked against OSV.dev.
- Bare-metal and RTOS images are reported as not analysable, never as clean.
Coming next
On the roadmap, not available yet. Dates are targets, not promises; this page changes the day a capability is live.
- Coming · Q1 2027Bare-metal and RTOS firmware. KROMSE will identify components in firmware without a Linux file system, such as bare-metal and RTOS images built on FreeRTOS or Zephyr.
- Coming · Q1 2027Hardware parts. KROMSE will match the hardware parts in your product against published hardware advisories.
- Coming · Q4 2026 (December)Robotics security. KROMSE will add ROS 2 advisories, component identification inside PX4 and ArduPilot firmware, and robot-specific vulnerability data.
Frequently asked questions
Can KROMSE scan FreeRTOS or Zephyr firmware?
Not as a binary image yet. KROMSE lists Zephyr and other embedded build manifests in its inventory, but component identification inside bare-metal and RTOS images is on the roadmap. 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.