Cyber Resilience Act SBOM Requirements: Building a Usable Component Inventory

Julian Meroi · Published 3 November 2026 · Last reviewed 3 November 2026

Under the Cyber Resilience Act, every manufacturer must identify and document the components contained in its product with digital elements, including by drawing up a software bill of materials (SBOM). The SBOM belongs to vulnerability handling. It is how you find out quickly whether a newly reported vulnerability affects a product release you have placed on the market. This guide explains what the Regulation requires, how to scope and check the inventory for a release, and how to use it when a vulnerability is reported, with a hypothetical example. Annex I Part II(1).

The obligation applies from December 11, 2027. Products placed on the market before that date fall under the CRA’s requirements only if they are substantially modified from that date. The Article 14 reporting obligations already apply, including to those earlier products. Article 71(2), Article 69(2)-(3), CRA reporting requirements guide.

What the Cyber Resilience Act requires

The CRA 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”. The definition covers relationships as well as components, so a flat list that loses which part of the product contains which component serves it poorly. It also covers every component in the software elements, whether developed in-house, bought or taken from an open-source project. Article 3(39).

The requirement itself sits in the vulnerability handling requirements. Manufacturers must identify and document vulnerabilities and components contained in the product, including by drawing up an SBOM “in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products”. Annex I Part II(1).

Two points follow from the wording:

• Top-level dependencies are the floor for the SBOM document. The duty to handle vulnerabilities is wider. Article 13(8) requires that vulnerabilities of the product, including its components, are handled effectively throughout the support period, and Article 13(5) requires due diligence on integrated third-party components, including free and open-source software. A vulnerability in a nested component is still yours to handle, so you need some way to know the nested component is there. Article 13(5), Article 13(8).
• The Regulation does not name a format. It requires a commonly used and machine-readable one. Article 13(24) allows the Commission to specify the format and elements of the SBOM by implementing acts. On November 3, 2026, the Commission’s CRA implementation page did not list such an act. Check the current position before you fix your format choice. Article 13(24).

The recitals explain the purpose: identifying components facilitates vulnerability analysis and helps manufacturers and users track newly emerging vulnerabilities. They also state that manufacturers should not be obliged to make the SBOM public. Recital 77.

Who sees the SBOM. The CRA has several separate routes:

Contracts, procurement rules and other laws can create their own SBOM delivery terms. Review those separately; the CRA routes above do not settle them. Annex VII, Article 13(25), Annex II. Our CRA technical documentation guide covers the rest of the technical file.

Set the product and release boundary

An SBOM describes the software elements of one product, so start from the product as you place it on the market: its firmware, applications and any remote data processing that forms part of the product. A remote service is part of the product only where its software is designed and developed by you or under your responsibility and the product cannot perform one of its functions without it. Our CRA product classification guide explains how to settle the product boundary, and the CRA risk assessment guide uses the same boundary. Article 3(1)-(2).

Then tie each inventory to a release. The technical documentation identifies the software versions affecting compliance, and an SBOM is only useful in vulnerability handling if you know which shipped version it describes. Both the international minimum elements and BSI’s technical guideline expect one SBOM per software version. The CRA itself does not fix a naming scheme or a trigger. Annex VII point 1(b).

Within each release, sort the software into three groups:

• Your own code, which you build, so you can identify it fully, including any third-party code copied or vendored into your repository.
• Components you integrate directly, such as an operating system, a library or a supplier’s binary module.
• Components nested inside those, which you may know about only from a supplier’s SBOM, your own analysis or not at all.

Record what you do not know. A component whose contents are unknown is different from one you have checked and found to contain nothing further. The 2026 Minimum Elements ask SBOM authors to state explicitly when information is unknown or withheld, and ENISA’s SBOM advisory recommends documenting these “known unknowns”. ENISA advisory, section 4.1.2.

Choose a format and the information to record

