Table of contents:
For years, embedded systems were treated as closed products: developers built the firmware, flashed the binary, shipped the product and moved on. However, the internal structure of these binaries was often a mystery even to the creators, with dependencies hidden deep within vendor SDKs, static libraries and build scripts.
That approach no longer fits today’s regulatory environment. Under the Cyber Resilience Act (CRA), manufacturers are legally obligated to track exactly what is inside their devices, verify the origin of every component and how they can be monitored over time.
For companies building connected devices, an SBOM is no longer an optional piece of documentation – it is a legal instrument for traceability, vulnerability response and market access. Read on to understand this specific landscape.
Defining the Cyber Resilience Act
The Cyber Resilience Act (CRA) is a European Union regulation that introduces legally binding cybersecurity standards for products with digital elements, including both hardware and software. This encompasses any software or hardware that connects to a network – ranging from industrial IoT sensors to consumer smartwatches.
In light of this, it is imperative that manufacturers be able to identify every component within their software – both proprietary and third-party – to facilitate rapid patching.
Its primary objective is to protect consumers and businesses from cyber threats in an increasingly connected landscape by ensuring that digital products are designed, developed and maintained securely throughout their entire lifecycle.
Critical CRA mandates and timelines
The CRA introduces strict obligations that matter directly to engineering teams: component traceability, vulnerability monitoring and impact assessment. The most demanding aspect is the reporting timeline – starting from September 11, 2026, manufacturers will be legally obliged to report actively exploited vulnerabilities or severe incidents within 24 hours of detecting them. A full notification must follow within 72 hours, with subsequent detailed reports as the investigation evolves.
This creates a great logistical challenge for companies without automated traceability. With the CRA fully in force by December 11, 2027, the window for transition is closing rapidly. Currently, many manufacturers are scrambling to update legacy processes. Building a CRA-ready workflow today is the only way to avoid a “mad dash” for compliance that could lead to forced shipment halts, hefty fines and market exclusion by next year.
The unique challenges of embedded SBOMs
At its core, a Software Bill of Materials (SBOM) is a nested inventory – a comprehensive “list of ingredients” that make up a software package. It is used to document every library, module and third-party dependency used in a build.
To meet CRA standards, this inventory must be exported in machine-readable formats like SPDX or CycloneDX. This standardization allows automated tools to cross-reference software components against global vulnerability databases (CVEs) in real time.
In cloud-native environments, generating an SBOM is relatively easy thanks to dependency managers, package metadata and runtime manifests that make composition visible. Embedded systems are far more complex. They often rely on static linking, copied source trees, binary blobs and long-lived toolchains.
That means the SBOM must be captured during the build phase, before structural information disappears in the final artifacts. In practice, the most useful SBOM comes from build inputs rather than from the .bin, .hex, or .elf outputs alone.
What an embedded SBOM should cover
A useful embedded SBOM goes far beyond application code. To manage risk effectively, you must map the entire stack. This includes internal modules, any integrated AI/ML models, middleware, RTOS or kernel components, Hardware Abstraction Layers (HAL) or Board Support Packages (BSPs), as well as the toolchain and build configuration used to produce the image.
A practical traceability model looks like this:
- Application layer: internal modules, models, configuration
- Middleware: networking, BLE, USB, protocol stacks
- OS or RTOS: FreeRTOS, Zephyr, schedulers, memory management
- Low-level layer: STM32 HAL, Nordic SDKs, BSPs
- Toolchain and build system: GCC version, linker scripts, build flags
Yocto as the gold standard for embedded Linux SBOMs
One of the clearest examples of how SBOM can work in embedded Linux is Yocto. It gives developers precise control over every layer – from the bootloader and kernel to the final application layer. The primary mechanism for this is the create-spdx.bbclass. When enabled, the build system automatically generates SPDX (Software Package Data Exchange) files in JSON format for every package and image, giving teams per-package and per-image visibility.
By automating the creation of high-fidelity, build-time SBOMs, it provides embedded teams with the rigorous software traceability required to satisfy CRA mandates for component visibility, rapid vulnerability response and long-term lifecycle compliance. This makes it a mature, production-ready framework for companies that need to move from “tooling gaps” to “process integration”.
At Software Mind, we have hands-on experience with Yocto-based Linux development and work closely with partners like Toradex whose Torizon platform is designed with CRA readiness in mind. By combining their hardware with our deep Yocto proficiency, we help manufacturers implement automated, high-fidelity SBOM generation that meets the strictest regulatory standards.
Zephyr and MCU systems
While Yocto handles high-performance Linux systems, Zephyr, one of the key real-time operating systems, is leading the charge for resource-constrained MCU environments. Zephyr’s architecture is built around a highly structured configuration system using West, CMake and Kconfig, which provides a natural trail of breadcrumbs for traceability.
In these systems, the SBOM reconstruction relies heavily on build manifests and configuration files rather than package managers. Recent updates to the Zephyr ecosystem have focused on integrating SPDX metadata directly into the build flow. This allows developers to export a granular list of dependencies automatically during compilation.
From “black box” firmware to CRA compliance
If you lack visibility into your firmware’s internal components, you cannot effectively manage risk or meet the CRA’s aggressive response windows. In the modern regulatory landscape, an SBOM is no longer just a documentation but a core pillar of secure embedded engineering.
A CRA-ready workflow should look like this: build, generate SBOM, archive the artifact and keep the component map linked to device deployments so that vulnerability response can be executed quickly when needed.
Our embedded software services are designed specifically to help manufacturers navigate this transition. By mapping out exactly what’s inside every device you ship, we help your team tackle vulnerabilities in hours rather than weeks – keeping your products safe, your customers protected and your EU market access legally compliant and secure. Don’t let the CRA deadlines catch you off guard. Contact our experts to automate your compliance pipeline.
FAQ
Does the CRA apply to legacy products I’ve already shipped?
Yes, in terms of reporting. While the “secure-by-design” requirements primarily apply to products placed on the market after December 2027, the vulnerability reporting obligations (starting September 2026) apply to all products currently available on the market, regardless of when they were first launched. If a legacy device is still being sold or supported in the EU, you must have a way to detect and report vulnerabilities within the 24-hour window.
Am I responsible for the security of open-source software I use?
Yes. While the CRA provides some exemptions for pure “open-source contributors,” the moment a manufacturer integrates open-source code into a commercial product, they inherit full legal responsibility for its security. You must include these components in your SBOM and have a plan for patching them if the upstream community stops providing updates.
What happens in case of non-compliance with the CRA?
Failure to comply with the CRA carries severe consequences:
- Fines: up to €15 million or 2.5% of global annual turnover (whichever is higher).
- Market withdrawal: removal of the product from sale or the entire EU market.
- Market prohibition: non-compliant products are prohibited from bearing the CE mark.
- Supply chain impact: your customers may be unable to use your product as part of their own CRA-compliant systems.
About the authorRadosław Kotewicz
Software Delivery Director
A business and technical consultant experienced with IT and connectivity standards organizations, Radoslaw has been working in the IT and Internet of Things (IoT) industries for over 15 years. His broad expertise, in embedded systems engineering and project management, has enabled him to support the development of IoT products and solutions for the last eight years. He has also been involved in creating certification test tools throughout his career, including a wireless automated charging test system.
