What Is an SBOM? Cyber Resilience Act Requirements, Fields & Checklist

By A.R. Hashir • Last reviewed: 30 October 2026 • Educational implementation guide, not legal advice

Short answer: An SBOM (software bill of materials) is the machine-readable inventory of components and dependency relationships in one exact product version. The Cyber Resilience Act legal floor is a commonly used, machine-readable SBOM covering at least the top-level dependencies. The defensible operational target is stronger: one signed, release-bound SPDX 3.0.1+ or CycloneDX 1.6+ record for every variant/version, full in-scope transitive coverage, stable identifiers, hashes, generation context and explicit unknowns. The Annex I SBOM duty applies with the main regime from 11 December 2027, while Article 14 reporting has been live since 11 September 2026 and already depends on fast component-to-release answers.

October 2026 update: This guide now incorporates ENISA’s 22 October 2026 Technical Advisory, the July 2026 international Minimum Elements, BSI TR-03183-2 and the current SPDX/CycloneDX lifecycle/tooling landscape.

When a security advisory names an open-source library, the first operational question is simple: Which shipped product versions contain it? If the answer depends on searching old repositories, asking individual engineers or opening a spreadsheet last updated two releases ago, the manufacturer does not yet have an SBOM system. It has an archaeological project.

This rebuilt guide separates three things that are often blended together: what Regulation (EU) 2024/2847 legally says, what the 2026 ENISA/CISA/BSI implementation baselines recommend, and what an engineering organisation should actually operate. It includes an SBOM example, format decision matrix, tool stack, quality scorecard, supplier-intake workflow and incident-response drill. For the wider date sequence, read EU Cyber Resilience Act Deadlines: 2026–2027 Timeline & Compliance Checklist.

On this page

1. What is an SBOM?
2. What the Cyber Resilience Act legally requires
3. What changed in 2026
4. Legal floor versus operational target
5. Recommended CRA SBOM profile
6. The 17 minimum data fields
7. SPDX vs CycloneDX
8. SBOM types and lifecycle
9. How to create a CRA-ready SBOM
10. SBOM tools
11. Quality scorecard
12. Supplier SBOM acceptance
13. Vulnerability response and 2026 reporting
14. Protecting the SBOM system
15. Product-specific playbooks
16. 30–90–180 day action plan
17. CRA SBOM readiness checklist
18. Frequently asked questions

What is an SBOM (software bill of materials)?

CISA describes an SBOM as a nested inventory—the list of ingredients that make up software applications and systems. The Cyber Resilience Act’s own definition is equally practical: a formal record containing details and supply-chain relationships of components included in the software elements of a product with digital elements.

An SBOM is therefore more than a flat list of package names. It should identify the product version at the root, the direct components it contains, the transitive components pulled in by those components, and enough metadata to match each item against vulnerability, license, supplier and support-status information.

Three distinctions matter:

• An SBOM is not the source code. It is structured metadata about components.
• An SBOM is not a vulnerability scan. It records what is present; vulnerability conclusions require matching that inventory to current advisories and analysing exploitability in the product context.
• An SBOM is version-specific. Firmware 4.2.0 and firmware 4.2.1 do not share one SBOM merely because they belong to the same product family.

A small SBOM example

Record element	Illustrative value
SBOM describes	Connected controller firmware, version 4.2.0
Direct component	ExampleTLS 3.2.1
Transitive component	ExampleCrypto 1.8.4
Relationship	Firmware 4.2.0 → contains ExampleTLS → depends on ExampleCrypto
Identity evidence	Producer, exact version, Package URL and/or CPE where available, license identifier and cryptographic hash
Document evidence	SBOM author, generation tool and version, generation context, timestamp, SBOM version and signature

The component names above are illustrative. A production SBOM would encode the equivalent records and full dependency graph in a standard format such as CycloneDX or SPDX.

What the example looks like in CycloneDX JSON

The shortened excerpt below shows the same idea in a machine-processable structure: a release root, an accountable author, a build-time generation context, a component with a Package URL and SHA-512 hash, and an explicit dependency edge. A production SBOM would contain the complete in-scope graph and pass schema/profile validation; illustrative hashes and identifiers must never be copied into evidence.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "version": 1,
  "metadata": {
    "timestamp": "2026-10-30T00:00:00Z",
    "lifecycles": [{ "phase": "build" }],
    "tools": {
      "components": [{
        "type": "application",
        "name": "Example SBOM Generator",
        "version": "1.0.0"
      }]
    },
    "authors": [{
      "name": "Example Manufacturer PSIRT",
      "contact": "psirt@example.com"
    }],
    "component": {
      "type": "firmware",
      "bom-ref": "controller-firmware-4.2.0",
      "name": "Connected Controller Firmware",
      "version": "4.2.0"
    }
  },
  "components": [{
    "type": "library",
    "bom-ref": "exampletls-3.2.1",
    "name": "ExampleTLS",
    "version": "3.2.1",
    "purl": "pkg:generic/exampletls@3.2.1",
    "licenses": [{ "license": { "id": "Apache-2.0" } }],
    "hashes": [{
      "alg": "SHA-512",
      "content": "cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e"
    }]
  }],
  "dependencies": [{
    "ref": "controller-firmware-4.2.0",
    "dependsOn": ["exampletls-3.2.1"]
  }]
}

