Most embedded manufacturers know they need Secure Boot, secure OTA updates, and vulnerability handling under the EU Cyber Resilience Act.

But one requirement is becoming just as important:

A clear, machine-readable SBOM.

For embedded and IoT products, the SBOM requirements EU CRA embedded firmware teams need to understand are not just about creating a list of open-source libraries. A proper Software Bill of Materials connects firmware, bootloaders, operating systems, third-party components, build dependencies, and software supply chain evidence into one structured record.

That matters because CRA compliance is not only about building secure products.

It is about proving what is inside your product, tracking vulnerabilities across the lifecycle, and responding quickly when a component risk appears.

If your embedded product contains firmware, an RTOS, embedded Linux, a bootloader, third-party libraries, cryptographic packages, device drivers, or cloud-connected software, SBOM readiness should be part of your compliance roadmap now.

What Is an SBOM?

An SBOM, or Software Bill of Materials, is a structured inventory of software components used inside a product.

Think of it as a product ingredient list for software and firmware.

For embedded firmware, an SBOM may include:

• Bootloader components
• Firmware modules
• RTOS packages
• Embedded Linux packages
• Kernel version
• Board support package components
• Middleware
• Device drivers
• Cryptographic libraries
• Open-source libraries
• Third-party SDKs
• Vendor-supplied binary blobs
• Build tools and toolchain references
• Application software
• Cloud or device-agent components

A good SBOM does more than list names. It should help answer practical engineering and compliance questions:

• Which software components are inside this firmware release?
• Which versions are used?
• Which licenses apply?
• Which dependencies are included?
• Which components are affected by known vulnerabilities?
• Which firmware image contains the affected component?
• Which deployed products or customers may be impacted?

For embedded manufacturers, this visibility is essential because products often stay in the field for years.

Why SBOM Matters Under the EU CRA

The EU Cyber Resilience Act changes how manufacturers must think about software supply chain transparency.

Under the CRA, manufacturers need to identify and document vulnerabilities and components contained in products with digital elements. This includes drawing up a Software Bill of Materials in a commonly used and machine-readable format, covering at least the top-level dependencies of the product.

In practical terms, this means embedded manufacturers cannot treat SBOM as a nice-to-have engineering file.

It becomes part of the evidence chain for:

• Vulnerability management
• Product security documentation
• Technical file preparation
• CRA conformity assessment
• Supply chain transparency
• Incident response
• Secure update planning
• Long-term product support

A secure product without component visibility is difficult to maintain.

A firmware product without an SBOM is difficult to assess when a new CVE appears.

And a deployed IoT device without release-to-component traceability can turn vulnerability response into guesswork.

 

SBOM Requirements EU CRA Embedded Firmware Teams Should Understand

For embedded firmware products, CRA SBOM readiness should focus on five practical requirements.

1) The SBOM Must Be Machine-Readable

The CRA expects SBOMs to be prepared in a commonly used and machine-readable format.

That means a spreadsheet is not enough.

A spreadsheet may be useful for internal review, but it is not the right long-term format for automated vulnerability management, tooling, and compliance exchange.

Common machine-readable SBOM formats include:

• CycloneDX
• SPDX

These formats allow security tools, vulnerability scanners, compliance systems, and customers to process SBOM data automatically.

This matters because CRA vulnerability handling is time-sensitive. If your team has to manually inspect spreadsheets every time a vulnerability is disclosed, the process will not scale.

2) The SBOM Should Cover at Least Top-Level Dependencies

The CRA text refers to covering at least top-level dependencies.

For embedded teams, this is the baseline, not the ambition.

Top-level dependencies may include the major packages, libraries, firmware components, SDKs, and software elements directly included in the product.

But practical vulnerability management often requires deeper visibility.

For example, a firmware image may directly include a networking library, but that library may include or depend on other components. If you cannot see the dependency chain, you may miss exposure to a known vulnerability.

A stronger embedded SBOM should aim to include:

• Direct dependencies
• Transitive dependencies where possible
• Package versions
• Component relationships
• Supplier or origin information
• License data
• Hashes or identifiers
• Firmware release association
• Build environment references

The goal is not to create a perfect file on day one.

The goal is to create a repeatable SBOM process that improves over time.

3) The SBOM Must Be Linked to Firmware Releases

An SBOM is only useful if you know which release it belongs to.

For embedded firmware, every production firmware release should have a corresponding SBOM.

This should include:

• Firmware version
• Build ID
• Release date
• Product model
• Hardware revision
• Bootloader version
• OS or RTOS version
• SBOM format and version
• Build pipeline reference
• Signing or release approval reference

