Common CRA SBOM Mistakes: How to Avoid Non-Compliance

Most manufacturers discover SBOM gaps during their first compliance review, not before it. By then, the enforcement deadline is closer and the remediation scope is wider. The CRA's Annex I SBOM obligation is simple to state: machine-readable format, top-level dependencies as a minimum, stored in your Annex VII technical file. What trips manufacturers up is the phrase "at the very least". This article covers six mistakes that create the widest gap between a formal SBOM and one that would survive a market surveillance authority audit.

Mistake at a glance

#	Mistake	Why it fails	Fix
1	Stopping at direct dependencies	Transitive CVEs invisible to scanners	Lock files plus built-artefact scanning
2	Treating SBOM as one-time	Stale within weeks of new CVEs	CI/CD generation per build
3	Missing identity fields	No CVE matching, TR-03183 fails	Exact version, SHA-512, PURL, supplier
4	Manual generation	Cannot keep pace with releases	Syft, Trivy, or cdxgen automation
5	Skipping internal or proprietary components	Annex I draws no such distinction	Internal IDs, self as supplier, SHA-512
6	Treating supplier SBOMs as final	Manufacturer owns the integrated product SBOM	Consolidate into one product SBOM

Mistake 1: stopping at direct dependencies

Direct dependencies are the minimum you can get away with, but they are not enough for useful vulnerability management. Many manufacturers stop there and leave transitive dependencies outside the SBOM. A transitive dependency is a library your direct dependency depends on, and it can be just as exploitable as a direct one. When a CVE is published against a transitive package your SBOM does not list, you cannot match it, cannot report it, and are exposed without knowing it.

Your product
+-- Library A (direct)         ← direct dependency listed
|   +-- Library B (transitive) ← outside SBOM, invisible to vulnerability scanners
|   \-- Library C (transitive) ← outside SBOM, invisible to vulnerability scanners
\-- Library D (direct)         ← direct dependency listed

The fix is tooling and configuration. Use lock files and scan built artefacts rather than source only. Trivy, Syft, and cdxgen all support transitive dependency capture when configured correctly. BSI TR-03183 treats full transitive coverage as the quality indicator that separates a minimum-compliant SBOM from a genuinely useful one. See BSI TR-03183 field categories for the Required, Additional, and Optional field requirements.

Mistake 2: 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 daily against components already in your product. An SBOM that was accurate at build time becomes stale within weeks. The CRA's Annex I obligation is ongoing: the SBOM must reflect the current state of the product throughout the support period.

Mandatory update triggers under the CRA:

Trigger	What changes	SBOM update required?
New firmware or software version	New build artefact	Yes, full regeneration
Security patch applied	Component version bumped	Yes, affected components
Vulnerability discovered and addressed	VEX or exploitability status	Yes, VEX fields
Component added, removed, or replaced	Dependency graph	Yes, full regeneration
Design change affecting security	Components and architecture	Yes, full regeneration

The fix is CI/CD integration. Every build should produce a current SBOM artefact stored alongside the release. A manual export cannot keep pace with the update frequency the CRA requires. See CRA SBOM requirements for the full list of triggers and the 10-year retention clock.

Mistake 3: missing identity fields

An SBOM without accurate version, hash, and identifier fields is nearly useless for vulnerability matching. These fields connect a component entry to a CVE record in the National Vulnerability Database (NVD), OSV, or CISA KEV. Without them, vulnerability scanners cannot match against your components, and BSI TR-03183 quality checks will fail.

Every component must include:

Field	Why it matters	Source
Exact version number	Required for CVE/NVD/OSV matching (not "latest" or ranges)	TR-03183 mandatory
SHA-512 hash	Integrity verification for binary components	TR-03183 mandatory
PURL identifier	Links the component to its registry record	TR-03183 Additional (when available)
Supplier name	Required for every component	TR-03183

A common version mistake is using CycloneDX 1.3 or earlier. Core VEX support was added in CycloneDX 1.4 (January 2022), and the richer component evidence structure (identity, occurrences) used to demonstrate CRA traceability arrived in 1.5 (June 2023). Target CycloneDX 1.6 or later for CRA conformity. Check your tool's output version before assuming compliance.

Mistake 4: generating SBOMs manually

Manual SBOM creation is error-prone and does not scale across product versions. A hand-crafted SBOM misses components automated tools would find, contains typos in version strings, and cannot be regenerated reliably when a component changes. More critically, a manual process cannot satisfy the CRA's ongoing update obligation: every release, every patch, and every component change requires an updated SBOM.

Automate generation with Syft, Trivy, or cdxgen. Manual entries should be reserved for components that automated tools cannot detect, such as commercial libraries without package database entries or proprietary firmware blobs. Everything else should come from the build. Market surveillance authorities can request the SBOM at any time; it must reflect the current product state.

Mistake 5: ignoring internal and proprietary components

A common shortcut is to document only open-source dependencies and omit internal libraries, proprietary modules, or firmware blobs. Annex I draws no such distinction. If a component is in the product, it belongs in the SBOM.

Internal components often have no PURL or registry entry. The correct approach is to assign an internal identifier, list your own organisation as the supplier, and include the SHA-512 hash of the binary artefact. BSI TR-03183 explicitly covers proprietary components, and its Required fields apply to them too.

For products with embedded firmware from an ODM or chip vendor, you cannot audit what you did not build. The fix is contractual: require SBOM delivery from your firmware suppliers. Under the CRA, you are responsible for the full product regardless of who wrote the code. For hardware-software products, see HBOM under the CRA for when a Hardware Bill of Materials is needed alongside the SBOM.

Mistake 6: relying on supplier SBOMs as the finished artefact

Supplier SBOMs are a valid input, and the CRA expects manufacturers to use upstream documentation. They are not a substitute for an integrated product SBOM. You still need to consolidate supplier SBOMs with your own first-party components, build dependencies, and glue code into a single SBOM for the product you place on the EU market.

If a supplier SBOM is missing fields required by BSI TR-03183 (PURL, hash, licence), you are responsible for filling those gaps before your product ships. Treat supplier SBOMs as raw material. Your product SBOM is the finished compliance artefact.