When people say a document "counts" as an SBOM, they usually mean it meets the NTIA minimum elements. Published in 2021 by the United States National Telecommunications and Information Administration, the minimum elements are the closest thing the SBOM world has to a baseline definition. If you produce SBOMs, this is the spec to know.

The three buckets

The framework groups its requirements into three categories: data fields, automation support, and practices. People remember the first and forget the other two — which is a mistake, because the practices are where most programs fall short.

1. Data fields

For every component in your software, an SBOM must record these baseline data fields:

Supplier name — who created or maintains the component.
Component name — its name.
Version — the precise version string.
Other unique identifiers — machine-readable IDs such as a PURL or CPE.
Dependency relationship — how components relate, including transitive dependencies.
Author of SBOM data — who assembled the SBOM.
Timestamp — when the SBOM was created.

The intent is simple: enough information to unambiguously identify each component and how it fits into the whole, so that when a vulnerability is announced against "library X version Y," you can find it.

2. Automation support

The minimum elements require that SBOMs be machine-readable in a widely supported, automatable format. In practice that means one of the standard formats — CycloneDX or SPDX — not a PDF or a spreadsheet a human has to read. The whole point is that SBOMs can be generated, exchanged, and consumed by tools at scale.

3. Practices and processes

This is the part teams underestimate. The minimum elements describe how SBOMs should be operated, not just what they contain:

Frequency — a new SBOM with every software release, because the inventory changes when the software does.
Depth — as complete a dependency graph as practical, including transitive dependencies.
Known unknowns — explicitly indicating where the component tree is incomplete, rather than silently omitting it.
Distribution and access — SBOMs have to actually reach the people who need them.
Accommodation of mistakes — early-stage SBOMs will be imperfect; the framework expects iteration.

The "known unknowns" clause deserves attention

One of the most quietly important requirements is honesty about gaps. An SBOM that silently omits a portion of the dependency tree is more dangerous than one that flags "this section is incomplete," because it creates false confidence. Good SBOM tooling makes the boundaries of its own knowledge explicit.

Minimum, not maximum

The word "minimum" is doing real work here. Meeting the NTIA elements makes a document a legitimate SBOM; it does not make it a good one. Richer SBOMs add license data, integrity hashes, vulnerability information, and quality metadata. The minimum elements are the floor you build on, not the ceiling you aim for.

The NTIA minimum elements, explained