What the Cyber Resilience Act legally requires

Annex I, Part II, point (1) of the Cyber Resilience Act requires manufacturers to:

“identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products”.

Question	CRA answer	Legal reference
What is an SBOM?	A formal record of component details and supply-chain relationships.	Article 3, point (39)
Is it mandatory?	Yes for manufacturers of in-scope products with digital elements under the vulnerability-handling requirements.	Annex I, Part II, point (1)
How deep must it go?	At the very least, the top-level dependencies. That wording sets a floor, not a sensible ceiling.	Annex I, Part II, point (1)
Which format is named?	The Regulation says commonly used and machine-readable; it does not itself name SPDX or CycloneDX. The Commission may specify format and elements by implementing act.	Annex I, Part II, point (1); Article 13(24)
Where does it belong?	The technical documentation must include necessary vulnerability-handling information and specifications, including the SBOM.	Annex VII, point 2(b)
Who can obtain it?	A market surveillance authority may obtain it further to a reasoned request where necessary to check compliance. Authorities may also request SBOMs for an EU-level dependency assessment.	Annex VII, point 8; Article 13(25)
Must users receive it?	Users receive access information only if the manufacturer decides to make the SBOM available to them.	Annex II, point 9
How long is documentation kept?	Technical documentation and the EU declaration of conformity are kept at the disposal of market surveillance authorities for at least 10 years after the product is placed on the market or for the support period, whichever is longer.	Article 13(13)
When does the SBOM duty apply?	With the main Cyber Resilience Act regime from 11 December 2027. Article 14 reporting has applied since 11 September 2026 and already depends on knowing affected components and product versions.	Article 71(2); Article 14
Are exact data fields named?	The Regulation does not publish a field-by-field schema for hashes, licenses or signatures. Those details currently come from the chosen format/profile and implementation guidance, subject to a future Article 13(24) implementing act.	Annex I, Part II, point (1); Article 13(24)
Do supplier components matter?	Manufacturers must exercise due diligence when integrating third-party components and ensure those components do not compromise product security. A supplier SBOM supports that duty but does not transfer manufacturer responsibility upstream.	Article 13(5)–(6)

The important planning conclusion is that December 2027 is the legal application date, not a sensible start date. A manufacturer that cannot map components to supported product versions will struggle to triage an actively exploited vulnerability, prepare user information and evidence its decisions under time pressure.

What changed in 2026: the SBOM guidance stack is now much clearer

The Regulation still leaves the detailed SBOM profile open, but manufacturers no longer have to invent one from a blank page. Three 2026 publications now sit between the legal text and engineering practice. None of them changes the CRA by itself; together they show what a defensible implementation looks like.

2026 source	What it adds	How to use it in a CRA programme
ENISA SBOM Adoption State of Play 9 June 2026	Survey evidence: 78% of respondents had started SBOM adoption, 44% were in pilot/limited use and only 9% described mature automation. CycloneDX was used by 44% and SPDX by 29%; the biggest barriers were completeness, data quality, skills and vulnerability matching.	Treat generation as only the first maturity step. Budget for identity/data-quality work, supplier SBOM consumption and operational use, not only a generator plug-in.
CISA and partner agencies: 2026 Minimum Elements 29 July 2026	Replaces the 2021 NTIA baseline with 17 data fields and six practices. It adds generation context, tool identity, author signature, license and explicit unknown/withheld information, and replaces a minimum depth with full component coverage.	Use it as the international data-quality checklist, especially for customers and procurement outside the EU. Do not label it EU law; the document says it does not create new requirements.
ENISA Technical Advisory for SBOM 22 October 2026	Practical architecture and lifecycle guidance for SMEs and stewards: SBOM types, CI/CD data flows, validation, cryptographic signing, immutable storage, consumption, update triggers, an SBOM threat model and security controls.	Use it as the operating model around the file—generation, validation, signing, storage, consumption and maintenance. ENISA states that the advisory is non-mandatory guidance, not a legal interpretation.

The practical conclusion is that the question has shifted from “Can we produce an SBOM file?” to “Can we repeatedly produce an accurate, signed, queryable, release-bound SBOM and use it during an incident?” That is the standard the rest of this guide applies.

CRA legal floor versus a useful operational SBOM

The phrase “at the very least the top-level dependencies” is often misread as permission to stop at direct dependencies. Legally, it states a minimum. Operationally, stopping there can hide exactly the component that created the incident: a vulnerable library introduced transitively by a framework, operating-system package or supplier module.

Baseline	Coverage expectation	How to use it
CRA Regulation text	At least top-level dependencies.	The legal floor in Annex I. Do not describe this alone as a mature vulnerability-response capability.
2026 SBOM Minimum Elements	All components that make up the target software, including transitive dependencies; no minimum depth.	A strong international target profile for data quality. The document says it does not create new requirements, so do not present it as EU law.
BSI TR-03183-2 v2.1.0	Recursive dependency resolution on each path at least to and including the first component outside the scope of delivery.	A concrete technical implementation baseline from Germany’s BSI where adopted by policy, customer or procurement; it is not the text of the Cyber Resilience Act itself.

