CISA's 2026 SBOM Minimum Elements: What Compliance Does Not Measure
| Interlynk
CISA's 2026 Minimum Elements replace the 2021 NTIA baseline and raise the bar. But compliance is only one of four independent tests an SBOM has to pass. This guide covers accuracy, completeness, structure, and compliance, why FDA and BSI requirements differ, and how to measure all four on every build with sbomqs.
SBOM Compliance, Quality and Minimum Elements
In July 2026, CISA and its partner agencies published the 2026 Minimum Elements for a Software Bill of Materials, replacing the NTIA baseline that had defined the category since 2021. The new version adds several fields the earlier baseline did not include, such as component hashes, license information, the name of the tool that generated the SBOM, and the context in which it was created. It also updates several fields to make the data easier for machines to process.
That is a meaningful step forward. It is also easy to misunderstand.
Whenever a new set of minimum elements is published, the industry tends to treat it as a definition of what a "good" SBOM looks like. Teams check that the required fields are present, confirm that the document passes validation, and move on.
That is where the trouble starts.
A minimum-elements list answers one question: does this SBOM comply with a particular framework? Compliance matters. It is a different thing from quality, and it is not a universal target. Different teams, industries, and regulators expect different information from the same SBOM.
An SBOM Has to Pass Four Filters
Instead of asking whether an SBOM is simply "good," it is more useful to ask what you need it to do. In practice, a reliable SBOM has to pass four independent tests, and each one can fail in a different way.
Filter | The question it answers |
|---|---|
Accuracy | Is the data an accurate representation of the software you actually shipped? |
Completeness | Does the SBOM contain enough of the right information for its intended use? |
Structure | Does it conform to the SPDX or CycloneDX specification it claims to use? |
Compliance | Does it meet the requirements of the specific regulatory or organizational framework that applies to you? |
These filters are independent. An SBOM can be structurally perfect and still describe the wrong software. It can comply with CISA's 2026 baseline and still lack the information your vulnerability-response team needs. It can be accurate and useful internally yet fall short of what a regulator requires.
That is why "we generate SBOMs" and "we generate SBOMs we can rely on" are very different claims.
1. Accuracy
Accuracy is the filter most teams assume they have, and one of the least frequently tested.
An SBOM is a collection of assertions: these components are present, these are their versions, and these are their identifiers. If those assertions are wrong, every process built on top of them is compromised. Better formatting cannot fix inaccurate data.
The problems are often subtle. A source-level scan may report a library that the final build never links. A version may be truncated or guessed. A component name may resolve to the wrong package because the same name is used across multiple ecosystems. The resulting document can look authoritative, pass schema validation, and still list a version of openssl that is not actually present in the product.
When the next OpenSSL vulnerability is disclosed, that one incorrect line can send your team investigating a release that was never affected. Worse, it can lead them to dismiss a release that was.
Accuracy cannot be assessed by looking at the finished SBOM in isolation. It has to be tested against the way the software was actually built, which makes the generation method as important as the file format.
An SBOM created from the wrong build context is not a slightly weaker version of the right SBOM. It is a confident description of software you did not ship.
2. Completeness
The word "complete" sounds absolute, but SBOM completeness is always tied to a purpose. The same document can be complete for one workflow and seriously inadequate for another.
Consider two teams working with the same SBOM. A software-compliance team may need license expressions, copyright statements, and source locations for every component to complete legal review and meet attribution obligations. A product-security team cares more about precise versions and machine-resolvable identifiers, such as package URLs and CPEs, so its tools can match components to known vulnerabilities.
An SBOM can carry extensive licensing information and almost no usable purls. That makes it valuable to the compliance team and nearly useless to an incident responder. The reverse is just as common.
The useful question is not "is this SBOM complete?" It is "is this SBOM complete for the job we need it to do?"
Mature SBOM programs define completeness for each use case and build path. A container release may need application dependencies, base-image packages, and the relationships between them. A license workflow may require a valid SPDX expression for every component before the release can ship. Completeness is a deliberate decision made per use case, not a single box that an SBOM either checks or misses.
3. Validity
Structural validity is the narrowest of the four filters and usually the easiest to automate. The question is straightforward: does the document conform to the SPDX or CycloneDX specification it claims to use? That covers having the right fields, using the correct data types, and validating against the relevant schema.
The SPDX project provides online validation tools, libraries, and build integrations for working with SBOM documents programmatically.
This filter is essential. A malformed SBOM cannot be reliably ingested, compared, signed, stored, or scanned. Structural validity is a foundation, and it is not a quality score.
A schema validator can confirm that a document is shaped correctly. It cannot tell you whether the component list is accurate, whether the document holds enough information for your workflow, or whether it satisfies the requirements of the regulator you answer to.
A validator that checks structure alone gives a green light that means much less than it appears to. Structure is the filter a tool can answer instantly, which is also why it is so often mistaken for the whole picture. If you are choosing between the two dominant formats, our guide on CycloneDX vs SPDX covers where each one fits.
4: Compliance
This is where CISA's 2026 release fits, and where the biggest misunderstanding tends to occur.
Compliance is not a property an SBOM possesses in the abstract. An SBOM is compliant with a specific framework, and those frameworks do not all ask for the same information.
CISA's 2026 Minimum Elements are now the general federal baseline. Sector-specific regulators and other jurisdictions add their own requirements, and some deliberately go much further. An SBOM can satisfy one framework while failing another, and many organizations have to satisfy more than one at the same time.
Framework | Builds on | Notable additional requirements | Who it applies to |
|---|---|---|---|
NTIA Minimum Elements (2021) | The original baseline | Supplier, component name and version, unique identifiers, dependencies, SBOM author, and timestamp | The reference baseline that later frameworks extend |
CISA Minimum Elements (2026) | Replaces the NTIA 2021 baseline | Component hashes, component licenses, generation-tool name, generation context, and renamed fields designed for automation | The current general federal baseline |
FDA Section 524B | NTIA minimum elements and machine-readable SBOM expectations | Per-component support status, end-of-support date, known vulnerabilities, and increasingly a VEX file | Premarket medical-device submissions |
BSI TR-03183 | Extends well beyond NTIA | Machine-actionable creator contacts, SHA-256 executable and source hashes, recursively resolved dependencies, SPDX license identifiers, source and executable URIs, and purls or CPEs | Products covered by Germany's CRA-aligned guidance |
The table is a useful warning against using "compliant" as if it were a single category.
FDA requirements still build on the 2021 NTIA elements and add information the CISA 2026 baseline does not specifically address. For a medical device, it can matter whether a component is actively maintained, no longer maintained, or abandoned, and whether it carries a known exploited vulnerability. We cover those expectations in FDA SBOM Requirements for Medical Devices.
BSI TR-03183 goes further in other areas, asking for cryptographic hashes and resolvable artifact URIs that support automated supply-chain verification under Europe's evolving requirements. Our guide to SBOM requirements for the CRA breaks the TR-03183 fields down in detail.
An SBOM designed to satisfy CISA's 2026 baseline may still be rejected by an FDA reviewer or fall short of TR-03183.
Why "CISA 2026 Compliant" Can Still Leave You Exposed
Seen together, the four filters expose the limit of any minimum-elements list.
Meeting CISA's 2026 requirements means the SBOM passed the compliance test for one framework. It says nothing about whether the components are accurately identified, whether the document holds the data your vulnerability workflow requires, or whether it meets FDA or BSI requirements that may also apply to your product.
None of that is a criticism of the 2026 Minimum Elements. A baseline is meant to set a floor and raise the standard across the industry, and this one does, particularly by adding license and hash data and by making the fields more useful for automated processing.
The mistake is treating the floor as the ceiling. Compliance is necessary. On its own it is neither sufficient nor universal.
How to Measure All Four Filters Continuously
These filters do not require four disconnected programs. They require one workflow that measures each dimension and runs on every build, as close as possible to where the SBOM is generated.
Interlynk's open-source sbomqs tool scores an SBOM across weighted dimensions that map closely to these four filters. Structural and schema checks address structure. Identification, completeness, provenance, integrity, and licensing checks help evaluate accuracy and use-case completeness. Vulnerability-readiness checks confirm that the purls and CPEs your scanners depend on are present before you rely on the results. A dedicated compliance mode validates against a named framework rather than a generic idea of what a "good" SBOM should contain. [5]
A basic CI quality gate can be as small as this:
The right threshold depends on the risk and purpose of the release. Set it higher as the release moves closer to production and to a regulator, and confirm the exact scoring bands against the current sbomqs documentation before you gate on them. [5]
Quality scoring works best paired with framework-specific validation. A medical-device build should be checked against FDA expectations. A product covered by German CRA guidance should be checked against TR-03183. Neither should be graded against a one-size-fits-all list.
Filter | Question it answers | Example control |
|---|---|---|
Accuracy | Is the data true to what we shipped? | Generate the SBOM from the real build context and score identification and integrity. |
Completeness for the use case | Does it contain what this workflow needs? | Require purls and CPEs for vulnerability work, and license expressions for compliance work. |
Structure | Can machines read and process it? | Validate the declared CycloneDX or SPDX document against its schema. |
Compliance | Does it carry the fields our framework requires? | Run the named profile for NTIA, CISA 2026, FDA, BSI TR-03183, or another applicable standard. |
The approach that holds up over time is to gate on all four filters and retain the results for every build. That makes it possible to spot quality drift before an auditor or a security incident finds it first.
The Bottom Line
CISA's 2026 Minimum Elements are a welcome improvement to the SBOM baseline, and organizations should take them seriously. The baseline is a starting point, not the destination.
A minimum-elements list is a compliance check against one framework. Compliance is one of four filters that decide whether an SBOM is actually useful.
The SBOMs teams can rely on pass all four tests. They accurately represent the software that was shipped. They carry the information required for the job at hand. They are structurally valid, so machines can process them. And they meet the requirements of the framework that governs the release, whether that is CISA 2026, FDA Section 524B, BSI TR-03183, or several at once.
Measure compliance alone, and you can keep producing SBOMs that pass a checklist and fail the moment someone needs to use them.
Want to see how your SBOMs perform across all four filters? Run one through sbomqs, Interlynk's open-source toolkit, and validate it against the framework that applies to your product before the SBOM reaches production or a regulator.
Interlynk gives security and compliance teams SBOMs they can rely on: generated from the real build, scored for quality on every build, validated against the framework that applies, and monitored continuously across the lifecycle. Generate in CycloneDX or SPDX and answer the exposure question in minutes. Book a demo · Start free. Trusted by security and compliance teams at 100+ regulated companies.
References
CISA and partner agencies, 2026 Minimum Elements for a Software Bill of Materials: https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom
SPDX Project, tools and libraries: https://spdx.dev/use/tools/
Interlynk, FDA SBOM Requirements for Medical Devices: https://www.interlynk.io/resources/fda-sbom-requirements-medical-devices
Interlynk, SBOM Requirements for the CRA (BSI TR-03183): https://www.interlynk.io/resources/sbom-requirements-for-cra
Interlynk, sbomqs: https://github.com/interlynk-io/sbomqs