In practice, “commonly used and machine-readable” points to the two widely used formats, SPDX and CycloneDX. Pick an officially released version of one specification and validate your output against that version’s schema. The 2026 Minimum Elements also advise against producing SBOMs for new software in deprecated format versions. ENISA advisory, section 2.1.

Beyond the format, the CRA does not list data fields. The guidance documents do, and the table shows what each kind of information is for and where the expectation comes from.

This is an example of implementation based on the 2026 Minimum Elements, BSI TR-03183-2 v2.1.0 sections 4 to 6 and ENISA’s SBOM advisory. Apart from the definition in Article 3(39) and the format and top-level dependency requirements of Annex I Part II(1), these fields are not mandated by the CRA.

BSI TR-03183-2. Germany’s Federal Office for Information Security publishes a technical guideline with its own SBOM profile. Version 2.1.0 requires JSON or XML in CycloneDX 1.6 or later or SPDX 3.0.1 or later, recursive dependency resolution for every component in the scope of delivery down to the first component outside it, SHA-512 hashes of deployable components, and one SBOM per software version. It also requires that an SBOM claiming conformance to the guideline contains no vulnerability information. These are conditions for conformance to the BSI guideline, which customers or tenders sometimes ask for; they are not the wording of the CRA. BSI TR-03183-2 v2.1.0, sections 3.1, 4 and 5.

Generate and check the inventory

ENISA’s advisory describes a minimum viable implementation: generate the SBOM as part of the build, when dependencies are most accurately known, using the build infrastructure you already have, and store it with the build artifacts. You do not need a particular tool or a full CI/CD pipeline to start, and a generated file is a starting point for the checks below. ENISA advisory, section 4.1.

1. Generate from the release you ship. Use build information where available: package manifests, lock files, build artifacts and container images. Some embedded build systems already produce SBOMs and only need the option enabled.
2. Bring in supplier information. Merge or reference supplier SBOMs, and check that each one matches the version you actually integrate and any changes you made to it. A supplier SBOM supports your due diligence; the responsibility for the integrated product stays with you. Article 13(5), Commission FAQ, section 4.4.2.
3. Fill gaps. For binary-only components, ask the supplier or use binary analysis, and record what remains unknown.
4. Validate the file. Check the syntax against the format specification, the required fields of your chosen profile and the component identifiers.
5. Check coverage against the release. Compare the SBOM with the system architecture in the technical documentation. Every delivered software element should appear, as a described component or as a recorded gap. Annex VII point 2(a).
6. Protect and store it. ENISA recommends signing SBOMs, controlling access to the generation pipeline and keeping SBOMs in version-controlled, tamper-evident storage linked to the release they describe. ENISA advisory, section 4.2.

This is an example of implementation based on ENISA’s SBOM advisory, sections 2.2 and 4. These workflow choices are not mandated by the CRA, and ENISA states that its recommendations are non-mandatory.

A schema-valid SBOM can still describe the wrong build or miss a component. Schema validation shows that the file is well formed for its format. A vulnerability scan with no findings covers only the components the scanner could identify and match, against the databases and settings it used: wrong or missing identifiers, incomplete analysis or severity filters can all produce no findings. Treat a failed or incomplete check as unresolved. Neither result shows that the product contains no vulnerable component. ENISA advisory, sections 2.2.2, 3.2 and 4.1.2.

Use the SBOM when a vulnerability is reported

The SBOM is most useful when a vulnerability in a component becomes known. A vulnerability should be regarded as known when it is listed in relevant public vulnerability databases, and it may also become known through coordinated disclosure, internal testing or prominent reporting. A report alone does not mean the vulnerability applies to your product: the Commission guidance expects you to investigate and confirm. Commission guidance, paragraphs 233-235.

Our CRA vulnerability handling guide explains the whole process, from receiving reports to issuing security updates and recording decisions.