A defensible manufacturer target is therefore: meet the Cyber Resilience Act wording, but engineer for the fuller resolved graph and explicitly mark unknown or withheld information instead of silently leaving gaps. Before freezing the company profile, check for any Article 13(24) implementing act, applicable harmonised standard and customer-specific SBOM clause.

A defensible CRA SBOM profile to adopt now

Until an Article 13(24) implementing act or cited harmonised standard supplies a more specific EU profile, the lowest-regret approach is a written company profile that satisfies the CRA wording and deliberately incorporates the stricter compatible parts of BSI TR-03183-2 and the 2026 Minimum Elements. The profile below is an implementation recommendation, not a claim that every row is written in the Regulation.

Profile decision	Recommended default
Release unit	One canonical SBOM for each product variant and software/firmware version actually delivered; never overwrite a shipped release. Corrections create a new SBOM document version linked to the same software version.
Canonical format	CycloneDX 1.6 or a later officially released version, or SPDX 3.0.1 or later, serialised as JSON or XML. Choose one canonical format per product line and validate it before release.
Coverage	Resolve direct and transitive dependencies in the scope of delivery, continuing down each path at least to the first component outside that scope so separate product/environment SBOMs can be chained. Declare incomplete enumerations and unknowns.
Generation evidence	Build SBOM as the primary release record, reconciled against the shipped artifact with an analysed SBOM where the product form makes that feasible. Record generation context, tool name/version, author, timestamp and SBOM version.
Component identity	Producer/creator, exact name and version, filename where applicable, dependency relationships, license identifiers/expressions, ecosystem identifiers such as PURL and/or CPE, source/deployable URIs where available, and a deployable-artifact hash—SHA-512 where the BSI profile is claimed.
Integrity	Sign the SBOM or attach a verifiable attestation, bind it to the exact artifact digest, and verify the signature during supplier intake and release retrieval.
Unknowns and referenced BOMs	Distinguish unknown, not applicable and deliberately withheld data. If a supplier SBOM is referenced rather than merged, keep its creator/name/version in the referencing SBOM and make the referenced SBOM retrievable for the support/retention period.
Storage and access	Immutable or version-controlled repository, role-based access, audit logs, backup and a named retrieval owner. File the SBOM with the release/technical-documentation record.
Operational use	Continuously correlate components with vulnerability intelligence, but keep vulnerability status in linked VEX/CSAF/advisory records rather than rewriting the static composition record.
Change triggers	Regenerate for new builds/releases, dependency or OS-package changes, build-configuration changes and supplier-component substitutions. Issue a corrected SBOM when component metadata is later discovered to be wrong.

Profile rule: If a customer, market-surveillance authority or future EU act requests a different version, generate that view from the controlled source data through a tested process. Do not maintain handwritten SPDX and CycloneDX files that can silently diverge.

The 17 minimum data fields to aim for

On 29 July 2026, CISA and international partner agencies published the 2026 Minimum Elements for a Software Bill of Materials, updating and replacing the 2021 NTIA baseline. The Cyber Resilience Act itself does not list these 17 fields today. They are nevertheless a practical starting profile because they address identity, integrity, provenance and machine processing—the qualities that make an SBOM useful after release.

Nine SBOM-document fields

Field	Purpose
SBOM Author	The entity that created the SBOM data.
SBOM Author Signature	A digital signature providing authenticity and integrity evidence.
SBOM Data Format Name	The format used, such as CycloneDX or SPDX.
SBOM Data Format Version	The exact format-specification version.
SBOM Generation Context	Whether the SBOM was generated before build, during build, after build or at another lifecycle point.
SBOM Timestamp	When the SBOM data was most recently updated.
SBOM Tool Name	The tool used to generate or amend the SBOM.
SBOM Tool Version	The exact version of that tool.
SBOM Version	The version of this SBOM document for the relevant component/version pair.

Eight component fields

Field	Purpose
Component Producer	The entity that creates, defines and identifies the component.
Component Name	The producer-assigned component name, including alternate names where needed.
Component Version	The producer’s exact version identifier, or an explicit unknown value.
Component Identifiers	Lookup keys such as Package URL (PURL), CPE, UUID, commit hash or intrinsic identifiers where appropriate.
Component Dependency Relationship	The relationship showing which component requires or contains another component.
Component Hash Value	The cryptographic hash of the executable component artifact where available.
Component Hash Algorithm	The algorithm used to calculate that hash.
Component License	The license identifiers under which the component is available.

The 2026 baseline also expects six operating practices: accommodate corrections, pursue full coverage, distribute promptly to authorised recipients, identify unknown information explicitly, create an SBOM for each software version or update, and use machine-processable data. Those practices matter as much as the fields. A perfectly formatted SBOM for the wrong release is still wrong evidence.

What BSI TR-03183-2 adds to the 17 fields

BSI TR-03183-2 v2.1.0 is not binding EU law and gives no presumption of conformity; BSI itself says it will be replaced by harmonised European standards when available. It is nevertheless the most concrete Europe-focused technical profile currently available. Its field model overlaps with CISA’s, but it is not identical.

