SBOM for legacy embedded firmware: building one from binaries when source is gone

Most CRA SBOM guidance assumes you build your firmware from source — Yocto, Buildroot, a Make pipeline you control. Real product portfolios do not look like that. A typical hardware manufacturer carries a long tail of legacy SKUs: products designed in 2018 with vendor SDKs from 2017, firmware images from a supplier that has since been acquired, factory-installed binaries with no source-of-truth recipe, and pre-CRA inventory still being shipped from EU warehouses.

This article walks the practical workflow for producing an honest, defensible SBOM from a legacy firmware binary when the source-controlled build path is not available. For the tool-by-tool comparison see the SBOM tooling for embedded systems guide; for the CRA scope question on legacy products see CRA for existing products already on the EU market.

The legacy SBOM problem in one paragraph

You have a firmware image. You did not build it from source. You may not have access to the build recipe, the supplier may be uncooperative or defunct, the source may have been lost in a corporate acquisition, the development team may have moved on. The European Commission still expects you to be able to identify vulnerabilities in components contained in the product per CRA Annex I Part II. The honest answer is that any SBOM you produce will be partial. The compliance answer is that you document the methodology, scan with multiple complementary tools, and explicitly state the residual-risk surface.

Step 1 — capture and hash the firmware artifact

Before extraction, get the exact binary that ships to customers. Sources:

• Vendor portal download (current firmware release)
• Over-the-air update payload captured on a representative device
• JTAG or SWD flash dump from a known-good device
• Factory image archive from the original manufacturing partner
• Vendor SDK distribution if it includes the deployed image

Record both SHA-256 and SHA-512 hashes of the captured artifact. Every downstream SBOM document — and the residual-risk statement — must reference this hash. This is the only way to prove to a market surveillance authority that the SBOM was generated from the exact binary that shipped, not from a build that drifted.

Store the firmware artifact in a write-once artifact repository alongside the SBOM, the extraction logs and the residual-risk register.

Step 2 — identify the container format with Binwalk

Binwalk was rewritten in Rust and released as v3.1.0 on 31 October 2024. Per the README:

"Binwalk can identify, and optionally extract, files and data that have been embedded inside of other files."

Run binwalk image.bin to identify embedded file types. Typical signatures in embedded Linux firmware:

• SquashFS — read-only rootfs (most common modern signature)
• JFFS2 / UBIFS — read-write flash partitions
• CramFS — older read-only systems
• ext2/3/4 — raw Linux filesystems on flash or disk images
• YAFFS / YAFFS2 — NAND flash filesystems
• U-Boot images, FIT images, vendor wrappers — boot containers

The entropy plot (binwalk -E image.bin) flags compressed or encrypted regions. A flat high-entropy region with no recognisable signatures often indicates encryption — that section's contents are opaque without the vendor's key.

Step 3 — extract the rootfs and component partitions

Binwalk's --extract mode handles most common filesystems. For specific types you may want dedicated tools:

• unsquashfs for SquashFS — preserves permissions and symlinks reliably
• jefferson or jffs2dump for JFFS2 — slower but handles bit-flip recovery
• ubidump or ubireader for UBIFS — handles UBI volume layering
• dd plus mount -o loop for raw ext2/3/4 — read-only mount for safety

Preserve the directory structure. Most downstream SBOM tooling needs intact /var/lib/dpkg, /var/lib/apk, /etc/yum.repos.d or equivalent package-manager state to enumerate installed packages.