Without this linkage, your SBOM becomes disconnected documentation.

With release linkage, your team can quickly answer: “Which firmware versions contain the vulnerable component?”

That is the difference between controlled vulnerability response and operational chaos.

4) The SBOM Should Support Vulnerability Monitoring

The value of an SBOM is not only in storing component data.

It is in using that data.

A CRA-ready SBOM workflow should support vulnerability monitoring against CVE databases, supplier advisories, open-source security notices, and exploit intelligence.

For embedded products, this is especially important because vulnerabilities may appear after the device is already deployed.

A practical vulnerability workflow should connect:

• SBOM generation
• Component version tracking
• CVE monitoring
• Exploitability analysis
• Product impact assessment
• Patch planning
• Secure OTA update delivery
• Customer communication
• CRA reporting readiness

This is where SBOM supply chain CRA transparency becomes more than a compliance phrase. It becomes the foundation of product security operations.

Read Also: The September 2026 CRA Reporting Deadline

 

5) The SBOM Should Be Part of the Technical Documentation

The SBOM should not live in isolation.

It should connect to the broader CRA technical file and product security evidence.

That includes:

• Product architecture
• Firmware architecture
• Secure Boot evidence
• Secure OTA strategy
• Vulnerability handling procedure
• TARA / threat analysis
• Security test reports
• Support period documentation
• EU Declaration of Conformity evidence
• Conformity assessment records

In other words, SBOM is one part of a larger CRA compliance story.

It helps prove that the manufacturer understands what is inside the product and can manage risk throughout the lifecycle.

CycloneDX SBOM Embedded: When to Use It

CycloneDX is one of the most widely used SBOM formats for modern software supply chain security.

For embedded products, a CycloneDX SBOM embedded workflow can be especially useful because CycloneDX supports software, hardware, services, dependencies, vulnerabilities, cryptographic assets, and other product transparency use cases.

CycloneDX can be a strong fit when your team needs:

• Automation-friendly SBOM generation
• CI/CD integration
• Vulnerability management workflows
• Firmware component tracking
• SaaS, cloud, and device ecosystem visibility
• VEX and vulnerability context support
• Software supply chain transparency

For IoT and embedded products that include device software, cloud services, and update infrastructure, CycloneDX can help connect the product ecosystem more clearly.

A CycloneDX SBOM for embedded firmware may include:

• Firmware application components
• Embedded Linux packages
• RTOS components
• Third-party libraries
• Device agent software
• Open-source dependencies
• Cryptographic libraries
• Build-time metadata
• Supplier and license information

The main benefit is automation.

If your team wants an SBOM pipeline that connects to vulnerability scanning and release governance, CycloneDX is often a practical format to consider.

SPDX Firmware SBOM CRA: When to Use It

SPDX is another major SBOM format and is recognized as an international open standard.

An SPDX firmware SBOM CRA workflow may be especially useful for teams that need strong license compliance, open-source governance, and supply chain documentation.

SPDX can be a good fit when your organization needs:

• Standardized license identification
• Open-source compliance tracking
• Component-level documentation
• Supplier communication
• Long-term product support evidence
• Integration with legal and compliance workflows

For embedded Linux products, SPDX is often relevant because Linux distributions, Yocto-based builds, and open-source dependency management already involve license and package metadata.

An SPDX SBOM can help teams document:

• Package names
• Version information
• License data
• File-level details where needed
• Component relationships
• Supplier or origin information
• Checksums and identifiers

For CRA compliance, the key is not choosing a fashionable format.

The key is choosing a format your team can generate reliably, validate, maintain, and use during vulnerability response.

CycloneDX vs SPDX for CRA SBOMs

Both CycloneDX and SPDX can support CRA SBOM needs.

The better choice depends on your product, tooling, customer expectations, and internal workflow.

Format	Strengths	Good Fit For
CycloneDX	Security automation, vulnerability management, dependency relationships, modern supply chain workflows	IoT platforms, firmware pipelines, cloud-connected products, vulnerability response
SPDX	Open-source license compliance, standardized component identification, legal and supply chain documentation	Embedded Linux, open-source-heavy firmware, compliance documentation, supplier review

Some companies may even support both formats depending on customer needs.

For example, an internal pipeline may generate CycloneDX for vulnerability management and SPDX for open-source license documentation.

The CRA does not force manufacturers to choose one specific format today. What matters is that the SBOM is commonly used, machine-readable, accurate, and useful for vulnerability handling.

How to Generate a CRA SBOM for Embedded Firmware

