SBOM Minimum Elements: what a compliant SBOM must contain

The SBOM Minimum Elements are the baseline fields and practices a Software Bill of Materials must satisfy to be considered usable for software supply chain risk management. The current version, 2026 Minimum Elements for a Software Bill of Materials (SBOM), was published on 29 July 2026 by the U.S. Cybersecurity and Infrastructure Security Agency (CISA) together with the NSA, FBI and 15 other national cybersecurity agencies (Australia's ACSC, Canada's Cyber Centre, Czechia's NÚKIB, France's ANSSI, Germany's BSI, India's CERT-In, Italy's ACN, Japan's METI and NCO, South Korea's NIS/NCSC and KISA, the Netherlands' NCSC-NL, New Zealand's NCSC-NZ, Poland's NASK and Slovakia's NBU). The document states it "updates and replaces" the original Minimum Elements that the U.S. National Telecommunications and Information Administration (NTIA) published on 12 July 2021 under Executive Order 14028.

Where the requirement comes from

Executive Order 14028, "Improving the Nation's Cybersecurity," signed 12 May 2021, directed in Section 4(f): "Within 60 days of the date of this order, the Secretary of Commerce, in coordination with the Assistant Secretary for Communications and Information and the Administrator of the National Telecommunications and Information Administration, shall publish minimum elements for an SBOM." Section 10(j) of the same order defines an SBOM as "a formal record containing the details and supply chain relationships of various components used in building software," comparing it to "a list of ingredients on food packaging." NTIA's resulting 2021 report set the first baseline; the version history recorded in the 2026 document shows two further revisions: a version 2.0 draft published 22 August 2025 for public comment (closing 3 October 2025), and the current version 2.1, finalized 29 July 2026 after incorporating that comment period's feedback.

The 17 data fields

The 2026 document splits data fields into two groups: SBOM Metadata, about the SBOM document itself, and Component Data, about the target component and each subcomponent it enumerates.

SBOM Metadata (9 fields)

Field	Definition
SBOM Author	"The name of the entity that creates the SBOM data for the target component."
SBOM Author Signature	"A digital signature attributable to the SBOM author."
SBOM Data Format Name	"The name of the data format used to represent the SBOM data."
SBOM Data Format Version	"Identifier designated by the SBOM data format to specify the version of the data format."
SBOM Generation Context	"The relative software lifecycle phase and data available at the time the SBOM author generated the SBOM" — e.g. "before build" or "after build."
SBOM Timestamp	"Record of the date and time of the most recent update to the SBOM data."
SBOM Tool Name	"The name of the tool used by the SBOM author to generate or amend the SBOM."
SBOM Tool Version	"Identifier for the version of the tool identified in the SBOM Tool Name element."
SBOM Version	"Identifier designated by the SBOM author to specify a change in the SBOM document from a previously identified version."

Component Data (8 fields)

Field	Definition
Component Producer	"The name of an entity that creates, defines, and identifies components" — replaces the 2021 "Supplier Name" field.
Component Name	"The name assigned by the component producer to a software component." Now allows multiple entries for alternate names.
Component Version	"Identifier used by the component producer to specify a change in a software component from a previously identified version."
Component Identifiers	At least one software identifier, such as Common Platform Enumeration (CPE) or Package-URL (PURL); may also include UUIDs, organization-specific identifiers, commit hashes, OmniBOR or SWHID.
Component License	"The identifiers for the licenses under which the software component is available," ideally using SPDX license identifiers — new in 2026.
Component Hash Value	A cryptographic hash of the executable component artifact — new in 2026.
Component Hash Algorithm	The algorithm used to compute the hash, identified via IANA's hash function text names — new in 2026.
Component Dependency Relationship	"The relationship between two components, where one component is necessary for the operation of the other."

Every "unknown" field should be marked explicitly as unknown rather than left blank — one of the six Practices and Processes below.

The 6 practices and processes

Separate from the data itself, the document sets six baseline expectations for how an organization handles SBOM data across its lifecycle:

Practice	What it requires
Accommodation of Updates to SBOM Data	SBOM authors correct errors promptly; recipients should expect corrections.
Coverage	All components including transitive dependencies, with "no minimum depth" — a 2026 change from the 2021 "Depth" element, which covered only top-level dependencies.
Distribution and Delivery	SBOMs available promptly to those who need them; access controls must not block sharing between authorized parties.
Explicitly Identifying Unknown Information	State whether missing data is unknown to the author or deliberately withheld, rather than leaving it blank.
Frequency	A new or revised SBOM for each software version, build or update.
Machine-Processable Data	Automation support "critical for managing software component data at scale." The document names SPDX and CycloneDX as the two formats "currently widely used by software ecosystem stakeholders to generate and consume SBOMs," and drops SWID tags from the recommended list, stating they are "not a widely used SBOM data format for which multiple tools exist."

What's new versus the 2021 NTIA version

Ten fields were added in the 2026 update, all aimed at letting a recipient trust and process the SBOM automatically: SBOM Author Signature, SBOM Data Format Name, SBOM Data Format Version, SBOM Generation Context, SBOM Tool Name, SBOM Tool Version, SBOM Version, Component Hash Value, Component Hash Algorithm and Component License. Several 2021 fields were renamed or redefined rather than dropped: Supplier Name became Component Producer (the document notes "Supplier Name has proven ambiguous in practice, particularly around distributors of software"), Other Unique Identifiers became Component Identifiers, Depth became the broader Coverage, and Automation Support became Machine-Processable Data. The Access Control element was removed outright, with its substance folded into Distribution and Delivery.

Scope: beyond traditional software

The 2026 document states the minimum elements "apply to SBOMs for all software, including open source software, AI software, and SaaS," while noting that AI systems and cloud/SaaS software "may require additional elements" not covered here — the document explicitly does not introduce AI- or SaaS-specific fields itself, pointing instead to a companion guidance, Software Bill of Materials (SBOM) for Artificial Intelligence – Minimum Elements, issued jointly by CISA and G7 partners in May 2026.

How this relates to the CRA and device firmware

The document states plainly that "the European Union's Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers of products with digital elements to provide an SBOM as part of the technical documentation." The CRA's own text, however, sets a narrower, separate requirement: Annex I Part II point (1) calls for a machine-readable SBOM covering at least top-level dependencies, without formally adopting the CISA-led Minimum Elements as the legal standard. A device maker building firmware for the EU market should treat the CRA text as the compliance floor and the Minimum Elements as a stronger, internationally-recognized baseline to build toward — see our guide on building a firmware SBOM without source code for the binary-analysis side of generating one, and CSAF and VEX for device makers for pairing an SBOM with vulnerability status data, which the Minimum Elements document also calls out as a complementary practice.

SoftWSP generates firmware SBOMs with the Minimum Elements' component-level fields (producer, version, identifiers, hashes) filled in from binary analysis rather than left unknown: see device firmware security.

This guide summarises a public CISA-led, multi-government document; it does not constitute legal or compliance advice.