CRA SBOM mistakes: 7 practical fixes for manufacturers

Your SBOM generator runs, the file validates, and the next product review can still find gaps. The recurring CRA readiness failures are usually not obscure legal edge cases. They are shallow dependency trees, source-only inventories, stale records, and components that scanners cannot match to a vulnerability. The Cyber Resilience Act asks for a commonly used, machine-readable SBOM covering at least your top-level dependencies and kept with the technical documentation. This article covers the seven gaps between an SBOM that technically exists and one that can support vulnerability handling. That is the SBOM a market surveillance authority expects to see.

Mistake at a glance

• Source tree, not shipped artifact: generate from the built artifact or image so compiled-in code, OS packages, and firmware are visible.
• Thin identity fields: use exact versions, hashes, PURLs where available, and supplier names so scanners can match CVEs.
• Direct dependencies only: add lock-file and built-artifact scanning so indirect and packaged dependencies enter the SBOM.
• One-time file: regenerate and archive the SBOM for every release, then keep vulnerability matching current.
• Omitted product code: internal, proprietary, commercial, and firmware components still need identifiers and evidence.
• Supplier copy-paste: supplier SBOMs are inputs. Reconcile them with first-party code and the final release artifact.
• SBOM sprawl: keep one authoritative product SBOM per release so version 1.4.2 has one defensible record.

What matters for SBOM evidence

That legal floor is not the same as a useful vulnerability-management floor. A direct-only SBOM may satisfy the minimum dependency phrase but still be too shallow to identify affected products quickly. BSI TR-03183, ENISA guidance, CISA SBOM guidance, and current tool practice are best read as quality benchmarks that help manufacturers make the CRA obligation operational.

Mistake 1: your SBOM describes the source tree, not the product you shipped

Source manifests are convenient, but they are not the product. A source scan can over-report development dependencies and miss what appears only after build, packaging, container layering, static linking, or firmware integration. For a manufacturer, the SBOM should answer what was in the product release, not only what was declared in a package file.

The difference matters most in embedded and containerised products. A language-level scan may miss OS packages in a container base layer. A Yocto or Buildroot export may miss silicon-vendor firmware, bootloaders, kernel modules, or binary blobs that entered outside the build system. If those components are in the shipped artifact, they belong in the release evidence even when an automated package scanner cannot infer them.

The fix is to generate from the release artifact or image, then compare it with source and lock-file output. For containers, scan the final image by digest. For firmware, combine build-system SBOM output with binary analysis and manual records for components tools cannot identify automatically.

Mistake 2: missing hashes and PURLs make components unmatchable

An SBOM without accurate version, hash, supplier, and package identifiers is hard to use for vulnerability matching. The file may be machine-readable, but a scanner still needs stable component identity to decide whether a CVE, OSV advisory, GitHub Security Advisory, or CISA KEV entry applies.

Every component should carry enough identity to survive automated matching:

This is not just hygiene. NIST announced on 15 April 2026 that NVD enrichment is now prioritised for selected CVEs because vulnerability volume has outpaced full enrichment capacity. That makes CPE-only matching a weaker plan for future vulnerability operations. Use PURL where available, keep hashes for shipped artifacts, and do not treat a component name alone as enough.

A common format mistake is using CycloneDX 1.3 or earlier. Core VEX support arrived in CycloneDX 1.4, and the richer component evidence structure arrived in CycloneDX 1.5. For current CRA preparation, target CycloneDX 1.6 or later, or a current SPDX profile your tools can consume reliably. Check your generator output before assuming the format supports the fields your process needs.

Mistake 3: stopping at direct dependencies

Direct dependencies are the CRA minimum floor. They are not enough for useful vulnerability work. A transitive dependency is a component pulled in by another component, and it can carry the vulnerability that matters. When a CVE lands against a transitive package your SBOM does not list, the product can be affected while your matching pipeline stays quiet.

To close this, use lock files where the ecosystem supports them, scan built artifacts as well as source, and inspect packages that bundle or shade dependencies. Treat transitive coverage as an audit-quality practice, not as a casual best-effort setting hidden in a scanner default.

Mistake 4: treating the SBOM as a one-time document

An SBOM generated once and never updated creates a false sense of security. New CVEs are published against components already in the product. New firmware versions, patches, and supplier updates change the product. The CRA also expects technical documentation to be continuously updated where appropriate during the support period.

Common update triggers:

CI/CD is the practical control. Every release should produce a current SBOM artifact stored alongside the build and linked to the technical documentation. Manual entries should exist only for components tools cannot detect, and those entries still need review when the product changes.

Mistake 5: leaving out internal, proprietary, and firmware components

A common shortcut is to document only open-source dependencies and omit internal libraries, commercial modules, proprietary firmware, or vendor blobs. That is not a product SBOM. If a component ships in the product, it belongs in scope, even when it has no public registry page.

Internal components often have no ecosystem PURL or public package record. Use an internal identifier, your own organisation as supplier where appropriate, the exact version or build ID, and the hash of the binary artifact. For commercial components, keep supplier name, version, licence evidence, and contract/source-of-truth references in the technical documentation.

For hardware-software products, firmware is where this becomes visible. Wi-Fi modules, modems, secure elements, bootloaders, trusted execution environment binaries, and out-of-tree kernel modules can carry vulnerabilities but remain invisible to language package scanners. Use supplier SBOMs where available, add manual records where not, and use binary analysis as a check. For the hardware side of the evidence package, see HBOM under the CRA.

Mistake 6: relying on supplier SBOMs as the finished artifact

Supplier SBOMs are valid inputs. They are not your finished product SBOM. The manufacturer places the integrated product on the EU market. The product SBOM has to combine supplier components, first-party code, build outputs, firmware, integration glue, and product-specific dependency relationships.

The failure mode is easy to miss: one supplier gives you a CycloneDX file, another gives you SPDX, a third gives a PDF inventory, and the final product folder contains links to all three. That is supplier evidence, not one product record. A reviewer still needs to know which components were in product version 1.4.2.

Reconcile instead of copy. Merge supplier SBOMs into the product SBOM, normalise identity fields, record known unknowns, and keep the upstream SBOMs as supporting evidence. If a supplier SBOM lacks PURL, hash, licence, or exact version, document the gap and close what you can before release. A URL to an upstream file is not the same as an integrated product SBOM.

Mistake 7: many SBOMs, no single product record

SBOM sprawl is the stage after teams adopt tools. There is an app SBOM, a container SBOM, a firmware SBOM, several supplier SBOMs, and a spreadsheet maintained by a product manager. None of them is the authoritative answer for the product release placed on the market.

That creates audit and operations risk. When a new actively exploited vulnerability appears, the team has to search across fragments before it can say whether the product is affected. When an authority makes a reasoned request, the evidence package should not depend on someone remembering which folder contains the latest merge.

Use one authoritative product SBOM per release, with supporting component SBOMs retained underneath it. Keep it for at least 10 years after the product has been placed on the market, or for the support period, whichever is longer. Store it where the release, vulnerability monitoring, VEX decisions, and technical documentation can all reference the same version.