BSI-specific or sharper item	What it means
Fully described component filename	The actual filename, not a filesystem path. Logical, external, identified and referenced components have reduced field sets under the guideline’s component-type rules.
Dependency-enumeration completeness	Each dependency list must clearly indicate whether it is complete. This prevents an incomplete graph from looking exhaustive.
SHA-512 deployable-component hash	The required hash is of the deployed/deployable component as a file, not merely a source-repository commit.
Executable / archive / structured properties	Three explicit classifications help consumers understand what kind of artifact a component record represents.
Creator contact	Component and SBOM creators are identified by email address or, if unavailable, a URL.
SBOM URI and component URIs	Additional fields cover the SBOM URI and, where they exist, source-code and deployable-form URIs. Optional fields include source-code hash, effective license and the creator’s security.txt URL.
License precision	Use SPDX license identifiers/expressions, not pasted license text as a substitute. BSI distinguishes original, distribution and effective licenses.
Format floor	Newly generated or updated SBOMs must be JSON or XML valid against CycloneDX 1.6+ or SPDX 3.0.1+, using officially released specification versions.
No vulnerability payload	A BSI-conforming SBOM must not contain vulnerability information. Keep the dynamic analysis in CSAF, VEX or a product security advisory linked to stable component/product identifiers.

The two baselines also pull in different directions: CISA adds an author signature and generation context that BSI’s minimum field list does not make central, while BSI adds filename and artifact-shape properties that CISA does not require. A union profile can satisfy both sets of data expectations, but only if the generator and manual-enrichment process are tested against both checklists.

SPDX vs CycloneDX: which SBOM format should you choose?

The Cyber Resilience Act does not currently force a winner. As reviewed on 30 October 2026, CycloneDX’s current specification version is 1.7 and SPDX’s is 3.0.1; BSI’s profile floor is CycloneDX 1.6+ or SPDX 3.0.1+ in JSON or XML using officially released versions. CISA identifies SPDX and CycloneDX as the two data formats widely used to generate and consume SBOMs. Using the newest version is sensible only when your generators, validators and consumers support it correctly.

Factor	CycloneDX	SPDX
Steward / standard	OWASP Foundation and Ecma TC54; current version 1.7, standardised as ECMA-424.	Linux Foundation project; SPDX 2.2.1 is ISO/IEC 5962:2021, while the current implementation profile in this guide is SPDX 3.0.1 or later.
Typical centre of gravity	Application-security and broader bill-of-materials workflows, including vulnerability-related exchanges.	Software provenance, licensing, security and supply-chain communication.
Serialisation	JSON, XML and Protocol Buffers.	Multiple machine-readable representations depending on specification version and profile.
Good first choice when	The engineering and security toolchain already generates or consumes CycloneDX efficiently.	License/provenance workflows, customer requirements or the existing toolchain already centre on SPDX.

Choose by product and consumer, not by fashion

Situation	Usually simpler starting point	Reason
Yocto/Linux, Zephyr or a build system that already emits high-quality SPDX	SPDX 3.0.1+	Build-native evidence is usually more accurate than post-hoc conversion. Validate that the output really is the selected SPDX version/profile, not an older 2.x document.
Vulnerability operations centred on Dependency-Track or CycloneDX VEX workflows	CycloneDX 1.6+	Shorter path from CI generation to portfolio ingestion, component analysis and VEX exchange.
License/provenance evidence is the dominant external consumer need	SPDX 3.0.1+	Deep license/provenance model and mature open-source compliance ecosystem. BSI still expects SPDX license identifiers even inside CycloneDX.
Container, filesystem or delivered-artifact reconciliation	Either, based on generator accuracy	Tools such as Syft or Trivy can emit both. Compare component identity and relationship quality on your artifact, not the logo on the file.
Customer, procurement or notified-body pack names a format/version	The requested format	Contractual acceptance can be stricter than the Regulation. Keep the internal canonical record and a tested native-generation path for the requested view.
Mixed product lines with different native outputs	One portfolio query model, controlled source SBOMs	You may ingest both formats, but each product needs one authoritative release SBOM. Conversion can lose fields or relationship semantics and must be diff-tested.

The format name is less important than valid output, complete identity data and repeatable generation. Choose according to the authoritative build pipeline, downstream consumers, notified-body/customer expectations and validation tooling. Do not maintain two hand-edited SBOMs in parallel; generate one canonical record and convert only through a tested process.

SBOM types: when you generate it changes what it can prove

Two valid SBOM files for the same release can disagree because they were created at different lifecycle points. Record the generation context so a consumer does not mistake a design intention for shipped evidence.

Type	Created from	Best use	Main limitation
Design	Planned architecture and intended components	Threat modelling, license/procurement decisions	May describe components that are never shipped
Source	Source tree, manifests and lockfiles	Early dependency/license/vulnerability feedback	Can miss generated, linked, shaded, copied or build-added components
Build	The actual build process and release inputs	Primary CRA release evidence and reproducible graph	Requires disciplined CI/CD and build-context capture
Analysed	Post-build executable, package, firmware or container artifact	Reconcile the build SBOM with what actually shipped; assess third-party binaries	Heuristics can create false positives/negatives and weaker provenance
Deployed	Installed system and selected configuration/options	Asset inventory and environment-specific exposure	One deployment may not represent every customer configuration
Runtime	Loaded libraries, plug-ins, sidecars and dynamic calls	Exposure/reachability analysis and threat detection	Observation depends on workload; not a complete release inventory

