Minimum SBOM Elements Required Under Executive Order 14028

Executive Order 14028 didn't create SBOM field requirements. It created an obligation and handed the actual definition work to NTIA, then later to NIST and CISA. That distinction explains why the compliance target has already moved once, substantially, and why anyone still building against the 2021 baseline alone is working from a document that no longer governs.

Signed on May 12, 2021, in the aftermath of the SolarWinds and Colonial Pipeline incidents, the order defined a Software Bill of Materials in statute, at Section 10(j), as "a formal record containing the details and supply chain relationships of various components used in building software."" That's a definition. The order gave the Department of Commerce and NTIA 60 days to publish the minimum elements, but it specified no fields of its own. Everything that follows, the seven-field baseline, the 2026 expansion, traces back to that single delegation.

The seven NTIA data fields that became the original compliance baseline

NTIA hit its deadline. On July 12, 2021, it published "Minimum Elements for a Software Bill of Materials (SBOM)," and that document became the de facto compliance target for federal software suppliers for the next five years.

The document organized its requirements into three categories: Data Fields, Automation Support, and Practices and Processes. Automation Support meant machine-readable formats, specifically SPDX, CycloneDX, and SWID tags. A spreadsheet doesn't count. Practices and Processes covered the operational side, frequency, depth, how to handle missing data, and distribution, a category that gets far less attention than it deserves and that this piece returns to later.

The Data Fields category reads like a checklist: seven required fields per component. Supplier Name identifies who makes or distributes the component. Component Name is the name of the software unit itself. Version of the Component pins down the specific release. Other Unique Identifiers are package-level IDs, things like Package URL or CPE, that let tools cross-reference vulnerability databases. Dependency Relationship captures how this component connects to others in the build. Author of SBOM Data records who actually generated the SBOM record, a party that can differ from the supplier. Timestamp marks when the record was created.

Seven fields, three categories, one deadline met. That's the whole 2021 baseline in outline.

What each of the seven fields requires in practice

Reading the field names doesn't tell you what compliance actually looks like day to day, and a few of them carry more operational weight than their one-line descriptions suggest.

Supplier Name sounds simple until you ask who, exactly, counts as the supplier. NTIA's answer is the entity that creates or defines the component, which is not automatically the vendor selling the finished product to an end customer. A software company shipping a product built on an open-source library is a downstream distributor of that library. It's also distinct from the SBOM author field: the person who compiles the SBOM record and the entity that produced the component can be, and often are, two different parties. This ambiguity, particularly around distributors who pass software along without having built it, is exactly the seam that the 2026 update would later pull on.

Component Name needs to be the canonical name, the one used in the actual package registry or repository, not an internal project nickname. Inconsistent naming across SBOMs is a quiet but real problem: automated vulnerability matching depends on names lining up across records, and a tool can't match what it can't recognize.

Version of the Component has to be the exact version string as distributed." This one has teeth. CVE-matching tooling works by comparing a known-vulnerable version range against the version in the SBOM, and if that field is vague, the match simply fails, silently, with no alert that anything went wrong.

Other Unique Identifiers do the heavy lifting that name and version alone can't. A Package URL or a Common Platform Enumeration entry is what lets an automated scanner tie a component to a specific vulnerability database entry without a human cross-checking by hand. NTIA's 2021 language called these "other" identifiers, almost as an afterthought category, which is part of why the 2026 update tightens the requirement to at least one machine-processable identifier rather than leaving it open-ended.

How the 2026 CISA update supersedes the NTIA baseline

On July 29, 2026, CISA released the "2026 Minimum Elements for a Software Bill of Materials (SBOM)," developed alongside NSA, FBI, and sixteen international cybersecurity agencies. This document formally supersedes the 2021 NTIA baseline. It doesn't amend it or run alongside it as an alternative standard, it replaces it.

The scope changed considerably. Where the 2021 document specified seven data fields, the 2026 framework defines 23 elements spread across three groups: nine SBOM Metadata fields, eight Component Data fields, and six Practices and Processes. That's more than a threefold expansion in the number of discrete requirements, and it reflects five years of SBOM tooling maturing from an experimental compliance exercise into something vendors and agencies actually run at scale.

CISA didn't finalize this in a vacuum. The agency opened a public comment period on draft guidance before publishing the final version, and the document that resulted incorporates that stakeholder feedback directly. The involvement of sixteen international partner agencies also signals something the 2021 document never really had: a scope that reaches well beyond a single country's compliance needs. It's shaping into something closer to an international baseline.

The structural change that matters most: how SBOMs must now disclose their own gaps

Most SBOMs generated under the 2021 baseline function as compliance snapshots. A build finishes, an SBOM gets generated, it gets filed somewhere, and it's rarely revisited even as the software it describes gets patched, repackaged, or redeployed. NTIA's "known unknowns" practice gestured at this problem, requiring authors to flag missing fields rather than leave them blank, but it never addressed the deeper issue: an SBOM that says nothing about how or when it was generated gives the recipient no way to judge how much to trust it.

The 2026 update closes that gap structurally, through a new "SBOM Generation Context" field. SBOM authors now have to declare the lifecycle phase at which the SBOM was produced. A manifest-sourced SBOM assembled before a single line of code compiles is a fundamentally different artifact than one generated by scanning the finished binary after build, and under the 2026 rules, that difference has to be stated on the record rather than left for the recipient to guess at. A downstream user can now judge the SBOM's reliability based on how it was made.

The unknown-field handling rule sharpens in the same direction. Where information can't be provided, the 2026 guidance requires the author to state explicitly that the information is either unknown to them or being withheld. Those are not the same failure mode, and treating them as interchangeable, as the 2021 language arguably allowed, obscures that a capability gap and a deliberate redaction, usually made for security reasons, are distinct conditions requiring different responses. The 2026 document also requires that authors maintain a process letting recipients request that withheld, security-sensitive information through an appropriate channel.

One more addition belongs in this section rather than the format discussion: authors must now hash the executable artifact itself. That ties the SBOM to a specific, verifiable build output. A version number can drift or get reused by mistake. A hash can't.

Practices and processes: the non-field requirements that make an SBOM usable or not.

Both the 2021 NTIA document and the 2026 CISA update treat Practices and Processes as a co-equal category. That's a deliberate structural choice, and it's the part of both documents that makes an SBOM either a living artifact or a piece of paperwork nobody will ever open again.

The 2021 baseline set several practices. Frequency: a new SBOM per release. Depth: top-level dependencies at minimum, with transitive dependencies strongly encouraged, since most real vulnerabilities live several layers down the dependency tree rather than in the direct imports. Known Unknowns: label what's missing instead of quietly omitting it. Distribution and Delivery: SBOMs have to reach the purchaser; access controls are allowed, but they can't become a way to functionally deny access to the people who need the document. Accommodation of Mistakes: there has to be a process for fixing and redistributing an SBOM once an error appears, because errors will occur.

The 2026 update builds directly on top of that foundation rather than discarding it. A digital signature requirement for SBOM documents addresses authenticity more formally than before, closing off the possibility of an SBOM whose provenance can't be verified. SBOM generation context, discussed above as a data field, is simultaneously codified as a required practice, reinforcing that it's not optional documentation but a structural expectation of how SBOMs get produced.

Machine-readability runs through both documents as a practice as much as a format rule. SPDX and CycloneDX remain accepted machine-readable formats, and a PDF inventory, however thorough, still doesn't satisfy the requirement under either version. The reasoning hasn't changed since 2021: an SBOM that a machine can't parse is an SBOM that can't be checked against a vulnerability database at scale, and scale is the entire point of having one.