Generating an SBOM for embedded firmware is more complex than generating one for a web application.

Embedded products often use custom build systems, patched libraries, cross-compilers, vendor SDKs, binary blobs, board support packages, and long-lived firmware branches.

Here is a practical step-by-step process.

Step 1: Define the Product Boundary

Before generating an SBOM, define what the product includes.

Ask:

• Is the product firmware-only, or does it include cloud services?
• Does the device depend on a mobile app or dashboard?
• Is remote data processing essential to the product?
• Does the OTA update infrastructure count as part of the product ecosystem?
• Which hardware variants share the same firmware?
• Which third-party SDKs are included?

For CRA purposes, product boundaries matter because they affect what needs to be documented and monitored.

For embedded products, the SBOM should normally cover the software elements that ship with or support the product’s intended function.

Step 2: Inventory the Firmware Architecture

Create a structured view of the firmware stack.

This may include:

• Boot ROM assumptions
• Bootloader
• Secure Boot components
• RTOS or embedded Linux
• Kernel
• Drivers
• Middleware
• Networking stack
• Cryptographic libraries
• Application layer
• Device agent
• OTA client
• Configuration files
• Third-party libraries
• Vendor SDKs

This inventory becomes the starting point for SBOM generation.

If you cannot describe the firmware architecture, automated tools will not solve the problem for you.

Step 3: Choose the Right SBOM Format

Choose CycloneDX, SPDX, or both.

For many embedded manufacturers:

• CycloneDX is useful for security automation and vulnerability workflows.
• SPDX is useful for open-source license and compliance traceability.

The choice should be based on your project needs, customer expectations, and toolchain.

For example:

• A Yocto-based embedded Linux device may already produce package and license metadata that can support SPDX workflows.
• A cloud-connected IoT product may benefit from CycloneDX because of its broader supply chain and vulnerability management capabilities.
• A regulated customer may request a specific format during procurement or technical review.

The most important rule: do not create an SBOM format your team cannot maintain.

Step 4: Select SBOM Generation Tools for IoT and Embedded Systems

There are many SBOM generation tools IoT and software supply chain tools available, but embedded environments require careful selection.

Your tool should support your actual build system.

Common inputs may include:

• Yocto build metadata
• Buildroot package data
• CMake projects
• Makefiles
• Cargo / Rust packages
• npm or Node.js components
• Python packages
• Linux package manifests
• Container images
• Vendor SDK metadata
• Binary analysis where source metadata is limited

For embedded firmware, no single tool catches everything perfectly.

That is why a hybrid approach is often needed:

• Build-system generated SBOM
• Source dependency analysis
• Package manager metadata
• Manual supplier component declarations
• Binary or firmware image inspection
• Internal review for patched or vendored components

The goal is to generate the best possible machine-readable SBOM and then improve accuracy over time.

Step 5: Include Supplier and Vendor Components

Embedded products often include components that do not come from public package managers.

These may include:

• Vendor SDKs
• HAL libraries
• Closed-source drivers
• Wireless modules
• Security libraries
• Modem firmware
• Bootloader code
• Precompiled binaries
• Third-party protocol stacks

These components still matter.

If a supplier component has a vulnerability, your product may be affected.

Your SBOM process should record:

• Supplier name
• Component name
• Version
• Origin
• License or usage terms
• Hash or identifier
• Product versions affected
• Update source
• Support status

This is where supply chain transparency becomes real.

Step 6: Generate SBOMs During the Build

A CRA-ready SBOM should not be created manually at the end of a project.

It should be generated as part of the firmware build and release process.

An automated SBOM pipeline may look like this:

1. Developer commits code
2. CI pipeline builds firmware
3. SBOM tool collects component data
4. SBOM is exported in CycloneDX or SPDX format
5. SBOM is validated
6. Vulnerability scan runs against the SBOM
7. Security review checks high-risk findings
8. Firmware image is signed
9. SBOM is archived with the release
10. Release evidence is stored for CRA documentation

This creates repeatability.

Every release has an SBOM.

Every SBOM links to a firmware image.

Every firmware image links to security evidence.

That is what manufacturers need for scalable CRA compliance.

Step 7: Validate SBOM Quality

An SBOM that is incomplete, inaccurate, or disconnected from the real build can create false confidence.

Validation should check:

• Is the SBOM machine-readable?
• Does it use a valid CycloneDX or SPDX schema?
• Are component names consistent?
• Are versions included?
• Are supplier components captured?
• Are top-level dependencies included?
• Are transitive dependencies included where possible?
• Are licenses recorded?
• Are hashes included where useful?
• Is the SBOM linked to the correct firmware release?
• Can vulnerability tools process it?
• Can engineering explain what is missing?