If a section is encrypted or signed-and-locked (e.g. a vendor's secure boot stage, a signed coprocessor blob, a DRM partition), document the partition as an opaque component with its hash, name and a justification — do not attempt unauthorised decryption.

Step 4 — scan with Syft for a baseline SBOM

Run Syft against the extracted rootfs:

syft dir:extracted/rootfs -o cyclonedx-json=sbom.cdx.json -o spdx-json=sbom.spdx.json

Syft will:

• Read Linux package-manager databases: Alpine (apk), Debian (dpkg), RPM
• Parse language-specific manifests where they exist: requirements.txt, package-lock.json, go.sum, composer.lock, Cargo.lock, *.gemspec
• Identify ELF binaries with retained metadata (Go build info, Python embedded interpreters)

The output covers everything Syft can confidently identify. Statically-linked libraries that were compiled into a binary, stripped ELFs without symbols, and in-house libraries with no package-database entry will not appear. Save the JSON outputs to the artifact repo immediately.

Step 5 — cross-check with Trivy and CVE-bin-tool

Run Trivy on the same rootfs:

trivy rootfs --format cyclonedx --output trivy-sbom.cdx.json extracted/rootfs
trivy rootfs --format spdx-json --output trivy-sbom.spdx.json extracted/rootfs
trivy rootfs --format json --output trivy-vulns.json extracted/rootfs

The third call produces a CVE matching report in addition to the SBOM. Trivy and Syft will overlap heavily on package-manager components but may differ at the edges — flag any divergences for manual review.

Add Intel's CVE-bin-tool. It specifically targets binary fingerprinting for known vulnerable component versions, including statically-linked OpenSSL, zlib, expat, libcurl and others that package-manager-based scanners cannot see. It does not produce a CycloneDX/SPDX SBOM by default but emits a JSON report you can merge into your component inventory.

Three independent passes catch most identifiable components. The remainder — what all three tools missed — is the residual-risk surface.

Step 6 — orchestrate with EMBA for vulnerability triage

EMBA is a firmware analysis platform that orchestrates extraction, static analysis, optional emulation-based dynamic analysis and vulnerability reporting. It detects:

• Insecure binaries
• Outdated software components
• Vulnerable scripts
• Hard-coded credentials

For SBOM emission specifically it offers the default-sbom.emba scan profile, producing an SBOM alongside the rest of the security findings.

EMBA does not replace Syft or Trivy. It adds a security-triage layer: vulnerable scripts, configuration mistakes, default credentials. For a legacy product still in the field that you cannot rebuild, EMBA's hard-coded-credential check alone can flag CRA Annex I Part I issues — secure-by-default failures — that would otherwise sit dormant.

Step 7 — produce the residual-risk register

Every binary-derived SBOM is incomplete. The compliance posture is to acknowledge the gap explicitly.

For each component or partition that could not be decomposed, add an entry to a residual-risk register:

The register is not a workaround for missing SBOM data — it is the SBOM's honest companion. Market surveillance authorities understand that legacy products do not yield perfect SBOMs; what they want to see is that the manufacturer knows what they do not know, and has a process for narrowing the gap over time.

Step 8 — bind the SBOM to continuous monitoring

A static SBOM file expires the moment a new CVE lands. Feed the CycloneDX 1.7 SBOM into OWASP Dependency-Track or an equivalent platform (Anchore Enterprise, Aqua Wave) and configure continuous CVE matching against the deployed firmware versions.

Then map the SBOM to your CRA legacy scope (see CRA for existing products already on the EU market):

• Was the product placed on the market before 11 December 2027? Article 69(2) grandfathers it from Annex I — but Article 69(3) keeps it under Article 14 reporting from 11 September 2026.
• The SBOM and the residual-risk register feed the Article 14 process: when a CVE matches a component in your SBOM AND you observe active exploitation in the fleet OR a severe incident, the 24-hour notification clock starts.

For products no longer in active development, the SBOM-plus-monitoring posture is what proves you have not abandoned the fleet.

Realistic expectations and the honest limitations

Three caveats every legacy SBOM programme should communicate up the management chain.

Coverage is partial. Even with Syft + Trivy + CVE-bin-tool + EMBA running on a clean extraction, you will catch 60–80 percent of the actual components in a typical embedded Linux image. The exact number depends on how aggressively the original manufacturer stripped binaries and how much was compiled directly versus installed as packages.

The SBOM is a snapshot, not a derivation. A build-time SBOM is generated FROM the build, so it is exact. A binary-derived SBOM is INFERRED from the build's output, so it is approximate. The compliance distinction matters: a market surveillance authority will accept "we generated this SBOM from the binary; we acknowledge inference confidence at X percent" but will not accept undocumented inference as ground truth.

Vendor cooperation can change the answer. If you can persuade the original silicon vendor or firmware supplier to provide the original build manifest or an SPDX/CycloneDX SBOM they produced, that beats any inference you can run. As a downstream economic operator under the CRA, you have a regulatory basis for requesting it. Write the formal request.

Common mistakes

• Treating the binary SBOM as definitive. It is inference. Document confidence levels, run multiple tools, maintain the residual-risk register.
• Skipping the firmware artifact hash. Without a SHA-256 binding the SBOM to the binary, you cannot prove to an authority which version was scanned.
• Attempting to decrypt vendor blobs without authorisation. Depending on jurisdiction this can violate TPM (technical protection measure) provisions. Document the opaque blob and engage the vendor instead.
• Forgetting language-runtime components. A Python or Node.js application embedded in the firmware brings hundreds of pip/npm dependencies. If the runtime is installed but the manifest files were stripped, Syft will see "Python 3.10" but miss every package.
• Running only Binwalk and stopping. Binwalk extracts. Syft and Trivy enumerate. EMBA triages. CVE-bin-tool catches static linkage. All four serve different purposes.
• No continuous monitoring after the initial SBOM. A 2024-emitted SBOM matched against a 2024 CVE database is stale by 2025. Dependency-Track or equivalent must run continuously against the SBOM record.
• Treating Article 69(2) grandfathering as a complete escape. Article 69(3) carve-back keeps Article 14 reporting alive for all in-scope legacy products. The SBOM is what makes Article 14 fleet-wide monitoring possible.

A template residual-risk statement

Product: <SKU and model>
Firmware version: <vendor-assigned version>
Firmware SHA-256: <hash>
SBOM date: <YYYY-MM-DD>
SBOM methodology: Binwalk v3.1.0 extraction → Syft + Trivy + CVE-bin-tool baseline scan → EMBA orchestrated triage → manual residual-risk review.

Coverage assessment: <% confidence in component enumeration, with reasoning>

Opaque components (could not enumerate):
  - <component>: hash <SHA-256>, vendor <name>, reason <encrypted | signed | stripped static | in-house>, mitigation <vendor advisory track | quarterly review | other>
  - ...

Continuous monitoring:
  - SBOM ingested into <Dependency-Track | Anchore Enterprise | other> on <date>
  - CVE feed: OSV + NVD + ENISA
  - Alert routing: <SOC | product security team>
  - Article 14 escalation path: <documented in incident response runbook>

CRA scope:
  - Placed on the market: <before | after> 11 December 2027
  - Substantial modification post-2027: <yes | no>
  - Article 69(2) grandfathering: <applicable | not applicable>
  - Article 69(3) Article 14 reporting: applicable (mandatory for all in-scope products)

This is the document a market surveillance authority will actually read. The SBOM is the data; the residual-risk statement is the answer to the question "what does the manufacturer know about its own product".

How Cenitia helps

Cenitia accepts binary-derived SBOMs from Syft, Trivy, EMBA and manual uploads, normalises them into a single per-product, per-version record, and links the SBOM to the residual-risk register the platform generates from your opaque-component log. The platform tracks every firmware version by SHA-256, runs continuous CVE matching against the SBOM via OSV, NVD and ENISA feeds, and routes Article 14-relevant matches to your incident response workflow. For legacy products in Article 69(2) grandfathering scope, the platform automatically narrows the CRA obligation set to Article 14 reporting only, while still tracking SBOM accuracy improvements over time.

When you re-extract a legacy firmware with a newer Binwalk or EMBA release and surface previously-unknown components, the platform diffs the new SBOM against the old one and flags the affected technical files for review.

Frequently asked questions

Do I need an SBOM for a legacy product that was placed on the market before 11 December 2027?

Not for Annex I Part II compliance — Article 69(2) of the CRA grandfathers products placed on the market before 11 December 2027 from the Annex I essential requirements unless they undergo a substantial modification from that date. But Article 69(3) keeps all in-scope products under the Article 14 reporting obligation, applicable from 11 September 2026. You need enough SBOM-like information about the legacy product to identify when an Article 14-relevant vulnerability is being actively exploited in your fleet — even if a full Annex I SBOM is not formally required.

What is the realistic completeness of an SBOM built from a firmware binary?

Usually 60–80 percent of the actual components, depending on the build system the manufacturer used and how much they stripped. Package-manager-based detection (Syft, Trivy) is near-complete for components installed via apk/dpkg/RPM. Statically-linked libraries (OpenSSL, zlib, curl compiled directly into a binary), stripped ELFs with no symbol table, in-house libraries with no package-database entry and signed-encrypted vendor blobs are typically invisible. CVE-bin-tool covers part of the statically-linked gap. The remainder is the residual-risk surface that must be documented explicitly.

Which extraction tool should I start with — Binwalk or EMBA?

Both. Binwalk is a focused identification-and-extraction tool you can chain into your own pipeline. EMBA is an orchestration platform that runs Binwalk-style extraction plus multiple scanners plus a vulnerability triage pass. For a one-off SBOM emission task, Binwalk plus Syft is enough. For a recurring security review of a legacy product fleet, EMBA's orchestration is worth the setup cost. The output formats are complementary — EMBA produces an SBOM via default-sbom.emba but Syft tends to produce cleaner CycloneDX/SPDX records.

What if the firmware is encrypted and I do not have the vendor's keys?

Document the encrypted partition as an opaque component in the SBOM with its SHA-256, the partition path, the vendor name and a "composition unknown — encrypted" justification. Do NOT attempt to reverse-engineer or decrypt without explicit vendor authorisation — depending on jurisdiction this can violate the EU Copyright Directive's TPM provisions or analogous national law. Engage the vendor with a written compliance request: as the responsible economic operator under the CRA you can legitimately ask the supplier for SBOM information for components you ship in your product.

Can I use AI or machine learning to identify components in a stripped binary?

Some tools — including binary similarity matchers like BinDiff, Diaphora and various commercial offerings — can identify known library versions by code-structure fingerprinting even when symbols are stripped. They are useful as a third pass after Syft, Trivy and CVE-bin-tool. They produce probabilistic matches, not definitive answers, so any AI-derived match must be flagged in the SBOM as a confidence level, not asserted as ground truth. Treat them as evidence-gathering tools, not as authority for the SBOM record itself.

How do I prove to a market surveillance authority that my legacy SBOM is honest?

Document the methodology: which extraction tool, which scanners, which versions, which dates the scans ran. Keep the raw scanner output files (Syft JSON, Trivy JSON, EMBA reports) alongside the SBOM. Maintain an explicit residual-risk register listing what could not be enumerated and why. Bind the SBOM to the firmware artifact by SHA-256. When the authority asks, you produce the chain of custody: "here is the firmware hash, here is the extraction log, here is the SBOM, here is the residual-risk register, here is what we monitor against new CVEs".

Related from the Library

• SBOM tooling for embedded systems compared
• SBOM update frequency requirements under CRA
• CycloneDX vs SPDX for hardware
• CRA for existing products already on the EU market
• CRA Annex I explained
• CRA ENISA 24-hour reporting

Further reading

• Regulation (EU) 2024/2847 — Cyber Resilience Act, EUR-Lex
• Binwalk on GitHub
• EMBA on GitHub
• Syft on GitHub
• Trivy on GitHub
• Intel CVE-bin-tool on GitHub
• OWASP Dependency-Track
• CycloneDX specification overview
• SPDX project — About
• ENISA — Vulnerability disclosure resources

Last reviewed: 5 July 2026. Cited tools and regulations watched continuously by Cenitia — when a new firmware-analysis release or regulatory clarification lands, this article is flagged for update.