Recommended evidence pattern: use Source SBOMs during development, make the Build SBOM the controlled release record, and reconcile high-risk artifacts with an Analysed SBOM. Deployed/runtime views are valuable operational overlays, not substitutes for the SBOM of the version placed on the market.

The SBOM lifecycle: from build record to operational system

ENISA’s October 2026 advisory describes a lifecycle of build, generation, validation, signing, storage, consumption and maintenance. In pipeline terms:

1. Collect authoritative inputs: source repositories, lockfiles, package-manager manifests, build logs/link maps, OS package databases, container layers, firmware images, binaries and supplier SBOMs.
2. Generate and normalise: discover direct/transitive components, construct relationships, normalise names/versions and resolve multiple instances without collapsing different artifacts.
3. Validate in layers: schema syntax, company profile fields, identifier/reference integrity, license expressions, completeness indicators and agreement with the shipped artifact.
4. Sign and bind: authenticate the SBOM author and associate the document with the exact release artifact digest.
5. Store and index: use immutable/versioned storage and make product, version, component, identifier and hash searchable across the portfolio.
6. Consume continuously: vulnerability matching, license governance, procurement risk, asset inventory, customer/authority response and support-period monitoring.
7. Maintain by trigger: new build/release, dependency or base-image change, supplier substitution, build-configuration change, metadata correction and referenced-BOM update.

How to create a CRA-ready SBOM

1. Define the release unit. Identify the exact product, variant, firmware/software version, delivery scope, support period and components supplied by third parties.
2. Freeze an SBOM profile. Select CycloneDX or SPDX, the minimum specification version, required data fields, identifier policy, depth rule, signing method and acceptance tests.
3. Generate from authoritative evidence. Integrate generation into the build or release pipeline. Depending on the product, combine source, build and analysed-artifact views instead of assuming one scan sees everything. Common generator categories include build-system plug-ins, container/filesystem analysers and supplier-provided SBOMs.
4. Resolve the graph. Merge direct and transitive dependencies, referenced supplier SBOMs, copied code, forks and commercial components. Record multiple instances separately where their metadata differs.
5. Normalise identity. Clean producer, name and version values; add PURL/CPE or other identifiers where appropriate; record hashes and machine-processable license identifiers; remove accidental duplicates without collapsing genuinely different instances.
6. Validate before release. Check schema validity, profile fields, dependency completeness, unknown values and agreement with the shipped artifact. Generate a new SBOM version, timestamp and signature where the profile requires them.
7. File it as controlled evidence. Store the immutable SBOM with the release record and technical documentation, protect access, and make historical versions retrievable for the required retention period.
8. Operationalise it. Continuously correlate component identifiers with advisories and vulnerability data, assess exploitability in product context, and communicate status through the coordinated vulnerability disclosure, security advisory, VEX or CSAF process as appropriate.
9. Run a retrieval drill. Pick one component and time the team while it identifies every supported product version containing it, the update path, affected variants, responsible owner and draft user/regulator decision record. This is the test that exposes a decorative SBOM.

Keep the SBOM and vulnerability status conceptually separate. The SBOM for a fixed software version is a stable composition record. Vulnerability knowledge changes daily. BSI TR-03183-2 goes as far as stating that an SBOM conforming to that guideline must not contain vulnerability information; the analysis belongs in separate advisory or VEX data linked to the product and component identity.

SBOM tools: build a stack, not a single magic scanner

No one tool sees every source file, linked binary, operating-system package, container layer and supplier module equally well. Select tools by lifecycle job and test them against a release artifact whose contents you already know.

Job	Representative tool categories/examples	Selection question
Build-native generation	CycloneDX build plug-ins; SPDX plug-ins/tools; Yocto create-spdx; Zephyr west spdx; Microsoft SBOM Tool	Does it capture the resolved dependency versions and artifacts selected by the real build?
Source and multi-ecosystem generation	cdxgen, OSS Review Toolkit (ORT), ScanCode and ecosystem dependency-graph exports	Does it understand our languages, private registries, vendored code and monorepo boundaries?
Artifact/container/filesystem analysis	Syft, Trivy and binary/package analysers	Can it reconcile the shipped image/firmware and explain heuristic identifications?
Schema/profile validation and quality scoring	CycloneDX CLI, SPDX tools/validators, sbomqs and SBOM scorecard tools	Can CI fail or quarantine output for missing versions, hashes, licenses, identifiers or broken graph references?
Signing and attestation	Cosign/Sigstore, platform build attestations and controlled code-signing services	Can a recipient verify who produced the SBOM and which artifact digest it describes after keys or staff change?
Consumption and portfolio query	OWASP Dependency-Track, Grype, OSV-Scanner, vulnerability/license platforms and internal graph indexes	Can we answer “which supported releases contain this exact component?” in minutes and preserve the assessment?

Treat vendor claims of “CRA-compliant SBOM” as a starting question: compliant with which named profile, which format version, which fields, what coverage rule, and with what validation evidence? The manufacturer remains responsible for the result.

