On July 29, 2026, CISA and a coalition of international cybersecurity agencies published the 2026 Minimum Elements for a Software Bill of Materials (SBOM)—the first full update to the baseline the National Telecommunications and Information Administration (NTIA) defined in 2021. Since that original draft, SBOM tooling has matured, use cases have expanded, and the minimum bar for “what counts as an SBOM” has risen with them.

This post is a practical field map that summarizes what changed with the 2026 minimum elements, with an overview for decision-makers and exact property paths in CycloneDX 1.6, SPDX 2.3, and SPDX 3.0 for implementers.

If you produce, procure, or operate software, best practice going forward is to request and generate SBOMs that satisfy the 2026 elements, in a widely used machine-processable format. CISA explicitly names SPDX and CycloneDX as those formats.

What Changed (for Leaders)

The 2026 document keeps the 2021 principles (nested inventory, automation, and known unknowns) and raises the floor in three ways.

1. Richer document metadata: Authors must identify themselves, the tool they used, the format and version, when the SBOM was last updated, which lifecycle phase produced the data, and, newly, a digital signature attributable to the author.
2. Stronger component identity: “Supplier Name” becomes Component Producer. Licenses and cryptographic hashes are now minimum elements. Identifiers should include at least one common lookup key, such as a Package URL (PURL) or a Common Platform Enumeration (CPE) name.
3. Clearer operating practices: “Depth” becomes Coverage, with no minimum depth but a clear expectation to include transitive dependencies. Unknowns must be called out explicitly, and withheld data is distinguished from genuinely unknown data. Access control is folded into Distribution and Delivery.

CISA is careful to say the minimum elements do not create new legal requirements by themselves. They refine how organizations should generate and request SBOMs. In practice, expect buyers, regulators, and frameworks that already point to the NTIA elements to migrate to this baseline.

 

Change Type	Elements
New	SBOM Author Signature; SBOM Data Format Name / Version; SBOM Generation Context; SBOM Tool Name / Version; SBOM Version; Component Hash Value / Algorithm; Component License
Major Updates	SBOM Author; Component Identifiers; Component Producer (was Supplier Name); Component Version; Accommodation of Updates; Coverage (was Depth); Explicitly Identifying Unknown Information (was Known Unknowns); Machine-Processable Data (was Automation Support)
Minor Updates	SBOM Timestamp; Component Name; Component Dependency Relationship; Distribution and Delivery; Frequency
Removed	Access Control (merged into Distribution and Delivery)

 

CycloneDX vs. SPDX: How the Two Formats Compare

Both CycloneDX and SPDX can satisfy the 2026 data fields, though the gaps fall in different places. CycloneDX is stronger on document signature and document version, because it carries both natively inside the document. SPDX is stronger on structured “unknown” handling, with NOASSERTION and NONE sentinels that let a consumer tell missing data apart from data the author deliberately withheld. For lifecycle context, SPDX 3.0’s sbomType and CycloneDX’s lifecycles both work, while SPDX 2.3 has no first-class field for it.

The choice of CycloneDX vs. SPDX does not lock you in. CISA’s Machine-Processable Data practice expects organizations to accept both, so the practical goal is emitting the right fields in whichever format you ship and knowing the handful of elements that need an external step. The field maps below give the exact property for each 2026 element in CycloneDX 1.6, SPDX 2.3, and SPDX 3.0.

Field Map: SBOM Metadata

CISA’s metadata elements describe the SBOM document, not the software under inventory. Map carefully, because SBOM Author is not Component Producer, and SBOM Tool is not SBOM Author.

 

