Annex I Part II · software bill of materials

CRA SBOM consulting

CRA SBOM consulting: building your software bill of materials and vulnerability management

Together with your teams we introduce a software bill of materials per release, generated from the build pipeline, and bring vulnerability findings into one chain with clear rules for rating and remediation. The result is evidence for key requirements of Annex I Part II: the software bill of materials, vulnerability handling and disclosure.

What the CRA requires for the SBOM

Manufacturers must identify and document components and vulnerabilities of their products, including by drawing up a software bill of materials in a commonly used machine-readable format covering at least the top-level dependencies (Annex I Part II(1)). The Regulation does not prescribe a specific format; the Commission may specify format and elements by implementing acts (Art. 13(24)).

The SBOM is part of the technical documentation (Annex VII(2)(b)). Upon a reasoned request, it must be provided to the market surveillance authority where that authority needs it to check compliance with the requirements of Annex I (Annex VII(8)). It becomes effective only through the process behind it: handle vulnerabilities without delay, provide security updates, disclose fixed vulnerabilities. Since 11 September 2026, actively exploited vulnerabilities are also subject to the Article 14 reporting obligation.

The SBOM chain in five steps from left to right. 1 Build: the product build pipeline. 2 SBOM per release: generated automatically, for example CycloneDX or SPDX, stored per version (Annex I Part II(1)). 3 Matching: continuously against vulnerability databases, hits in one place. 4 Assessment: is the finding exploitable in the product, who decides, by when (Annex I Part II(2)). 5 Remediation: security update, separate where technically feasible, then disclosure (Annex I Part II(2) and (4)). An arrow leads back to the build with the next release. A branch leaves the assessment step: if the vulnerability is actively exploited, the Article 14 reporting obligation also applies (in force since 11 Sep 2026), with an early warning without undue delay and in any event within 24 hours of becoming aware. Alongside: the SBOM is part of the technical documentation under Annex VII(2)(b) and must be provided to market surveillance upon a reasoned request, where necessary for the check (Annex VII(8)). Footer: a commonly used machine-readable format covering at least the top-level dependencies; the Commission may specify format and elements (Art. 13(24)).
SBOM chain under Annex I Part II CRA: build, SBOM per release, matching, assessment, remediation.

Service modules

You commission what is missing. We work with your existing tools and processes.

Inventory and selection of SBOM tools

Which scanners, SBOM tools, registries and ticket systems are in use, where they overlap, and which components and products nobody covers. We then decide the toolchain with you.

SBOM from the build pipeline

Automatic generation per release, for example in CycloneDX or SPDX, starting with one reference product, stored per version and fed into analysis.

Check your SBOM now

One chain for findings

Continuously match components against vulnerability databases, collect hits in one place, assign ownership per product.

Rules for rating and remediation

When is a finding exploitable in the product, who decides, by when is it fixed, how are exceptions justified. Separate security updates where technically feasible.

Third-party components

Due diligence for third-party components under Article 13(5), passing SBOM information along the supply chain, reporting vulnerabilities found to the manufacturer or maintainer (Art. 13(6)).

Disclosure and CVD

Coordinated vulnerability disclosure policy, contact address and publication of fixed vulnerabilities after the update (Annex I Part II(4) to (6)).

CVD policy generator

What you end up with

Results that go into the technical documentation and keep running in operations.

  1. 01

    SBOM per release

    Generated automatically from the build, stored per version, available for market surveillance.

  2. 02

    Consolidated findings chain

    One view in which development sees what needs fixing, with ownership per product.

  3. 03

    Target picture and operating guide

    In writing, with a plan for rolling out to further products.

  4. 04

    Evidence under Annex I Part II

    Description of the vulnerability handling processes for Annex VII(2)(b).

How we work

From inventory to a running chain.

  1. 1

    Free initial call

    Products, build environment, existing tools. You then receive a proposal with a clearly defined scope.

  2. 2

    Inventory

    Record tools, gaps and overlaps.

  3. 3

    Target picture

    Agree the toolchain with you, describe rules for rating and remediation.

  4. 4

    Reference product

    Introduce and trial SBOM generation and matching in one pipeline.

  5. 5

    Roll-out

    Extend to further products as planned, hand over to operations.

Christian Gebhardt, founder and managing director of Blackfort Technology

Your contact

Christian Gebhardt · Founder and managing director, Blackfort Technology

Christian Gebhardt, founder and managing director of Blackfort Technology, is happy to take your enquiry personally. In a free initial call you work out together what you need; the consulting is carried out by the Blackfort Technology team.

Profile on LinkedIn

What we do not do

So that expectations are right:

  • We do not carry out penetration tests.
  • No legal services: questions that need a legal decision are flagged for review by your legal department or counsel.
  • You choose the tools; we recommend and set them up. Third-party licences are not included.

The CRA obligations remain with your company. We help you meet them and document the evidence.

Frequently asked questions

Which SBOM format does the CRA require?+

A commonly used machine-readable format covering at least the top-level dependencies. The Regulation does not name a specific format; the Commission may specify it by implementing acts. Examples of such formats are CycloneDX and SPDX.

Do we have to publish the SBOM?+

No. It belongs in the technical documentation and must be provided to market surveillance upon a reasoned request where needed for checking compliance. If you make it available to users, where to access it belongs in the user information (Annex II(9)).

Is an SBOM generated once enough?+

The evidence under Annex I Part II requires the ongoing process: identify components, rate and fix vulnerabilities, provide updates. That is why we generate the SBOM per release from the build.

What does SBOM consulting cost?+

The effort depends on the number of products, the build environment and the existing tools. After a free initial call you receive a proposal with a clearly defined scope.

How does this differ from the Blackfort Technology SBOM service?+

The SBOM service at https://www.blackfort-tec.de/sbom-service is an ongoing service: we generate and monitor your SBOMs and alert you to new vulnerabilities in your components. SBOM consulting sets up the chain in your own development, defines rules for rating and remediation and prepares the evidence for the CRA, so that your team runs it itself. The two can be combined.

Further reading

This content provides general technical and organizational information on the Cyber Resilience Act (Regulation (EU) 2024/2847) and does not constitute legal advice (no legal services within the meaning of the German RDG).

Last updated: 2026-10-09

Get in touch

Request SBOM consulting

Tell us about your products and your build environment. The initial call is free and without obligation; we usually reply within one to two working days.