SBOM quality scorecard: test the data before an incident tests you

Schema validity only proves the file can be parsed. Use release gates for identity, coverage and retrievability. The scorecard below is an internal quality framework, not an EU scoring system.

Gate	Points	Release evidence
Exact release and artifact binding	15	Primary product/variant/version, artifact digest, SBOM URI/version, timestamp and build identifier all agree.
Coverage and graph integrity	20	Direct/transitive graph follows the declared scope rule; every dependency reference resolves; incomplete paths and external identified components are explicit.
Component identity quality	20	Exact producer/name/version; PURL/CPE or another documented lookup key; license identifier/expression; deployable hash and filename where the profile requires them.
Provenance and integrity	15	Accountable SBOM author, tool name/version, generation context, signature/attestation and protected pipeline logs.
Accuracy reconciliation	10	Build SBOM compared with the shipped artifact or an analysed SBOM; unexplained additions/omissions are zero or formally accepted.
Operational query readiness	10	A named component can be traced to supported product versions, owners and update paths within the organisation’s incident target.
Retention, access and corrections	10	Immutable archive, backup/recovery, role-based access, referenced-BOM availability and a tested correction/versioning process.

Track the underlying rates rather than celebrating a total: unknown-version rate, missing-identifier rate, missing-hash rate, duplicate/inconsistent component instances, orphaned graph nodes, supplier-SBOM rejection rate and median component-to-release query time. A small SBOM can score well while covering the wrong product; a huge SBOM can still be low-quality noise.

Supplier SBOMs: intake, referenced BOMs and contract controls

A supplier’s SBOM is evidence entering your technical file, not an email attachment to file unread. Put it through the same trust process as a binary component.

Five-step supplier SBOM intake

1. Authenticate: verify the supplier identity, signature/attestation and delivery channel.
2. Validate: check schema, format version, company profile, identifiers, graph references and license expressions.
3. Bind: confirm the SBOM describes the exact component version and artifact digest received—not the supplier’s latest release.
4. Merge or reference deliberately: merged data becomes part of your SBOM; referenced data must remain available and resolvable. Preserve creator, name and version in the referencing record in case the reference fails.
5. Quarantine exceptions: issue a correction request for silent unknowns, missing transitive paths or artifact mismatches. Binary-only components may need an analysed SBOM plus a supplier declaration of scope and known gaps.

Clauses to put in purchasing and component agreements

• Named format/version, serialisation, data fields, graph-depth/scope rule and identifier policy.
• One SBOM for every delivered component version/update, delivered no later than the artifact or release note.
• Correction and reissue process when metadata or component content is wrong.
• Referenced SBOM availability, confidentiality/access rules and permission to disclose to conformity/market-surveillance bodies where legally required.
• Component end-of-life/end-of-support notice aligned with your product support period.
• Vulnerability notification, fixed-version data and separate VEX/CSAF or advisory information.
• Sub-supplier flow-down for components inside the supplier’s delivery scope.

Using the SBOM during vulnerability response and 2026 reporting

The SBOM’s highest-value moment is not an audit. It is the first hour after a credible advisory says a component is being exploited. Build this query path before you need it:

1. Normalise the advisory identifiers: CVE/GHSA/OSV records may use CPE or ecosystem package names that do not match your PURL exactly. Maintain aliases and test matching rules.
2. Find candidate releases: query exact component/version, artifact hashes and dependency paths across supported and still-deployed product versions.
3. Assess product context: determine whether the vulnerable function is present, reachable and exposed; record the result as affected, not affected, fixed or under investigation in a linked VEX/CSAF/advisory workflow.
4. Prioritise by evidence: active exploitation, exposure, product criticality, mitigations and patch availability—not CVSS score alone.
5. Escalate the legal decision: if the event may be an actively exploited vulnerability or severe incident, start the Article 14 awareness record and PSIRT/legal review. The SBOM supplies evidence; it does not make the regulatory determination.
6. Communicate and preserve: user mitigation, fixed versions, timestamps, query results and decision rationale should be linked to the release SBOM, not buried in chat.

For the wider legal sequence and the 24-hour/72-hour filing workflow, use the companion EU Cyber Resilience Act Deadlines: 2026–2027 Timeline & Compliance Checklist. Remember the legal distinction: reporting has applied since 11 September 2026, while the Annex I SBOM duty belongs to the main regime applying from 11 December 2027.

Protect the SBOM system itself

An SBOM is both defensive evidence and sensitive architecture information. ENISA’s threat model highlights spoofed authors/tools, tampered component data, uncontrolled disclosure of versions and supplier relationships, repository denial of service and privilege escalation in CI/CD or signing infrastructure.

• Apply MFA, least privilege and branch/pipeline protection to generators, signing services and repositories.
• Protect signing keys in managed key services or hardware-backed storage; keep revocation and key-rotation evidence.
• Use access-controlled, tamper-evident storage with audit logs, backups and tested recovery.
• Harden parsers against oversized/deeply nested supplier files and validate external references before automated lookup.
• Decide which customers receive a full SBOM, a redacted/authorised view or only vulnerability advisories. Fair, reasonable and control access without making legitimate security use impossible.

Product-specific SBOM playbooks