Keep the reporting obligations in view from the first triage. Once you become aware that a vulnerability contained in the product is actively exploited, Article 14 requires an early warning without undue delay and in any event within 24 hours, followed by further notifications. Remediation does not postpone it. The reporting obligations also continue after a product’s support period ends, when the vulnerability handling obligations of Part II no longer apply. Our CRA reporting requirements guide explains the triggers and deadlines. Article 14(1)-(2), Commission guidance, paragraphs 209-211.

1. Find the affected releases. Match the component and version range in the advisory against the SBOMs of your releases. Include releases whose support period has ended: Part II no longer applies to them, but Article 14 still does.
2. Check for gaps. Where a release records unknown contents for a component that could contain the affected code, a missing match does not clear that release. Resolve the gap with the supplier or by analysis.
3. Watch for active exploitation throughout. If at any point you become aware that the vulnerability is actively exploited, the Article 14 notification runs from that moment, in parallel with the investigation and the fix.
4. Assess applicability. Check whether the vulnerable code is present in your build and whether it can be reached or exploited in the way your product uses it.
5. Record the investigation and the decision. Article 13(7) requires you to document vulnerabilities you become aware of and relevant information from third parties, and to update the risk assessment where applicable. Article 13(7).
6. Remediate. Address and remediate the vulnerability without delay in relation to the risks, including by providing security updates, separately from functionality updates where technically feasible. Once the update is available, share and publicly disclose information about the fixed vulnerability. In duly justified cases, where you consider that the security risks of publication outweigh its benefits, you may delay publication until users have had the possibility to apply the patch. Annex I Part II(2) and (4).
7. Tell the component’s maintainer. Article 13(6) requires you to report a vulnerability you identify in an integrated component to whoever manufactures or maintains it. The Commission guidance limits this to the version you integrate and to vulnerabilities in the component itself. You need not report where you can confirm that the maintainer already knows, or where the component no longer has a maintainer. If you develop a modification that fixes the vulnerability in the component, share the relevant code or documentation with the maintainer. A mitigation that changes another part of your system does not have to be shared. Article 13(6), Commission guidance, paragraphs 222-229.
8. Issue the new SBOM with the fixed release.

VEX and security advisories. Formats such as Vulnerability Exploitability eXchange (VEX) and the Common Security Advisory Framework (CSAF) let you tell customers whether a product is affected by a particular vulnerability. They carry vulnerability status, which changes over time, while the SBOM records what a release contains. BSI keeps the two in separate documents for its profile. The CRA does not require a VEX file. A “not affected” statement records your assessment and is not independent proof. BSI TR-03183-2 v2.1.0, sections 1 and 3.1.

Example: the SBOM of a connected sensor and its dashboard

This continues the hypothetical Example Sensor 1.0 from the CRA risk assessment guide: a network-connected environmental sensor for commercial buildings, with a cloud dashboard developed by the manufacturer that forms part of the product. Firmware 1.0 and dashboard 1.0 are separate software releases, so each gets its own SBOM, and the technical documentation records which firmware and dashboard versions make up the product. All component names and versions below are fictional.

Selected entries from the two SBOMs:

For this example, assume the team has checked the dashboard 1.0 SBOM against the deployed dashboard, including vendored code and nested dependencies, and found no gaps. The firmware 1.0 SBOM has one recorded gap.

A vulnerability is reported. A hypothetical public advisory reports a vulnerability in example-tls versions before 3.1.5.

