Under the Cyber Resilience Act, manufacturers must identify and document vulnerabilities and components in products with digital elements, including by drawing up a software bill of materials (SBOM) in a commonly used, machine-readable format that covers at least the product's top-level dependencies. The SBOM is part of the manufacturer's vulnerability-handling and technical-documentation work; the CRA does not create a general requirement to publish every SBOM to customers or the public.
What the CRA actually requires
The core SBOM obligation appears in Annex I, Part II of Regulation (EU) 2024/2847. As part of vulnerability handling, manufacturers must identify and document vulnerabilities and components contained in their products, including by drawing up an SBOM in a commonly used and machine-readable format covering at least the top-level dependencies.
The Regulation defines an SBOM as a formal record containing details and supply-chain relationships of components included in the software elements of a product with digital elements. This makes the SBOM more than a package list. It is a structured record of what software components belong to the product and how those components relate to its software supply chain.
The main CRA obligations apply from 11 December 2027. Product teams therefore have time to turn SBOM generation into a controlled lifecycle process rather than treating the requirement as a file-format exercise shortly before conformity assessment.
Top-level dependencies are the legal minimum, not the operational ceiling
Annex I sets a clear minimum: the SBOM must cover at least the product's top-level dependencies. The Regulation does not say that the base requirement stops manufacturers from recording deeper dependency relationships, nor does it state that every transitive dependency must always appear in every SBOM.
For implementation, teams should distinguish the legal floor from the visibility they need to operate the product securely. A first-level component may itself contain or depend on many other libraries. If a vulnerability appears in one of those deeper components, the response team may need enough dependency information to determine whether the affected code is present, reachable and relevant to a supported release.
A useful internal policy therefore defines what "top-level" means for the organisation's build and dependency model and then records additional dependency depth where it improves vulnerability analysis. The important point is not to silently claim full transitive coverage when the generation process cannot prove it.
Machine-readable means the record must support tooling
The CRA requires a commonly used and machine-readable format. The base Regulation does not name one mandatory SBOM syntax such as CycloneDX or SPDX. Article 13(24) gives the European Commission power to specify the format and elements of the SBOM by implementing acts, taking European or international standards and best practices into account.
That distinction matters for teams choosing tooling today. The objective should be a structured, parseable SBOM with stable component identities and relationships, not a PDF or manually maintained spreadsheet that cannot be processed reliably by security tools.
The German Federal Office for Information Security, BSI, provides useful technical implementation guidance in TR-03183. Its Part 2, "Software Bill of Materials (SBOM)", is currently published as Version 2.0.0 and describes formal and technical SBOM requirements. BSI also publishes a CycloneDX namespace to assist teams using that guideline. TR-03183 can help make an implementation concrete, but it is technical guidance and should not be presented as the CRA legal text or as a substitute for applicable EU requirements and future standards.
Keep each SBOM tied to an exact product context
An SBOM becomes operationally weak when nobody can say which product version it describes. A useful lifecycle record should therefore be scoped tightly enough that a vulnerability analyst can connect a component to the correct released product.
For each generated SBOM, engineering teams should retain context such as:
- product name, family and variant;
- exact release or version identifier;
- build or artefact identifier where relevant;
- generation timestamp and generator version;
- SBOM format and specification version;
- component names, versions and stable identifiers;
- known dependency relationships;
- source or supplier information where available; and
- a durable link to the release evidence that produced the record.
These fields are practical implementation recommendations rather than a claim that the CRA prescribes one universal metadata template. Their purpose is to make the legal component record usable when the product changes over time.
Do not overwrite an old release SBOM when a new version is built. Historical SBOMs can be important when a vulnerability is discovered months after a release, because the affected customer population may still be running older supported versions.
The SBOM belongs inside vulnerability handling
The location of the SBOM requirement in Annex I is significant. It appears in the vulnerability-handling requirements, alongside duties to address and remediate vulnerabilities, apply regular security tests and reviews, disseminate information about fixed vulnerabilities, and securely distribute updates.
This means SBOM generation should connect to the vulnerability process rather than operate as an isolated compliance export. When a new vulnerability is disclosed, the team should be able to use the component record to answer questions such as:
- Is the affected component present in one of our products?
- Which supported releases contain the relevant version?
- Is the vulnerable code used in the product's actual configuration?
- What technical exposure or mitigating controls exist?
- Which engineering owner must investigate and decide the treatment?
- Which remediation and verification evidence belongs to the affected release?
An SBOM can establish component presence and relationships. It does not, by itself, prove that a vulnerability is exploitable in the product, that the product is affected in a particular configuration, or that a CRA reporting threshold has been met. Those remain separate product-security decisions that need their own reasoning and evidence.
Include third-party components in the operating model
The CRA also requires manufacturers to exercise due diligence when integrating third-party components so that those components do not compromise the cybersecurity of the product, including free and open-source software components that have not been made available on the market in the course of a commercial activity.
A release-specific SBOM gives that due-diligence process a factual starting point. It can show which third-party components are present and which versions need monitoring. The manufacturer still needs processes for evaluating component security, receiving vulnerability information, assessing product impact, applying fixes and preserving decisions.
This is especially important for dependencies that move independently of the product's own source code. A supplier update, operating-system package change or embedded library replacement can change the component inventory even when the visible product feature set is unchanged.
What belongs in technical documentation
Annex VII connects SBOM work directly to technical documentation. The description of the manufacturer's design, development, production and vulnerability-handling processes includes information and specifications about vulnerability handling, including the SBOM, coordinated vulnerability disclosure policy, evidence of a vulnerability-reporting contact address and the technical solutions chosen for secure update distribution.
Annex VII also lists, where applicable, the SBOM following a reasoned request from a market-surveillance authority when it is necessary for that authority to check compliance with the essential cybersecurity requirements.
The practical implication is that teams should not store the SBOM in a place that is disconnected from the technical documentation and product record. The organisation needs to know which SBOM supports which product and how to retrieve the relevant record when an authorised review requires it.
Does the CRA require public SBOM disclosure?
No general public-disclosure rule follows from the CRA text. Annex II says that if the manufacturer decides to make the SBOM available to the user, the user information must state where it can be accessed. That conditional wording is different from requiring every manufacturer to publish every SBOM.
Public or customer disclosure is therefore a separate policy decision from generating and maintaining the SBOM required for vulnerability handling. Teams should define who may receive an SBOM, what information can be disclosed, how requests are reviewed and how any disclosed version is kept aligned with the relevant product release.
Market-surveillance access is another matter. The Regulation contains mechanisms under which authorities may request relevant SBOM information, including the reasoned request described in Annex VII and Union-wide dependency assessments under Article 13(25). A disclosure policy should distinguish regulatory requests from voluntary user publication.
Build a repeatable SBOM workflow
A practical implementation can be organised as a release workflow rather than an annual documentation task.
- Define the product and release boundary. Decide exactly which software elements and artefacts the SBOM describes.
- Generate from authoritative build inputs. Prefer dependency, package, source and build information that can be reproduced rather than manual entry.
- Normalise component identity. Use stable names, versions and identifiers so vulnerability tools can correlate components consistently.
- Validate minimum coverage. Confirm that top-level dependencies are represented and record known gaps rather than hiding them.
- Retain the release SBOM. Preserve the generated record with the exact product or artefact context and do not silently replace history.
- Connect vulnerability monitoring. Use the component inventory as an input to vulnerability intake and product-impact assessment.
- Record decisions separately. Keep the reasoning for affected/not-affected, exploitability, mitigation and remediation decisions rather than encoding unsupported conclusions into the SBOM itself.
- Regenerate on relevant releases. Dependency changes should produce a new release-specific record and trigger comparison with the previous inventory.
- Link technical documentation. Make the applicable SBOM retrievable from the product's controlled vulnerability-handling and technical-documentation record.
Automation can perform much of the collection and validation, but human accountability still matters where component identity is ambiguous or a vulnerability decision requires product context.
Common SBOM implementation mistakes
Several patterns create a compliant-looking file without a dependable operating process.
- One SBOM for an entire product family. Different variants and releases can contain different components, making later impact analysis unreliable.
- Treating a package-manager lockfile as the complete answer. Lockfiles can be useful inputs but may omit operating-system packages, vendored code, firmware, generated components or manually integrated dependencies.
- Ignoring generation gaps. A scanner that misses a dependency does not make that dependency disappear from the product.
- Equating presence with impact. Finding a component version in an SBOM is a triage signal, not an automatic vulnerability or reportability decision.
- Overwriting historical records. Vulnerability response often needs to reconstruct what was shipped in an older supported release.
- Publishing by default without a disclosure decision. The CRA's generation and authority-access requirements are not the same as a universal public-publication mandate.
- Treating technical guidance as law. BSI TR-03183 and SBOM specifications can guide implementation, but legal obligations should remain traceable to the CRA and applicable EU acts.
Keep SBOM evidence connected over the lifecycle
The durable value of an SBOM comes from its connection to vulnerability decisions, releases and supporting evidence. A component inventory that cannot be linked to the product version under investigation creates additional reconstruction work when a security issue appears.
Generating an SBOM file is only part of the operational problem. Teams also need component identity, vulnerability decisions and supporting evidence to remain tied to the correct product and release as dependencies change. AA-sec is designed around traceability between SBOM, vulnerability work, security evidence and exact product or lifecycle context; the manufacturer still owns the engineering and legal decisions.
A practical readiness check before 2027
Manufacturers can use the remaining implementation period to test whether SBOM work is genuinely operational.
Take one representative supported product and one real release. Generate its SBOM, verify top-level dependency coverage, identify the exact artefact it describes and compare it with the previous release. Then choose a known vulnerability in one component and test whether the team can move from the component record to affected-product analysis, an accountable decision, remediation evidence and the technical documentation without reconstructing the release from scratch.
The result should expose concrete gaps: missing component identities, incomplete generation, unclear product boundaries, overwritten history, disconnected vulnerability records or uncertain ownership. Those are engineering backlog items that can be corrected before the CRA's main obligations apply.
The practical standard to aim for
A CRA-ready SBOM process should let a manufacturer show what software components belonged to a specific product release, preserve at least the required top-level dependency coverage in a commonly used machine-readable format, and use that record as part of vulnerability handling and technical documentation.
The file format matters, but the lifecycle connection matters just as much. A repeatable process that generates, validates, retains and uses release-specific SBOM data gives product-security teams a stronger basis for vulnerability analysis while keeping the legal requirement tied to verifiable engineering evidence.
Official sources
- Regulation (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
- The Cyber Resilience Act - Summary of the legislative text — European Commission
- Commission publishes new guidance to support timely Cyber Resilience Act implementation — European Commission
- BSI TR-03183: Cyber Resilience Requirements for Manufacturers and Products — BSI