Product form	Authoritative evidence to combine	Common blind spot
Stand-alone application	Lockfiles, build plug-ins, installer contents and bundled runtimes	Dependencies copied into the installer but absent from the source graph
Containerised product/backend	Application build SBOM plus image-layer/OS-package inventory and image digest	Base-image packages, sidecars and tools left in the production image
Embedded Linux / firmware	Yocto/Buildroot output, kernel and bootloader records, link maps, binary analysis and update-package contents	Vendor blobs, statically linked libraries, generated code and configuration-selected components
RTOS / microcontroller firmware	Build-system metadata, linker inputs, third-party SDK records and analysed firmware image	Object libraries whose package identity disappears after linking
Commercial or binary-only module	Supplier SBOM bound to the delivered digest, supplier declarations and independent artifact analysis	Accepting a marketing PDF or an SBOM for a different version

A 30–90–180 day SBOM implementation plan

First 30 days: make one release trustworthy

• Choose one representative supported product, freeze the SBOM profile and generate its Build SBOM in CI.
• Validate schema/fields, bind it to the artifact digest and archive it immutably.
• Run a timed component-to-product-version query for the PSIRT.

By 90 days: make it repeatable

• Roll the profile to priority products, reconcile shipped artifacts and add supplier-SBOM intake.
• Connect vulnerability/license consumption and VEX/advisory decisions.
• Measure unknown, identifier, hash and graph-quality rates at every release gate.

By 180 days: make it portfolio-ready

• Cover supported legacy releases needed for Article 14 response, not only the newest version.
• Contractually align suppliers and referenced-BOM retention with product support periods.
• Rehearse authority/customer retrieval, correction/reissue and a 24-hour reporting tabletop using real SBOM data.

Six SBOM mistakes that create CRA friction

• One SBOM for the whole product family. Variants and releases diverge; evidence must follow the version actually placed on the market.
• Names without identifiers. “OpenSSL” without an exact version, producer, identifier and relationship is difficult to correlate at machine speed.
• Top-level-only thinking. The legal floor can miss the transitive component that drives the vulnerability decision.
• Spreadsheet archaeology. A list reconstructed from repositories months after shipment may not match the binary, firmware image or supplier module users received.
• Embedding today’s CVE conclusion forever. A component can become vulnerable tomorrow; keep composition, assessment and disclosure records connected but distinct.
• No retrieval owner. If nobody can produce the signed SBOM for a five-year-old supported release, the SBOM is not functioning as technical-documentation evidence.

CRA SBOM readiness checklist

• ☐ Product, variant, version, scope of delivery and support period are defined.
• ☐ SPDX or CycloneDX profile and minimum specification version are selected and documented.
• ☐ Direct and transitive coverage rules go beyond a flat top-level list where feasible.
• ☐ All 17 target data fields are mapped to the chosen format or an explicit exception process.
• ☐ Unknown or withheld values are identified rather than left silently blank.
• ☐ SBOM generation is automated in the build/release pipeline and tied to the shipped artifact.
• ☐ Supplier SBOM intake, confidentiality, correction and referenced-BOM availability are contractually and technically managed.
• ☐ Schema/profile validation, SBOM versioning, timestamping and signing occur before release.
• ☐ The SBOM is filed with the technical documentation and historical releases remain retrievable.
• ☐ Vulnerability correlation, exploitability analysis, user communication and Article 14 escalation have named owners.
• ☐ A timed component-to-product-version drill has been completed and the evidence retained.
• ☐ The build SBOM has been reconciled with the shipped artifact or an analysed SBOM where feasible.
• ☐ The SBOM is signed/attested and cryptographically bound to the exact artifact digest.
• ☐ A supplier SBOM intake gate validates signature, schema/profile, artifact binding and correction status.
• ☐ Referenced supplier BOMs are retrievable for the full product evidence-retention period.
• ☐ SBOM repository access, audit logs, backup/recovery and parser limits are controlled.
• ☐ Component identifiers can be matched across PURL, CPE and advisory aliases without manual spreadsheet work.
• ☐ VEX/CSAF or advisory status is linked to the SBOM but does not overwrite the static release inventory.
• ☐ Supported legacy product versions needed for Article 14 response are included in the query index.
• ☐ Unknown, withheld and incomplete dependency data have named owners and correction deadlines.
• ☐ Generation/validation failures can quarantine a release or trigger a documented risk acceptance.

Need the complete CRA operating system?

From Code to CE Mark places SBOM creation inside the wider manufacturer workflow: product scope, cybersecurity risk assessment, secure-by-design evidence, coordinated vulnerability disclosure, Article 14 reporting, conformity assessment and the Annex VII technical file. It is a 253-page practitioner guide with 22 chapters, 12 worksheets and 13 figures. You can also compare formats through the Books by A.R. Hashir on Amazon catalogue.

Read the Sample / Buy on Amazon →

Frequently asked questions

Is an SBOM mandatory under the Cyber Resilience Act?

Yes, for manufacturers of in-scope products with digital elements. Annex I, Part II, point (1) requires components and vulnerabilities to be identified and documented, including by drawing up an SBOM. The main regime applies from 11 December 2027.

Is an SBOM legally required from 11 September 2026?

