Blackfort Technology

SBOM & Cyber Resilience Act: Do You Know What's Inside Your Software?

No SBOM, no CRA compliance — and no fast vulnerability reporting

From 11 September 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities within 24 hours as an early warning — followed by a full notification within 72 hours. Anyone who does not know which third-party components are in their product at that moment risks routinely missing these deadlines.

The Software Bill of Materials (SBOM) is not an optional add-on: the Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers to maintain a complete inventory of all software components as part of their technical documentation — including open-source dependencies, version information and known vulnerabilities. This documentation must be retained throughout the entire support period, typically at least ten years.

The problem: most SBOM projects are still in pilot mode

According to ENISA, 78 % of affected companies have started their SBOM implementation — but 44 % are still in the pilot phase. A pilot SBOM does not meet CRA requirements: it typically does not cover all product lines, does not conform to the required format (CycloneDX ≥ 1.6 or SPDX ≥ 3.0.1) and is not embedded in a repeatable vulnerability-tracking process.

The gap between "we have started something" and "we are CRA-ready" is larger than many companies realise — and the time until September 2026 is short.

What the SBOM→CRA gap report delivers

Blackfort Technology assesses your existing SBOM practices — or establishes a baseline where none yet exists — and evaluates them against the concrete CRA requirements. The result is a structured report with clear recommendations for action:

  • Format conformity: Does your SBOM comply with the CycloneDX ≥ 1.6 or SPDX ≥ 3.0.1 standard as referenced by BSI in TR-03183-2?
  • Completeness: Are all relevant components, dependencies and transitive dependencies captured?
  • Process integration: Is the SBOM generated automatically in the build pipeline and kept current — or is it a one-off snapshot?
  • Vulnerability tracking: Is a process in place to match known CVEs against your component list (e.g. via Dependency-Track, Grype or comparable SCA tools)?
  • Archiving: How is it ensured that SBOM versions remain retrievable throughout the entire support period?
  • Reporting-process readiness: In an emergency, can you demonstrate within 24 hours which products are affected by a vulnerability?

Expertise from real-world implementation

Christian Gebhardt, Managing Director of Blackfort Technology, brings hands-on experience from real ISMS and vulnerability management engagements. He is a member of the ACS AI expert working group and co-author of the ACS/BSI guide on pentesting of LLMs. For your SBOM assessment this means: no abstract regulatory theory, but technically sound analysis with a direct link to the actual CRA requirements.

Blackfort Technology uses established open-source tools such as Dependency-Track (OWASP) for continuous Software Composition Analysis (SCA) and CycloneDX-native toolchains — so that you remain independent of proprietary platforms.

SBOM depth depends on your CRA product class

The specific SBOM requirements that apply to your product also depend on its CRA product class. Manufacturers of Class I or Class II products (Annex III, Regulation (EU) 2024/2847, as specified in Implementing Regulation (EU) 2025/2392) are subject to stricter conformity assessment requirements — and therefore higher expectations regarding documentation depth and process maturity.

Orientation framework: SBOM requirements by product class
Product class Conformity assessment Typical SBOM expectation
Standard Self-assessment (Module A) Complete SBOM, machine-readable, embedded in process
Important — Class I Self-assessment only with harmonised standards/specifications; otherwise notified body SBOM including dependency depth, CVE mapping, demonstrable process
Important — Class II Notified body mandatory SBOM as auditable part of technical documentation; archiving evidenced
Critical (Annex IV) Notified body or EU certification scheme Highest requirements; SBOM part of conformity evidence

If you are not yet sure which class your product falls into, the applicability check on cra-readiness.de is a useful first step.

How the gap report works

  1. Initial call (30 minutes): We capture your product landscape, existing SBOM practices and relevant toolchain.
  2. Document review: You share existing SBOMs, build descriptions and vulnerability processes — in confidence, not shared with third parties.
  3. Gap analysis: Assessment against CRA requirements, TR-03183-2 and your product class.
  4. Report and action plan: Written report with prioritised recommendations, tooling suggestions and a realistic timeline towards September 2026 and December 2027.

A self-service online tool for independent assessment is under development. If you cannot wait: request your gap report directly now.

Frequently asked questions

Is an SBOM actually mandatory under the Cyber Resilience Act?
Regulation (EU) 2024/2847 obliges manufacturers to exercise due diligence with regard to third-party components and to maintain complete technical documentation — an SBOM is a central means of meeting these requirements. Whether a specific form is prescribed in an individual case depends on the product class and the applicable harmonised standards.
Which SBOM format is required for CRA compliance?
The CRA itself does not prescribe a specific format, but refers to technical specifications. The BSI standard TR-03183-2 references CycloneDX ≥ 1.6 and SPDX ≥ 3.0.1 as suitable formats. In practice, CycloneDX is recommended as it is natively supported by Dependency-Track and many CI/CD tools.
How long must an SBOM be retained?
Technical documentation — including the SBOM — must be retained throughout the entire support period of the product, typically at least ten years. The determining factor is the support period stated for the product; for products without an explicit statement, the requirement may apply for longer.
What is the difference between an SBOM and a gap report?
An SBOM is the document itself — the inventory of all software components. An SBOM→CRA gap report assesses whether your existing SBOM practice meets CRA requirements: format, completeness, process maturity, vulnerability tracking and archiving. It identifies specific gaps and prioritised actions.
Does this also affect companies that use open-source software?
Yes. Anyone who integrates open-source components into a commercial product and places it on the EU market is subject to the CRA as a manufacturer — regardless of whether the components are free of charge. The CRA provides relief for open-source stewards, but not for manufacturers who embed FOSS in their products.

Let's talk about your CRA readiness

Request your gap report — we assess your SBOM practice against CRA requirements and deliver a prioritised action plan. Initial call free of charge and without obligation.

Request a first call Check eligibility
The content on this website provides general technical and organizational information on the Cyber Resilience Act (Regulation (EU) 2024/2847) and does not constitute legal advice. Blackfort Technology provides technical/organizational IT-security and compliance consulting, not legal services.