A good SBOM should be honest.

If some components cannot be fully identified, document the limitation and define a plan to improve.

Step 8: Connect SBOM to Vulnerability Handling

An SBOM is not the end of the process.

It is an input into vulnerability management.

A CRA-ready workflow should connect SBOM data to:

• CVE monitoring
• Exploitability analysis
• Triage decisions
• Security patch planning
• OTA update planning
• Customer notification
• CRA reporting readiness
• Technical documentation updates

For example, if a vulnerability is disclosed in a cryptographic library, your team should be able to answer:

• Do we use this library?
• Which version do we use?
• Which firmware releases include it?
• Which products are affected?
• Is the vulnerable function reachable?
• Is exploitation possible in our product context?
• Do we need a patch, mitigation, or update?
• Do we need to notify users or authorities?

Without an SBOM, those answers take longer and may be less reliable.

Step 9: Archive SBOMs for the Product Lifecycle

Embedded products often have long support periods.

That means SBOMs must be retained and maintained across the product lifecycle.

Your archive should include:

• SBOM per firmware release
• Firmware binary or image reference
• Build logs
• Release approval record
• Vulnerability scan results
• VEX or exploitability decisions where used
• Patch history
• OTA release logs
• Customer or deployment mapping where appropriate

This helps show that your product security process is not a one-time activity.

It is an ongoing lifecycle security.

Common SBOM Mistakes Embedded Teams Should Avoid

Mistake 1: Creating an SBOM Once and Forgetting It

An SBOM is only useful if it reflects the product version in the field.

Every firmware release should have its own SBOM.

Mistake 2: Treating a Spreadsheet as the Final SBOM

A spreadsheet can help during early inventory work, but CRA-aligned SBOMs should be machine-readable and suitable for automated processing.

Mistake 3: Ignoring Vendor SDKs and Binary Components

Many embedded products rely on supplier code, closed-source libraries, and precompiled binaries.

Ignoring them creates blind spots in your supply chain visibility.

Mistake 4: Not Linking SBOMs to Firmware Versions

If the SBOM is not linked to a firmware release, it cannot support rapid vulnerability response.

Mistake 5: Assuming Tools Catch Everything

SBOM tools help, but embedded firmware often includes custom components, patched libraries, and vendor code that tools may not identify automatically.

Engineering review still matters.

Mistake 6: Not Using the SBOM for Vulnerability Response

An SBOM that is never checked against vulnerabilities is just stored documentation.

The real value comes when it supports triage, patching, reporting, and lifecycle security.

What Should Be Included in an Embedded Firmware SBOM?

A practical embedded firmware SBOM should include:

• Product name
• Product model
• Firmware version
• Build ID
• SBOM format and version
• Component names
• Component versions
• Component type
• Supplier or origin
• License information
• Dependency relationships
• Package URLs or identifiers where available
• Hashes or checksums where useful
• Bootloader and OS components
• Third-party libraries
• Vendor SDKs
• Cryptographic libraries
• Known limitations
• Release date
• Responsible team or owner

The exact structure may vary, but the SBOM should be detailed enough to support vulnerability response and compliance review.

Example: SBOM Workflow for an Embedded Linux Product

A manufacturer building an embedded Linux gateway may use this workflow:

1. Yocto build generates package and license metadata
2. CI pipeline exports an SPDX firmware SBOM
3. A CycloneDX SBOM is generated for security tooling
4. The SBOM is validated against schema rules
5. CVE scanning checks vulnerable packages
6. Engineering reviews exploitability in product context
7. Firmware is signed and released
8. SBOM, test evidence, and build logs are archived
9. OTA update system tracks deployed firmware versions
10. Vulnerability handling process monitors future risks

This turns SBOM from a compliance file into a product security control.

Example: SBOM Workflow for an MCU Firmware Product

A manufacturer building MCU firmware may not have package manager metadata.

In that case, the workflow may look different:

1. Engineering defines firmware modules manually
2. Vendor SDKs and HAL libraries are inventoried
3. Third-party C/C++ libraries are listed with versions
4. Build scripts identify compiled modules
5. SBOM is generated or assembled in CycloneDX or SPDX
6. Supplier components are documented
7. Cryptographic libraries and update components are tagged
8. Firmware image is linked to the SBOM
9. SBOM is reviewed during release approval
10. Vulnerability tracking continues during support period

