CISA rewrote the SBOM rulebook: what the 2026 Minimum Elements mean, and how monsys already conforms

On 29 July 2026, CISA published the 2026 Minimum Elements for a Software Bill of Materials. It replaces the 2021 baseline that the National Telecommunications and Information Administration (NTIA) wrote, and it was co-authored by an unusually broad coalition: CISA, NSA and FBI alongside Australia's ACSC, Canada's Cyber Centre, Czechia's NÚKIB, France's ANSSI, Germany's BSI, the Netherlands' NCSC-NL, and others.

That coalition matters. It signals that "an SBOM" is no longer a US procurement checkbox. It is becoming the shared, machine-readable language that European regulators expect too, in step with the EU Cyber Resilience Act (CRA) and NIS2.

If you generate SBOMs today, the bar just moved. Here is what actually changed, and what it takes to meet it.

What the 2026 standard asks for

The 2021 baseline had seven data fields and a handful of practices. The 2026 revision keeps those core principles but adds a lot of teeth. The minimum elements now fall into three groups.

SBOM-level metadata (about the document itself):

Component-level data (about each part in the software):

Practices and processes: Accommodation of Updates, Coverage (all components including transitive, with no minimum depth), Distribution and Delivery (an API or URL is now explicitly an acceptable delivery channel), Explicitly Identifying Unknown Information, Frequency, and Machine-Processable Data. On that last point the standard names exactly two acceptable formats: SPDX and CycloneDX.

Why it changed

Three forces drove the rewrite.

Tooling caught up. In 2021, asking every SBOM to be signed or to carry per-component hashes was unrealistic. In 2026 the tools can do it, so buyers are allowed to demand more.

Integrity became the point. The headline addition is the SBOM Author Signature. An unsigned SBOM is just a text file that anyone can edit. A signed one lets the recipient prove the inventory was not tampered with in transit and that it came from who it claims to. That is the difference between "a list" and "evidence".

Regulation converged. The co-authoring list reads like a who's-who of European cyber agencies for a reason. The CRA will require SBOMs for products with digital elements, and NIS2 auditors ask for supply chain visibility. A single, tightened, internationally co-signed baseline is what makes one SBOM satisfy several regimes at once.

The standard even adds a section on correlating SBOMs with security advisories, naming VEX and CSAF explicitly. In other words: an inventory alone is not the goal. You need the inventory plus a per-vulnerability exploitability signal. (We wrote about that pairing when we shipped VEX; it turns out the standard now agrees.)

The parts that are genuinely hard

Most of the new fields are easy if your generator already walks the host. Three are not.

1. The signature. You need a real key, a canonical serialization so the signature is reproducible, and a public verification path. Sign the wrong bytes and every downstream verifier rejects it.
2. Component hashes. The standard wants a hash of each component artifact. A tool that inventories installed metadata (package name and version) does not have the original artifact bytes to hash. Fabricating a hash is worse than omitting one.
3. Honesty about unknowns. The 2026 standard is explicit: state when a value is genuinely unknown rather than leaving it blank or guessing. That sounds soft, but it is a real design constraint, because it forbids the convenient lie.

How monsys conforms

Every SBOM monsys generates, in both SPDX 2.3 and CycloneDX 1.5, already emits the full set. Here is the mapping, element by element.

The signature, done so anyone can check it

Each SBOM is signed with the hub's Ed25519 key. CycloneDX uses its native JSF signature block; SPDX carries the signature in a document-level annotation. Crucially, the signature is computed over the RFC 8785 (JSON Canonicalization Scheme) form of the document with the signature holder removed. That means a third party can re-canonicalize the file, fetch our public key, and verify it offline, with any standard library. It is the same key that signs the monthly Audit Pack, so one public key covers all of our evidence.

Honest about component hashes

monsys does metadata-only host inventory: it reads what the package managers report, it does not pull down and store every binary. So it cannot compute a genuine artifact hash, and it says so, recording Component Hash as unknown rather than inventing a value. That is exactly the behaviour the 2026 standard's "Explicitly Identifying Unknown Information" element calls for. When we add a source that does carry hashes, the field fills in automatically.

What you actually get

Open any host in the dashboard, go to the CVEs tab, and the Audit export bar gives you four one-click downloads:

• SBOM in SPDX 2.3 or CycloneDX 1.5, three layers deep: application dependencies, OS packages, and the running kernel.
• VEX in OpenVEX or CycloneDX-VEX, stating per CVE whether the host is actually affected.

Or pull them straight from the API, which the standard now blesses as a delivery channel:

GET /api/v1/agents/{id}/sbom?format=spdx-json
GET /api/v1/agents/{id}/sbom?format=cyclonedx-json
GET /api/v1/agents/{id}/vex?format=openvex

Every download is signed and offline-verifiable, and the exact same data is bundled into the monthly Audit Pack so your signed evidence matches what your operators can pull on demand.

The bottom line

The 2026 Minimum Elements raise the floor from "a component list" to "a signed, licensed, machine-verifiable inventory paired with an exploitability signal". That is more work for whoever generates your SBOMs. With monsys it is a download, generated inside an EU-hosted platform from data the agent already reports, with nothing sent to third parties.

Read the full standard: 2026 Minimum Elements for a Software Bill of Materials (CISA, TLP:CLEAR). SBOM and VEX are documented at docs.monsys.ai/en/security/sbom-vex. First five servers free: monsys.ai/en/signup.