For 5 years, the SBOM conversation has been stuck on just generating one, saving it as an artifact, and “it’s done.” That’s what you get from a mandate measuring existence rather than quality: a lot of documents and very little consumption. ENISA’s 2026 adoption survey found more than 60% of respondents naming comprehensive coverage as their top barrier. Cloudsmith puts the share of SBOM data actually used for governance at around 25%. We produced the artifact but still didn’t have an entirely usable inventory!
On July 29, 2026, CISA with NSA, FBI, DOE, NIST, DC3, and a long list of international partners replaced the 2021 NTIA baseline with the 2026 Minimum Elements for a Software Bill of Materials. 14 elements became 23. 13 carried forward, all renamed or redefined. 1 was removed. 10 were added.
This is a better standard, and not by a little. Here’s the argument.
Where the mandate went
The 2021 NTIA SBOM requirements came about after Executive Order 14028, signed May 12, 2021, after SolarWinds told the Department of Commerce to publish them. NTIA delivered on July 12, 2021, a mere 60 days later. That was the entire drafting window.
Given the clock, it was good work. But its weakest choices- one level of dependency depth and no notion of the SBOM as an attributable document are the choices you make with only two months of consideration and a deliverable deadline.
The mandates and requirements have since bounced back and forth. What hasn’t changed is the need to protect our infrastructure, company, and reduce risk & exposure.
The paperwork built on that order has since been rolled back. Selling software to the federal government used to mean signing a form attesting to secure development practices, and agencies were told to collect it. In June 2025, the White House removed the stricter version of those rules. In January 2026, the Office of Management and Budget cancelled the memos requiring the forms at all, telling agencies to decide for themselves based on risk. A proposed rule that would write these requirements into federal contracting has been sitting unfinished since 2023.
Which makes the most interesting fact about the 2026 elements easy to miss: they aren’t an executive order deliverable. Nobody was compelled to write them. CISA put a draft out for comment in August 2025 and published the final roughly a year later, after more than 90 comments. The co-author list runs past the U.S. interagency into ACSC, the Canadian Cyber Centre, NÚKIB, ANSSI, BSI, CERT-In, ACN, METI, and NCO.
Three reasons why the 2026 elements are better
1. Absence finally means something
The most important change isn’t a field. It’s Coverage, the element that replaced Depth.
Under the 2021 baseline, an SBOM only needed one level of dependencies. That made it a partial view by design, and a partial view can’t answer the question everyone actually asks: Do I understand my known vulnerabilities? If a component wasn’t listed, ignorance isn’t bliss; it’s outright scary. You learned nothing; maybe it wasn’t there, maybe the scanner didn’t go that deep, maybe the format dropped it in conversion. Silence carries no information.
Coverage removes the minimum-depth notion, requires transitive dependencies, and states the intent plainly: a recipient should be able to see a new CVE, check the SBOM, not find the affected component, and conclude they aren’t exposed. With that being said, no tool is perfect and false negatives still exist. However, that is a tool issue, not the SBOM requirements.
So absence is now a claim. If a component isn’t listed, you’re telling the recipient a package or dependency isn’t in your software. Every package your tooling drops silently becomes a false statement with your signature on it.
That’s a harder standard, and it should be. Software inventory is the foundation of knowing where you’re exposed. An inventory you can’t search or see what’s missing isn’t an inventory at all; rather, it is a false sense of security.
2. The SBOM is evidence, not just inventory
7 of the 10 new elements describe the document, not the software: SBOM Author, SBOM Author Signature, Data Format Name, Data Format Version, Generation Context, Tool Name, Tool Version, and SBOM Version.
The 2021 spec described software. The 2026 spec describes software and the party making a claim about it — signed, attributable, and versioned, so you know who produced the SBOM, with what tool, at what point in the build, and which revision you’re holding.
Generation Context matters more than it looks. A pre-build SBOM sees declared dependencies. A post-build image scan sees installed packages. Treating those as the same claim has caused years of confusion. Now you have to say which one you did, and more importantly, the SBOM consumer clearly understands in which context the SBOM was constructed.
3. “I don’t know” is a real answer
Explicitly Identifying Unknown Information separates unknown to the author from deliberately withheld. Component Version must declare when a version is unknown. Component Producer requires a fallback when provenance can’t be established. Accommodation of Updates treats errors as normal input to vendor risk management rather than something to quietly correct.
Pair that with Coverage, and the design becomes clear: one isn’t required to know everything. You’re required to stop deleting the evidence that something was there. A declared unknown is an honest gap a recipient can chase. A silent omission is a false statement. Same missing data, but a completely different artifact.
The two elements only work as a pair. A completeness requirement with no way to say “I don’t know” would set a bar nobody could clear honestly. With it, a diligent team can actually meet it.
What this means for open source
The elements apply to all software, explicitly including open source, AI systems, and SaaS. Some of the reaction has been “great, now upstream maintainers owe us 23 fields.” That reading is wrong, and harmful if it sticks.
Look at where the burden lands. The elements that got harder are about the document and the party issuing it: author, signature, tool, format, generation context, version, coverage. Component Producer draws a sharp line between the entity that originated a component and the entity operating the tool that generated the SBOM. It also provides a mandatory fallback for unknown provenance, precisely because much of the open source graph has no clean answer to “who produced this?”
The obligation sits with whoever ships the software and signs the claim. If you build a product on 900 npm packages, you’re the SBOM Author. Your unpaid transitive dependency’s maintainer isn’t.
These elements make the ecosystem more legible without making maintainers the compliance surface — as long as we read them that way.
What you can actually decide
Under the 2021 baseline, an SBOM supported roughly one decision: does a plausible component list exist? Under the 2026 elements, a conforming SBOM supports several:
- Am I exposed to this CVE? Coverage plus Component Identifiers plus transitive dependencies make the negative answer meaningful, not just the positive one.
- How much do I trust this answer? Signature, Author, Tool Version, and Generation Context let you weight the claim instead of taking it whole.
- Did the artifact match the inventory? Component Hash Value and Hash Algorithm, which is why the algorithm is now its own element.
- Can I gate on this? Frequency requires an SBOM per build and per release. Once that’s enforced, an SBOM is something a pipeline or admission controller can act on.
- What changed since last time? SBOM Version turns a pile of files into a diffable history.
None of this makes an SBOM a guarantee of security. It makes it a document you can build a decision on.
This lands right where BOD 26-04 and FedRAMP need it
On June 10, 2026 — 7 weeks before the new elements were published, CISA issued Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk. A BOD is compulsory for Federal Civilian Executive Branch agencies, not just guidance. It supersedes and revokes BOD 19-02 and BOD 22-01, dropping the CVSS requirement for prioritization. Urgency now comes from 4 decision points: public exposure, KEV status, exploit automation, and technical impact. The worst combinations carry a 3-day remediation clock, with 14-day and 60-day tiers below.
Then read what FedRAMP did with it. In Public Notice NTC-0014 (June 16, 2026), FedRAMP stated that the legacy monthly scanning process most Rev5-Certified services follow is insufficient for the assurance agencies now require. Mandatory adoption of the Vulnerability Detection and Response and Vulnerability Evaluation and Reporting rules moved up from June 2027 to December 7, 2026, with a corrective-action grace period to March 7, 2027; after which Certification is revoked.
That’s the enforcement everyone assumed had gone away. It moved from procurement attestation to operational assurance, and it’s on a clock. Put the documents side by side, and they solve for each other:
3 of the 4 decision points are handed to you. CISA supplies KEV status, exploit automation, and technical impact through Vulnrichment. The fourth, exposure, is yours, and exposure is a function of your inventory. You can’t prioritize what you don’t know you’re running.
Unknown defaults to worst case. Where the data isn’t available, the directive defaults to the 60-day timeline and treats an asset of unknown exposure as publicly exposed. Read that against Coverage: a silently dropped package doesn’t give you a safe “no finding.” It gives you an inventory you can’t defend, in a regime where indefensible means assume the worst. Vagueness is now expensive in days.
3 days isn’t a manual answer. When a KEV lands with a 3-day clock, “are we running this component anywhere, including transitively?” has to be a query, not a project. That takes a complete SBOM inventory you can search and know its running location.
Matching depends on identifiers. KEV and Vulnrichment data are keyed to CPE and PURL. Component Identifiers being required is the plumbing that makes the match work.
Be clear about the boundary. An SBOM doesn’t tell you whether an asset is internet-reachable; that’s network architecture, and no scanner infers it. It doesn’t make the SSVC decision, nor does it apply the patch. What it does is make the inventory underneath those decisions trustworthy, and produce the artifact you hand an assessor when they ask how you knew.
If you operate in, or sell into, the federal space: December 7, 2026 is the date, and your SBOM quality is upstream of whether you hit it.
Where Anchore Enterprise is going
3 of the 23 elements aren’t generator problems at all. Accommodation of Updates needs a prior SBOM to correct and reissue against. Distribution and Delivery needs prompt, access-controlled delivery. Frequency needs per-build generation enforced rather than assumed. Those need storage, versioning, access control, and delivery — a platform, not a CLI.
That’s where Anchore Enterprise picks up today: centralized SBOM storage as the authoritative record, re-evaluation of stored SBOMs as vulnerability feeds update, SBOM export for evidence, and CI/CD and admission-control gating that turns Frequency into a gate. Build inventory first, and incident response gets faster as a byproduct. When a KEV drops, you’re querying a record instead of rescanning a fleet.
Over the next few releases, we’re working toward the 2026 elements and CISA BOD 26-04 across the platform. That work includes annotation of the new required fields, validation of those fields for authenticity, SBOM distribution for downstream consumers, and SSVC data to help prioritize and categorize vulnerabilities.
Quick Guides to download :
Not ready to purchase? Here’s how to get started for free:
- Use Syft, Grype, and Grant to get started with open source tools to generate SBOMs, vulnerability results, and license compliance data.
- Save the results and artifacts with each build to have parity, documentation, and SBOM evidence.
- Use tools like cosign for attestation