The Annex I SBOM duty is part of the main 2027 regime, but Article 14 reporting has applied since 11 September 2026. Manufacturers therefore need a reliable component-to-product-version inventory now to assess and report qualifying vulnerabilities and incidents.

Does the CRA require SPDX or CycloneDX?

The Regulation requires a commonly used, machine-readable format but does not itself name a format. SPDX and CycloneDX are the two widely used options identified by CISA. The Commission may specify format and elements later under Article 13(24).

Are transitive dependencies required?

The Cyber Resilience Act text says “at the very least the top-level dependencies”. The 2026 Minimum Elements target all components including transitive dependencies, and BSI TR-03183-2 requires recursive resolution to the first component outside the scope of delivery. Treat top-level-only as a floor, not the operational goal.

Must an SBOM be published to customers or the public?

The Cyber Resilience Act places SBOM information in the technical documentation and provides market-surveillance access routes. Annex II, point 9 only requires user-access information if the manufacturer decides to make the SBOM available to users. Customer contracts may separately require disclosure.

Should vulnerabilities be listed inside the SBOM?

The SBOM inventories components. Vulnerability status changes over time and should be handled through correlation, product-context analysis, advisories and, where appropriate, VEX or CSAF records. BSI TR-03183-2 expressly keeps vulnerability information out of a conforming SBOM.

How often should an SBOM be updated?

Create an SBOM for each software version or update and issue a revised SBOM when underlying component information is corrected or becomes known. Do not overwrite the evidence for an older shipped release.

How long should the SBOM be retained?

Keep it with the technical documentation under the manufacturer’s retention process. Article 13(13) requires the technical documentation and EU declaration of conformity to remain at the disposal of market surveillance authorities for at least 10 years after the product is placed on the market or for the support period, whichever is longer.

Are the CISA 2026 Minimum Elements EU law?

No. The document itself says the minimum elements do not create new requirements. They are a current international implementation baseline that can inform a manufacturer’s Cyber Resilience Act SBOM profile, subject to EU implementing acts, standards and customer obligations.

Is this article legal advice?

No. This is an educational implementation summary. Product scope, category, conformity route and final SBOM profile should be confirmed against the official Regulation and qualified legal or regulatory advice where needed.

Are hashes, licenses and signatures expressly required by the CRA text?

The CRA text requires an SBOM in a commonly used machine-readable format covering at least top-level dependencies, but it does not publish a field-by-field list naming every hash, license or signature element. BSI TR-03183-2 and the 2026 Minimum Elements supply those implementation details. Treat them as profile requirements where adopted, not as quotations from the Regulation.

Is an Excel spreadsheet or PDF an SBOM?

A PDF report is a human-readable view, not a dependable machine-processable SBOM. A spreadsheet can be a working inventory, but it is a weak canonical record for dependency graphs, identifiers, validation and exchange. Use CycloneDX or SPDX as the controlled record and generate human views from it.

Should a CRA SBOM be signed?

Signing is not spelled out as a stand-alone field requirement in the CRA SBOM sentence. It is nevertheless part of the 2026 Minimum Elements and ENISA’s recommended lifecycle because recipients need authenticity, integrity and a strong SBOM-to-artifact binding. For a defensible profile, sign or attest the release SBOM and verify it on intake/retrieval.

What is the difference between an SBOM and VEX?

An SBOM states which components are in a specific software version. VEX communicates whether a known vulnerability affects that product in context—for example affected, not affected, fixed or under investigation. Vulnerability knowledge changes; the composition record for an immutable release should not be rewritten every time a CVE database changes.

Can I reference a supplier’s SBOM instead of merging it?

Yes, if your profile controls the reference. Preserve the referenced component’s creator, name and version, validate the supplier document and keep it available for as long as your product evidence must be retained. If the link can disappear or describe a different artifact digest, reference-only is not adequate evidence.

What should I do when a component version or producer is unknown?

Record it explicitly as unknown or withheld under your format/profile convention, preserve any filename/hash/URI evidence available and create a correction task. Do not invent a version to make the file look complete. Repeated unknown identity for security-relevant components should fail the release or supplier-acceptance gate.

Does generating an SBOM make a product CRA-compliant?

No. The SBOM is one Annex I vulnerability-handling artefact inside the wider duties for risk assessment, secure product properties, vulnerability remediation, disclosure, updates, technical documentation, conformity assessment and CE marking. A polished SBOM cannot compensate for an insecure or unsupported product.

Official sources

• EUR-Lex: Regulation (EU) 2024/2847, the Cyber Resilience Act
• CISA and partner agencies: 2026 Minimum Elements for a Software Bill of Materials
• CISA: Software Bill of Materials
• BSI: Technical Guideline TR-03183, including Part 2 on SBOMs
• SPDX: Overview
• OWASP: CycloneDX
• ENISA: Technical Advisory for Software Bill of Materials, 22 October 2026
• ENISA: SBOM Adoption State of Play — 2026
• CISA: Types of Software Bill of Materials (SBOM)
• CycloneDX: Specification Overview
• SPDX: Specification version 3.0.1

Disclosure: I am the author of From Code to CE Mark. Amazon controls final pricing, availability and delivery. Read the site Privacy, Disclosure & Terms.