SBOM requirements compared: NTIA, EU CRA, FDA, and BSI TR-03183
All major SBOM mandates build on the NTIA minimum elements, but they diverge in depth, format strictness, and lifecycle expectations: the EU CRA ties SBOMs to conformity, the FDA ties them to device submissions and postmarket duty, and Germany's BSI TR-03183 is the most precise field-level specification. Build one pipeline to the strictest requirement and every other mandate is covered by construction.
SBOM mandates are multiplying, and teams keep asking the same question: do we need a different SBOM for each regulator? The answer is no, provided you build to the strictest interpretation once. Here is how the four most important specifications compare.
NTIA minimum elements: the shared floor
Published under a US executive order, the NTIA minimum elements define the baseline everyone else references: supplier, component name, version, unique identifiers, dependency relationships, author, and timestamp, in a machine-readable format such as CycloneDX or SPDX, with known-unknowns handled honestly.
Two details are widely under-implemented. First, dependency relationships are required: a flat list of components without the graph does not meet the floor. Second, known-unknowns must be declared: where the inventory is incomplete, it must say so, rather than silently presenting partial coverage as complete.
EU CRA: SBOM as conformity evidence
The Cyber Resilience Act requires manufacturers to produce an SBOM covering at least the top-level dependencies of a product with digital elements. The letter of the requirement is modest; the practice will not be, because the SBOM sits inside technical documentation that market surveillance authorities can examine, and because the CRA’s vulnerability-handling duties are only performable with component-level visibility underneath. An SBOM that cannot support “which of our products contain this newly disclosed component” fails the regulation’s purpose even where it meets its text.
FDA: SBOM attached to a legal submission
For medical cyber devices, US law now requires premarket submissions to include an SBOM covering commercial, open-source, and off-the-shelf components. Two things distinguish the FDA context. The SBOM is part of a legal submission, so accuracy standards are effectively evidentiary. And the accompanying expectation of postmarket vulnerability management means the SBOM must live on after clearance: when a new vulnerability is disclosed, the manufacturer is expected to know which fielded device versions carry the affected component, ideally without rescanning devices in the field.
BSI TR-03183: the precision benchmark
Germany’s federal cybersecurity agency published TR-03183 as a technical requirement for products, and its SBOM part is the most precise field-level specification in circulation: exact required attributes per component, format expectations, depth requirements, and explicit treatment of unresolvable components. It anticipates CRA conformity practice, which makes it the smart engineering target: an SBOM pipeline that satisfies TR-03183 will sail through the vaguer mandates. Our TR-03183 guide covers the field mapping.
The one-pipeline strategy
Build a single SBOM capability with these properties and all four mandates are satisfied simultaneously:
- Generated from real dependency resolution in the build, never assembled by hand. Accuracy failures in hand-built SBOMs are the top reason auditors reject them.
- Complete transitive graph, not just top-level. Mandates are converging on depth, and the vulnerability-handling duties need it regardless.
- CycloneDX with full metadata: identifiers, relationships, hashes, licenses, generation provenance, timestamps.
- Known-unknowns declared explicitly, satisfying NTIA and TR-03183 and building auditor trust everywhere.
- Regenerated per release and stored, so that historical builds remain answerable when the next disclosure lands.
That last property quietly matters most. Every mandate is drifting from “produce a document” toward “operate a capability”: the SBOM as the living substrate for vulnerability management across shipped versions. That is the design center of SecuDep for generation and BOMNexa for lifecycle management, both fully offline, which regulated build environments tend to appreciate.