CISA 2026 Element	CycloneDX 1.6	SPDX 2.3	SPDX 3.0	Notes
SBOM Author	metadata.authors[].name (and/or metadata.manufacturer when generation is automated)	creationInfo.creators[] entries with Person: / Organization: prefixes	CreationInfo.createdBy → Person / Organization	Exclude Tool: creators — those are the tool, not the author. Use full legal/org names; avoid unexplained acronyms.
SBOM Author Signature (new)	Root signature (JSF: algorithm, value, optional public key)	No normative in-document signature	No normative Signature class ; verifiedUsing is integrity hashing, not author authentication	Prefer CycloneDX native signature, or sign the SPDX artifact externally (JWS/CMS/Sigstore) and treat that as the author signature.
SBOM Data Format Name (new)	bomFormat (“CycloneDX”)	Implied (“SPDX”); no dedicated field	Implied (“SPDX”); profile set via profileConformance	Only CycloneDX encodes the format name inside the document.
SBOM Data Format Version (new)	specVersion (e.g. “1.6”)	spdxVersion (e.g. “SPDX-2.3”)	CreationInfo.specVersion (e.g. “3.0.1”)	Avoid deprecated format versions for new software.
SBOM Generation Context (new)	metadata.lifecycles [].phase (design, pre-build, build, post-build, operations, discovery, …) or custom name	No document-level SDLC field; approximate via CreatorComment / DocumentComment or package sourceInfo	software_Sbom.sbomType (design, source, build, deployed, runtime, analyzed)	CISA examples: “before build,” “build,” “after build.” SPDX 3.0 sbomType is the best SPDX match.
SBOM Timestamp	metadata.timestamp	creationInfo.created	CreationInfo.created	CISA: date/time of the most recent update; prefer RFC 9557-compatible timestamps.
SBOM Tool Name (new)	metadata.tools.components [].name (or legacy metadata.tools[].name)	creationInfo.creators[] entries with Tool: prefix	CreationInfo.createdUsing → Tool.name	Full tool names; no unexplained acronyms.
SBOM Tool Version (new)	metadata.tools.components [].version	Conventionally embedded in the Tool: name-version creator string	No dedicated Tool version property — put version in name, externalIdentifier, or an extension	If unknown, say so explicitly (see practices below).
SBOM Version (new)	Integer version + identity via serialNumber (urn:uuid:…)	No document version field; new revision → new documentNamespace, optionally linked with AMENDS	Same pattern: new document identity; relate prior with amendedBy	CISA allows SemVer for the SBOM itself (major 1 when following these elements) or UUID-style identifiers.

 

Lifecycle Quick Map

CISA Phrasing	CycloneDX lifecycles.phase	SPDX 3.0 sbomType
Before build	design, pre-build	design, source
Build	build	build
After build	post-build, operations, discovery	analyzed, deployed, runtime

 

Field Map: Component Data

These elements apply to the target component and every enumerated subcomponent.

CISA 2026 Element	CycloneDX 1.6	SPDX 2.3	SPDX 3.0	Notes
Component Producer (was Supplier Name)	Prefer manufacturer.name; also supplier, authors, publisher where appropriate	Prefer PackageOriginator; PackageSupplier is the distributor, not necessarily the producer	Prefer originatedBy; suppliedBy is distinct	One producer per component. For open source, use the packaging ecosystem convention, else the original project or maintaining org. If provenance is unknown, say so explicitly.
Component Name	name (alternates via group, SWID, properties)	PackageName / packages[].name	Element.name on software_Package	Producer-assigned human-readable name; formats should allow alternate names where possible.
Component Version	version	PackageVersion / versionInfo	packageVersion	If the producer provides no version, mark unknown. Do not invent one.
Component Identifiers	purl, cpe, omniborId, swhid, swid, bom-ref, plus externalReferences	externalRefs[] (purl, cpe23Type, cpe22Type, …)	externalIdentifier[] (packageUrl, cpe23, cpe22, gitoid, swhid, …); also packageUrl / content identifiers	Include at least one common software identifier; include all known identifiers when multiple exist.
Component Hash Value (new)	hashes[].content	PackageChecksum / checksums[].checksumValue	verifiedUsing → Hash.hashValue	Hex/ASCII digest of the executable artifact. If you lack the artifact, mark unknown. Do not fake a hash.
Component Hash Algorithm (new)	hashes[].alg (SHA-256, SHA-512, …)	checksums[].algorithm (SHA256, …)	Hash.algorithm (sha256, …)	Prefer IANA Hash Function Textual Names or authority-approved algorithms (for example, NIST). Normalize spelling across formats.
Component License (new)	licenses (SPDX expression or license object)	licenseConcluded / licenseDeclared	Relationships hasConcludedLicense / hasDeclaredLicense	Prefer SPDX License List IDs, otherwise a URL or other locator for the full text. Call out proprietary terms. If unknown, say so.
Component Dependency Relationship	dependencies[] (ref / dependsOn); optional pedigree; completeness via compositions	relationships[] (DEPENDS_ON, CONTAINS, …)	Relationship (dependsOn, contains, …) + optional completeness	Either embed dependencies in one SBOM or link to dependency SBOMs. Both satisfy Coverage if recipients can reach the linked documents.

 

