Use the checklist to verify that the SBOM is not just a one-time export. It should be tied to product versions, updated through the lifecycle, usable for vulnerability triage and connected to technical documentation. Track who owns generation, validation, storage and update of the SBOM, and preserve enough dependency context to respond when a component vulnerability appears.
Confirm That an SBOM Process Exists
Annex I Part II point 1 requires manufacturers to identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials. The first readiness question is therefore whether each relevant product has a repeatable SBOM process rather than a one-off manual export.
Use a Commonly Used Machine-Readable Format
The CRA requires the SBOM to use a commonly used and machine-readable format. Record the format, generation method and toolchain used so the organisation can reproduce the SBOM and adapt if future implementing acts further specify format or elements.
Cover at Least Top-Level Dependencies
The express legal minimum is coverage of at least top-level dependencies. Readiness work should also ask whether deeper transitive dependency visibility is needed for effective vulnerability handling, because security impact can arise below the first dependency layer.
Associate the SBOM With a Product Release
Store the product version, release identifier or build context associated with each SBOM. Without release context, a team may know that a vulnerable component exists somewhere in the product line without being able to determine which supported versions and customers are affected.
Validate Component Identity and Version Data
Check that component names, versions, package identifiers and supplier or maintainer information are sufficiently accurate for vulnerability matching. An automatically generated SBOM can still contain aliases, missing versions or duplicated component records that weaken incident response and technical evidence.
Connect SBOM Data to Vulnerability Intelligence
The SBOM should support vulnerability handling, not sit in a separate compliance archive. Product security should be able to use component records to identify affected releases, assess exploitability, assign remediation work and track security updates when a dependency vulnerability is disclosed.
Keep the SBOM Current as Dependencies Change
Create review triggers for dependency additions, upgrades, removals, major build changes and new product releases. The current SBOM should reflect the shipped product version, while historical SBOMs remain available for supported older releases.
Include the SBOM in the Technical Evidence Set
Annex VII links the SBOM to vulnerability-handling information in the technical documentation. The readiness checklist should therefore confirm that the SBOM can be retrieved with the architecture, cybersecurity risk assessment, test evidence and vulnerability-handling records for the same product version.
Distinguish SBOM Creation From User Disclosure
The manufacturer must draw up the SBOM. Annex II separately addresses the situation where the manufacturer decides to make the SBOM available to users. The checklist should therefore have separate fields for SBOM existence and any user-access decision.
Prepare for Authority Requests
Market surveillance authorities can request relevant SBOM information in specified circumstances. Confirm that the organisation knows where the SBOM is stored, who can provide it and how the product version and component data will be explained if an authority asks for it.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.