Read this first
CISA, with the NSA, the FBI, and international partners, published the 2026 Minimum Elements for a Software Bill of Materials (SBOM), which updates and replaces the minimum elements the NTIA set in 2021. It adds roughly ten new data fields and reworks several existing ones. The headline changes: every component now needs a cryptographic hash, the SBOM itself can carry an author signature so a recipient can confirm it is genuine and unaltered, coverage must reach transitive dependencies, identifiers must be machine-processable, and the whole thing now explicitly applies to open-source, AI software, and SaaS. Why now: the 2021 list was a floor the tooling has long since outgrown, and supply-chain risk work has moved from documents people read to records machines check.
Ask a security team for a list of what is inside their software and, if they have one at all, it is usually a software bill of materials: an inventory of the components and dependencies a product ships, the way an ingredients list sits on the side of a box. Since 2021 the floor for that list has been the minimum elements the National Telecommunications and Information Administration published under the Executive Order on cybersecurity. That document did its job. It also aged. Tooling, formats, and the questions people ask of an SBOM all moved on, and the floor stayed where it was.
In late July 2026, CISA moved it. Together with the National Security Agency, the Federal Bureau of Investigation, and a set of international partners, it published the 2026 Minimum Elements for a Software Bill of Materials (SBOM), a document that, in CISA's own framing, "updates and replaces" the 2021 NTIA baseline. It is the first full revision in five years, and it was shaped by a 2025 public comment period that drew more than ninety responses. This is not a rewrite of what an SBOM is for. It is a raising of what counts as a complete one.
What actually changed
The revision keeps the shape of the old list and adds to it: about ten new fields, plus renames and clarifications to several existing ones. The changes that matter most in practice:
- A cryptographic hash for every component. Each component now carries a hash value and the hash algorithm that produced it, so a consumer can confirm the component they received is the exact one the SBOM describes, rather than a look-alike.
- A signature on the SBOM itself. The guidance adds an author-signature field so a recipient can confirm an SBOM is genuine and unaltered. The document stops being a claim you take on faith and becomes a record you can check.
- Depth, not just the top layer. Coverage is expected to reach all components including transitive dependencies, the dependencies of your dependencies, which is where most real supply-chain risk actually lives.
- Machine-processable identifiers. The old "other unique identifiers" becomes "component identifiers" and is expected in a form software can parse, not prose a human has to read.
- Provenance about the SBOM. New fields record the tool name and version that generated it and the generation context, the point in the lifecycle where it was produced.
- Licenses and clearer names. Component license is now a minimum field, "supplier name" becomes "component producer," and "author of SBOM data" becomes "SBOM author."
- Wider scope. The minimum elements now apply to SBOMs for all software, and the document says so explicitly, including open-source software, AI software, and software-as-a-service.
Why CISA did this
The stated reason is maturation. The 2021 minimums were written when SBOM tooling was young, and they set a floor generous enough that almost anything counted. Five years on, the formats (CycloneDX, SPDX) are mature, generators are common, and the weak link is no longer whether a bill of materials exists but whether it is trustworthy, deep, and machine-readable enough to act on. The new fields target exactly those gaps: hashes and a signature for integrity, transitive coverage for depth, machine-processable identifiers and generation provenance for automation.
Underneath that is a purpose CISA has been consistent about. An SBOM is a building block of software security and supply-chain risk management: a way for an organization to understand what its software is made of and make risk-informed decisions about it. The 2026 revision reflects a world where the party reading the bill of materials is increasingly a machine, a build gate, a policy engine, an agent updating a dependency, and a document that a person had to eyeball is no longer good enough. Raising the floor here is a bet that the next phase of supply-chain security runs on lists that software can verify at speed, not documents that people file away.
Why it lands close to our work
We build the cryptographic version of exactly this. A software bill of materials tells you which packages you ship; a cryptographic bill of materials (CBOM) tells you which cryptography you run, which is the question a post-quantum migration turns on. You cannot replace an algorithm you have not enumerated, and the cryptography that will hurt you is rarely the piece you already know about. The two inventories are siblings, and the direction CISA just pushed the SBOM in is the direction the CBOM already points.
Two of the new SBOM fields are worth dwelling on for anyone thinking about the quantum transition. First, the component hash: the guidance now expects every component to name its hash algorithm, and that algorithm is itself cryptography, exactly the kind of detail a cryptographic inventory captures. Second, the author signature: moving an SBOM from "trust the sender" to "verify the record" is the same shift we argue for with attestation and a machine-readable crypto posture. A signed, hash-anchored, dependency-deep inventory is only useful if the signatures and hashes underneath it are themselves quantum-resistant, which is the part the standard does not yet ask about, and the part worth watching next.
The point
The point
The 2026 minimum elements are not a dramatic document, and that is the point. They take a list people treated as a compliance checkbox and quietly make it something a machine can verify: hashed, signed, deep, and parseable. The center of gravity in supply-chain security is moving from producing a bill of materials to being able to check one, and CISA just wrote that into the floor.
For teams, the practical read is short. If you already generate an SBOM, check it against the new fields: are your components hashed, is the SBOM signed, does coverage reach transitive dependencies, are your identifiers machine-processable. If you are running a post-quantum program, treat this as the adjacent standard it is: the same inventory-and-verify discipline, one layer down at the cryptography, and a reminder that the hashes and signatures now required of an SBOM are themselves on the migration list.
References
- CISA, 2026 Minimum Elements for a Software Bill of Materials (SBOM) - the guidance itself and the linked PDF.
- CISA news release: CISA and Partners Unveil Updated Software Bill of Materials Resource - the announcement, co-authors, and scope.
- NTIA, The Minimum Elements for an SBOM (2021) - the baseline this revision updates and replaces.
- quantakrypto: build a CBOM with qScan - the cryptographic sibling of the SBOM.