• Affected releases: the firmware 1.0 SBOM lists example-tls 3.1.4 inside the operating system, so firmware 1.0 is a candidate. The dashboard 1.0 SBOM does not list it, and its coverage was checked with no gaps, so the team concludes that dashboard 1.0 is not affected by this advisory.
• Exploitation: from the first triage, the team looks for information that the vulnerability is actively exploited and would start the Article 14 notification as soon as it became aware of exploitation. It finds none at this point and keeps checking during the investigation.
• The gap: the Wi-Fi module firmware has unknown contents. The team cannot conclude that it is free of example-tls, so it asks the module supplier and records the open question.
• Applicability: the team confirms that firmware 1.0 uses the affected function when connecting to the dashboard, and records the analysis and the updated risk assessment.
• Remediation: firmware 1.0.1 updates example-tls to 3.1.5 through the operating system supplier’s update. The advisory comes from the library’s maintainers, so they already know and no upstream report is needed. Nothing justifies delaying publication, so the team publishes information about the fixed vulnerability once 1.0.1 is available.
• Evidence: the SBOM for firmware 1.0.1, the investigation record, the updated risk assessment and the test report for 1.0.1.

This is an example of implementation based on CRA Annex I Part II, Article 13(5)-(7) and Article 14. The CRA does not mandate these columns, this workflow or these coverage labels. The rows are selected entries, not a complete or schema-valid SBOM, and the evidence listed is planned, not completed.

A complete SBOM for Example Sensor 1.0 would cover every software element of both releases, record the remaining gaps and be checked against the architecture described in the technical documentation.

Sharing, updates and retention

Updates. Generate a new SBOM whenever a release changes its components, and correct an existing SBOM when you discover an error or receive better information about a component. Both the Minimum Elements and BSI distinguish a corrected SBOM for the same software version from a new SBOM for a new version. The technical documentation, including the SBOM, must be continuously updated, where appropriate, at least during the support period. Article 31(2).

Retention. Keep the technical documentation 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. The SBOMs of the releases you place on the market are part of that documentation. The CRA does not set a separate rule for SBOMs of internal builds that were never released; decide that in your own policy. Article 13(13).

Sharing. You decide whether to give users access to the SBOM, and if you do, the user information says where. Customers may still ask for it under a contract, and integrators may need component information to meet their own obligations. ENISA’s advisory and the Minimum Elements both describe controlled ways of sharing, such as a version-specific address or access through an authenticated portal. Annex II points 8(f) and 9.

Where guidance and standards fit

• ENISA’s SBOM advisory (October 2026) gives practical advice on SBOM types, lifecycle, pipeline integration and security. ENISA states that it is non-mandatory and is not a legal interpretation of the CRA, and that its recommended practices may go beyond the CRA’s requirements. ENISA advisory, sections 1.1-1.2.
• The 2026 Minimum Elements (July 2026) were published by CISA with partner agencies from several countries, including EU Member State authorities. They set out baseline data fields and practices, say that they do not create new requirements, and expect coverage of all components, including transitive dependencies. That is deeper than the CRA’s minimum. 2026 Minimum Elements.
• BSI TR-03183-2 defines a stricter profile, described above.
• EN 40000-1-3 is the harmonized standard being prepared for vulnerability handling. Its published scope includes identifying components and the SBOM within the wider vulnerability handling process. On November 3, 2026, the CEN project record showed it as under approval, with citation in the Official Journal expected. A presumption of conformity arises only once the reference is published in the Official Journal, and only for the requirements it covers. Check the published text before relying on its detailed requirements. Our CRA risk assessment guide explains how the EN 40000 parts fit together. Article 27(1).

Check your SBOM before you rely on it

• Each SBOM names the product release it describes, and the versions match the technical documentation.
• Every software element of the release, including remote data processing that forms part of the product, appears as a component or as a recorded gap.
• Relationships show which part of the product contains each component.
• Components carry identifiers that your vulnerability sources can match.
• Supplier SBOMs match the versions you integrate.
• Unknown contents are marked as unknown.
• The vulnerability handling process uses the SBOM, and a past investigation shows how.
• The SBOM is stored with the release and can be provided on request.

How Meroi Security can help

Meroi Security can review your existing SBOMs against the Cyber Resilience Act, identify coverage and version gaps, set up the link between your component inventory and vulnerability handling, and prepare the related technical documentation. Explore our Cyber Resilience Act compliance services.