Practices and Processes (Not Always a Single Field)

CISA separates data fields from how you operate. Several 2026 practices map to format features, but contracts and generation policy still matter.

Practice	How Formats Help	What You Still Need to Do
Coverage	CDX: dependencies, compositions, BOM-Link externalReferences (type: bom). SPDX 2.3: externalDocumentRefs + cross-doc relationships. SPDX 3.0: import / ExternalMap, contains / dependsOn.	Inventory all components, including transitive deps; no minimum depth; list differing instances separately; exclude non-code files only deliberately.
Explicitly Identifying Unknown Information	SPDX 2.3: NOASSERTION / NONE. SPDX 3.0: NoAssertionElement / NoAssertionLicense, relationship completeness. CDX: compositions.aggregate (incomplete, unknown, …), annotations/properties — no global NOASSERTION.	Distinguish unknown to the author from known but withheld. Provide a channel for recipients to ask about redacted security-relevant data.
Machine-Processable Data	Native in both formats	Accept SPDX and CycloneDX; refuse deprecated format versions for new software.
Frequency	New document / new version / new namespace per release	New build or release means a new SBOM; corrections mean a revised SBOM with an updated timestamp and version.
Accommodation of Updates	CDX version increments; SPDX AMENDS / amendedBy	Correct errors promptly; treat chronic bad data as a supplier-risk signal.
Distribution and Delivery	URLs, APIs, repos, attach-to-install	Deliver promptly to authorized parties; access controls must not block legitimate security tooling.

 

Gaps Worth Planning For

1. Signatures: CycloneDX carries an author signature in-document. SPDX 2.3/3.0 typically need an external signing envelope. If your procurement language says “SBOM Author Signature,” specify whether in-document JSF, detached signature, or Sigstore-style attestation is acceptable.
2. SBOM document version: This is first-class in CycloneDX (version + serialNumber). In SPDX, treat a new document identity (namespace / SPDX ID) plus an amend relationship as the equivalent.
3. Unknown vs. omitted: SPDX consumers can rely on NOASSERTION. CycloneDX consumers must agree on conventions (compositions, annotations, or properties) so omission isn’t mistaken for “not applicable.”
4. Generation context on SPDX 2.3: Prefer SPDX 3.0 sbomType or CycloneDX lifecycles when lifecycle phase is a hard requirement. Otherwise, document it in a comment or property your consumers understand.
5. Tool version on SPDX 3.0: If tool has name but no dedicated version property, encode the version explicitly so it remains machine-readable.

None of these gaps mean you should pick one format. CISA’s Machine-Processable Data practice expects organizations to accept both. Interoperability and conversion (with fidelity notes) remain valuable.

How RunSafe Helps Customers Meet the 2026 Elements

RunSafe Identify’s SBOM generation (the runsafe-sbom build-time collector for C/C++, plus Yocto and Platform pipeline paths) emits CycloneDX 1.6 JSON, one of the two formats CISA calls out for machine-processable data. The design goal is build-observed fidelity. RunSafe wraps the real compiler and linker (or BitBake recipes), then enriches and serializes the result.

Customer-facing setup and override knobs are documented in Compiled SBOMs and Yocto SBOMs. Below is how that capability lines up with the 2026 minimum elements.

What RunSafe Generates Automatically

 

