CVD Portal
← All tools
Free Tool

SBOM Validator (BSI TR-03183-2 and CISA 2026 Minimum Elements)

Upload or paste a CycloneDX or SPDX JSON SBOM and check it against BSI TR-03183-2 v2.1.0, the German federal guideline that concretises the CRA SBOM requirement. The validator verifies the minimum specification version of CycloneDX 1.6 or SPDX 3.0.1. It checks every required data field for the SBOM and for each component, including creator, timestamp, dependencies, licences, and hashes. Validation runs entirely in your browser. The same document is also assessed against the 2026 Minimum Elements for a Software Bill of Materials, version 2.1. CISA published this specification with seventeen partner agencies, including seven EU national cybersecurity authorities. That document replaced the 2021 NTIA minimum elements and expanded the field count from seven to seventeen. It is not EU law and creates no CRA obligation, but it is increasingly what procurement asks for. The two verdicts are reported separately and never blended because the frameworks disagree on key requirements. TR-03183-2 sets minimum format versions that the 2026 elements do not. In addition, the 2026 elements require transitive dependency coverage that CRA Annex I Part II(1) does not.

Last updated 29 August 2026

Key takeaways

  1. BSI TR-03183-2 version 2.1.0 sets CycloneDX 1.6 or SPDX 3.0.1 as the minimum SBOM format versions.
  2. CRA Annex I Part II(1) requires a software bill of materials in a machine-readable format, covering at the very least the top-level dependencies.
  3. BSI TR-03183-2 requires component entries to include creator, name, version, dependencies, licences, and SHA-512 hashes.
  4. The 2026 Minimum Elements for a Software Bill of Materials, version 2.1 expands required data fields from seven to seventeen.

Validate your SBOM against BSI TR-03183-2 and the 2026 Minimum Elements

Upload or paste a CycloneDX or SPDX JSON document. Validation runs entirely in your browser. Your SBOM is never uploaded or stored.

Frequently asked

What does BSI TR-03183-2 require from an SBOM?
TR-03183-2 is the German Federal Office for Information Security (BSI) technical guideline on SBOMs for the Cyber Resilience Act. Version 2.1.0 requires a machine-processable SBOM in CycloneDX 1.6 or later, or SPDX 3.0.1 or later. It requires one SBOM per software version and a defined set of data fields. Top-level fields include the SBOM creator and timestamp. For each component, it requires creator, name, version, filename, dependencies, distribution licences, and a SHA-512 hash of the deployable form. It also requires the executable, archive, and structured properties.
Is an SBOM mandatory under the CRA?
Yes. CRA Annex I Part II(1) requires manufacturers to identify and document vulnerabilities and components. It requires a software bill of materials in a commonly used and machine-readable format, covering at the very least the top-level dependencies of the product. TR-03183-2 is the most concrete official guidance available on how to fulfil this.
My SBOM is CycloneDX 1.4 or SPDX 2.3. Is that a problem?
Older versions still parse and remain useful, and TR-03183-2 includes a transitional system. However, the current guideline sets CycloneDX 1.6 and SPDX 3.0.1 as the minimum for a newly generated or updated SBOM. Most SBOM generators can already emit CycloneDX 1.6, so upgrading is usually a one-flag change in your build pipeline.
Does this tool upload my SBOM anywhere?
No. Validation runs entirely in your browser using the same open logic that CVD Portal uses server-side. Your SBOM never leaves your machine when you use this page.
Can vulnerability information be included in the SBOM?
TR-03183-2 explicitly says an SBOM MUST NOT contain vulnerability information, because SBOM data is static per software version while vulnerability knowledge changes daily. Vulnerability communication belongs in separate documents such as CSAF security advisories or VEX. CVD Portal publishes CSAF 2.0 advisories for exactly this purpose.
What changed in the 2026 SBOM Minimum Elements compared with the 2021 NTIA version?
The data fields went from seven to seventeen. Ten are new, including the SBOM author signature, the tool name and version, the generation context, component hashes and component licences. Supplier Name was replaced by Component Producer because the old term was ambiguous around distributors. Depth was replaced by Coverage, which now requires all components including transitive dependencies with no minimum depth. SWID tags were dropped from the accepted formats, leaving SPDX and CycloneDX. Access Control was removed as a standalone element and folded into Distribution and Delivery.
Do the 2026 Minimum Elements apply to me as an EU manufacturer?
No. They are guidance published by CISA with international partners, not EU law, and by their own terms they create no new requirements. Your obligation is CRA Annex I Part II(1), which requires you to identify and document the components in your product. This includes drawing up an SBOM in a commonly used machine-readable format, covering at the very least the top-level dependencies. Note that this is a lower bar than the 2026 Coverage element, so an SBOM built to the CRA minimum will not satisfy the 2026 elements. Seven EU national authorities co-authored the document, so expect customers and procurement teams to cite it.
Why does my SBOM pass one framework and fail the other?
Because they measure different things. BSI TR-03183-2 section 4 sets minimum format versions of CycloneDX 1.6 or SPDX 3.0.1. In contrast, the 2026 Minimum Elements set no version floor and only ask that deprecated versions are avoided. So a CycloneDX 1.5 document can be accepted by one and rejected by the other. Conversely, the 2026 elements ask for fields TR-03183-2 never requested, such as the SBOM author signature and the generation context. This is why the validator reports two separate verdicts rather than one combined score, which would hide the disagreement.

Other free CRA tools

Free SBOM Vulnerability Scanner & Component CVE CheckerA free open source tool and SBOM vulnerability scanner for engineering and security teams. Paste a list of software components (package@version, one per line) or SBOM file entries to instantly generate NVD CVE Database search links for each component. Quickly scan your SBOM tooling output, detect vulnerable transitive dependencies in container and Docker image stacks, and triage open source license and security issues.CSAF 2.0 Advisory ValidatorPaste your CSAF 2.0 JSON advisory and instantly validate the structure against the OASIS CSAF 2.0 schema. Identifies missing mandatory fields, invalid values, and flags common issues that would cause rejection by automated consumers and ENISA tooling.security.txt GeneratorGenerate a standards-compliant security.txt file (RFC 9116) for your product or website. Required by the EU Cyber Resilience Act to make your vulnerability reporting contact discoverable.SBOM Exposure SnapshotUpload or paste a CycloneDX, SPDX JSON document or dependency manifest to scan all declared components against the OSV.dev open vulnerability database. The scanner identifies known CVEs and security advisories with precise version matching, returning an immediate severity breakdown across Critical, High, Medium, and Low vulnerabilities alongside top exposed components. The live interactive scanner is available at /sbom-exposure with no registration required. The tool operates in-request and does not store your SBOM data on our servers. For continuous vulnerability monitoring and full CRA Annex I Part II(1) due diligence, CVD Portal integrates SBOM ingestion with automated alerting and CSAF 2.0 advisory generation.

Ready to automate your CVD programme?

CVD Portal integrates all these tools and handles your Article 13 and 14 obligations automatically.

Start your free portal →