For MCU products, SBOM generation may require more engineering discipline because the ecosystem is often less automated.

How Epteck Helps With CRA SBOM Generation

At Epteck GmbH, we help embedded and IoT manufacturers turn SBOM requirements into a practical, automated engineering workflow.

Our CRA SBOM support includes:

• SBOM readiness assessment
• Firmware architecture inventory
• CycloneDX SBOM embedded workflow setup
• SPDX firmware SBOM CRA documentation
• SBOM tool selection for embedded and IoT products
• Automated SBOM pipeline integration
• Yocto, Buildroot, Linux, RTOS, and MCU firmware support
• Vendor SDK and third-party component tracking
• SBOM validation and quality review
• Vulnerability monitoring workflow design
• Secure OTA and SBOM release traceability
• CRA technical documentation alignment

We help teams move beyond manual spreadsheets and build SBOM processes that support real product security, vulnerability response, and EU CRA compliance.

Explore our CRA readiness assessment

 

Conclusion: A CRA SBOM Is More Than a Component List

For embedded manufacturers, SBOM is not just a compliance document.

It is the foundation of firmware transparency, vulnerability response, supply chain security, and long-term product support.

The EU CRA makes this especially important because manufacturers must be able to identify components, manage vulnerabilities, document evidence, and support products throughout their lifecycle.

A strong SBOM process should be:

• Machine-readable
• Repeatable
• Connected to firmware releases
• Integrated into CI/CD
• Validated for quality
• Linked to vulnerability monitoring
• Archived as compliance evidence

The companies that build SBOM pipelines early will be better prepared for CRA documentation, vulnerability reporting, CE alignment, and customer security reviews.

The best time to build your SBOM process is before a vulnerability forces you to.

FAQs

What are the SBOM requirements under the EU CRA for embedded firmware?

The EU CRA requires manufacturers to identify and document vulnerabilities and components in products with digital elements, including by drawing up an SBOM in a commonly used and machine-readable format that covers at least top-level dependencies. For embedded firmware, this means documenting firmware components, bootloaders, operating systems, libraries, vendor SDKs, and third-party software where applicable.

Is an SBOM mandatory under the EU Cyber Resilience Act?

Yes, the CRA includes SBOM as part of the vulnerability handling and component documentation expectations for products with digital elements. Manufacturers should prepare SBOMs as part of their technical documentation and lifecycle vulnerability management process.

What format should a CRA SBOM use?

The CRA refers to commonly used and machine-readable formats. CycloneDX and SPDX are two widely used SBOM formats. CycloneDX is often strong for security automation and vulnerability workflows, while SPDX is widely used for open-source license and supply chain documentation.

What is a machine-readable SBOM?

A machine-readable SBOM is structured in a format that software tools can automatically process. Examples include CycloneDX JSON/XML and SPDX JSON/RDF/tag-value formats. A manually maintained spreadsheet is not ideal for scalable CRA vulnerability management.

Should embedded firmware use CycloneDX or SPDX?

Both can be useful. CycloneDX is often practical for security automation, dependency tracking, and vulnerability management. SPDX is strong for open-source license compliance and standardized component documentation. Some manufacturers may use both depending on customer and internal requirements.

What components should be included in an embedded firmware SBOM?

An embedded firmware SBOM should include bootloaders, firmware modules, RTOS or embedded Linux packages, kernel components, drivers, middleware, cryptographic libraries, open-source libraries, vendor SDKs, third-party binaries, and key build or release metadata where relevant.

Can SBOM generation be automated for IoT products?

Yes. SBOM generation can be automated through CI/CD pipelines, build systems, package metadata, source analysis tools, and firmware release workflows. However, embedded products often require additional manual review for vendor SDKs, patched libraries, binary blobs, and custom build systems.

Why does SBOM matter for CRA vulnerability reporting?

SBOMs help manufacturers quickly determine whether a newly disclosed vulnerability affects their product. This supports vulnerability triage, secure update planning, customer communication, and CRA reporting readiness for actively exploited vulnerabilities or severe incidents.

Do I need an SBOM for every firmware release?

Yes, that is the practical best practice. Every production firmware release should have a corresponding SBOM linked to the firmware version, build ID, product model, hardware revision, and release evidence.

How can Epteck help with CRA SBOM generation?

Epteck helps embedded and IoT manufacturers create SBOM workflows for CRA readiness, including CycloneDX and SPDX setup, automated SBOM pipelines, firmware architecture inventory, Yocto and RTOS support, vulnerability monitoring workflows, secure OTA traceability, and audit-ready technical documentation.