CISA Element	RunSafe Behavior
SBOM Data Format Name / Version	Always bomFormat: “CycloneDX” and specVersion: “1.6”.
SBOM Timestamp	metadata.timestamp set to UTC at generate time.
SBOM Tool Name / Version	metadata.tools.components[] records the RunSafe generator (C/C++ SBOM Generator plus crate/package version), with RunSafe as tool supplier/manufacturer.
SBOM Version	CycloneDX document version (default 1) plus a fresh serialNumber (urn:uuid:…) per generation.
Component Name / Version	Observed from the build graph and package enrichment (dpkg, rpm, vcpkg, git submodules, SDK packages, headers, filename heuristics).
Component Producer	Mapped primarily to CycloneDX supplier when enrichment or headers provide it (plus Yocto SPDX_SUPPLIER).
Component Identifiers	Package cpe generated from identity; purl for supported ecosystems (RPM, Deb, GitHub, generic); every component gets a bom-ref.
Component Hash Value / Algorithm	SHA-256 (hashes[].alg / hashes[].content) for observed file artifacts at collection time.
Component License	From source headers, vcpkg SPDX metadata, Yocto LICENSE, and config overrides — emitted as CycloneDX license objects/expressions.
Component Dependency Relationship	dependencies[] built from the observed build/process graph and package containment.
Coverage (practice)	Build-time interception inventories what the toolchain actually touches, including nested libraries and source; package post-processing groups files under packages.

 

That combination covers the bulk of the component data bar and several metadata fields without requiring customers to hand-author an SBOM.

What Customers Can Specify

RunSafe auto-detects components, but customers can also enrich SBOMs to include proprietary components or other known data via a declared configuration file (see Compiled SBOMs: Configuration File).

The same config file is used across builds and, once created, is applied to future SBOM generation. This gives organizations more control and the ability to integrate SBOMs into the existing build pipeline.

A Practical Path for 2026-Ready RunSafe SBOMs

1. Wrap the real build (or enable Yocto/meta-runsafe-sbom / Platform pipeline generation) so Coverage and dependency relationships reflect shipped software.
2. Set product metadata (metadata_component_* / env) so the target component’s Name, Version, and Producer are unambiguous.
3. Override hard cases in config.toml (or Yocto recipe vars) where auto-detection misses license, supplier, or CPE-critical naming.
4. Bump RUNSAFE_SBOM_VERSION_ID when you correct an SBOM for the same product version (Accommodation of Updates + SBOM Version).
5. Add author + signature in your release pipeline if those elements are contractual — RunSafe already supplies format, tool, timestamp, lifecycle, hashes, identifiers, licenses (when known), and the dependency graph.

For those developing embedded software written in C and C++, where dependencies are compiled into the binary instead of declared in a package manifest, generating accurate SBOMs is quite difficult. Scanners that read package files miss what actually ships. 

RunSafe Identify generates the SBOM by observing the real build, wrapping the compiler and linker (or Yocto and BitBake recipes), so the inventory reflects the components in the shipped binary. Building an accurate inventory is the most demanding part of meeting the 2026 elements, and it is hardest for this kind of software. Generating an SBOM directly from the build removes the heaviest lift.

Checklist: Generating a 2026-Ready SBOM

Document

• ☐ Author entity named (not just the tool)
• ☐ Author signature present (in-document or agreed external)
• ☐ Format name + format version present and unambiguous
• ☐ Generation context (lifecycle phase) recorded
• ☐ Timestamp of last update
• ☐ Tool name + tool version
• ☐ SBOM version / revision identity

Each Component

• ☐ Producer, name, version (or explicit unknown)
• ☐ ≥1 common identifier (PURL and/or CPE strongly preferred); all known IDs included
• ☐ Hash value + algorithm when the executable artifact is available
• ☐ License ID(s) or locator; proprietary terms noted; unknown if unknown
• ☐ Dependency relationships (embedded or linked)

Process

• ☐ Transitive coverage; linked SBOMs reachable by the recipient
• ☐ Unknowns and redacted fields labeled distinctly
• ☐ New SBOM per release; corrections issued promptly
• ☐ Delivered in SPDX and/or CycloneDX (non-deprecated versions)

Putting the 2026 SBOM Minimum Elements into Practice

The 2026 minimum elements build on the 2021 baseline, adding additional metadata for trust and triage, sharpening producer and identity semantics, promoting licenses and hashes to first-class, and setting coverage expectations that match modern tooling.

CycloneDX 1.6 and SPDX (2.3 and 3.0) already have homes for nearly every data field. For most organizations the work is emitting the right fields consistently, signing and versioning documents, and treating unknowns as data rather than silence.

RunSafe Identify emits CycloneDX 1.6 SBOMs at build time, covering the format, tool, timestamp, hashes, identifiers, licenses, and dependency graph the 2026 elements call for. 

Talk to our team to run it against your own embedded software and see the output against the checklist above.