SBOM requirements in 2026: what regulators and buyers actually expect

SBOM requirements used to be a U.S. federal procurement concern. In 2026 they show up in FDA submissions, EU product regulation, defense contracts, and—most often for SaaS companies—enterprise vendor security reviews. Teams that treat SBOMs as a one-off document scramble every time a new request lands; teams that generate them per release answer in minutes.

This guide covers:

The NTIA minimum elements every SBOM is typically measured against
Which regulations and frameworks reference SBOMs today
What enterprise buyers actually ask for in questionnaires
A practical path to meeting SBOM requirements without new headcount
Mistakes that make SBOM programs fail quietly

Reading the fine print

GIF via GIPHY

Related guides:

Key takeaways

The NTIA minimum elements (supplier, component name, version, unique IDs, dependency relationships, author, timestamp) are the de facto baseline for "a real SBOM."
EO 14028, FDA premarket guidance, and the EU Cyber Resilience Act all reference SBOMs—each with different scope and depth expectations.
Enterprise buyers commonly request SBOMs per major release, delivered in SPDX or CycloneDX.
Meeting requirements is mostly an automation problem: generate in CI, store with release artifacts, and define a sharing process.
SecureSlate turns SBOM practices into reusable evidence for audits and security questionnaires.

The NTIA minimum elements

The NTIA's 2021 "Minimum Elements for a Software Bill of Materials" remains the reference point most requesters use. It defines three categories:

Category	Elements	What "good" looks like
Data fields	Supplier, component name, version, unique identifiers, dependency relationships, SBOM author, timestamp	Every component resolvable to a CVE-matchable identifier (PURL/CPE)
Automation support	Machine-readable format	SPDX or CycloneDX in JSON—not a PDF or spreadsheet
Practices and processes	Frequency, depth, known unknowns, distribution, access control	New SBOM per release; transitive dependencies included; gaps declared

The "known unknowns" element matters more than teams expect: an SBOM that explicitly states where its visibility ends is typically treated as more credible than one that silently omits sections of the dependency tree.

Regulations that reference SBOMs

Regulation / program	Who it affects	SBOM expectation
EO 14028 / OMB M-22-18	Vendors selling software to U.S. federal agencies	SBOM on request, plus secure development attestation (CISA form)
FDA Section 524B	Medical device manufacturers ("cyber devices")	SBOM covering commercial, open source, and off-the-shelf components in premarket submissions
EU Cyber Resilience Act	Products with digital elements sold in the EU	Machine-readable SBOM of at least top-level dependencies, available to market surveillance authorities
DoD / defense supply chain	Defense contractors and subcontractors	SBOM clauses increasingly appearing in contracts alongside CMMC obligations
PCI DSS 4.0 (6.3.2)	Organizations handling cardholder data	An inventory of bespoke and custom software components—an SBOM satisfies this cleanly

If you sell into several of these markets, resist the urge to build separate processes. One automated SBOM pipeline typically satisfies all of them with format and depth adjustments.

What enterprise buyers ask for

In vendor security reviews, SBOM requests commonly look like:

"Provide an SBOM for the product in scope" — expect SPDX or CycloneDX JSON
"Describe your process for maintaining component inventories" — they want cadence and ownership, not a one-time export
"How do you identify and remediate vulnerable components?" — SBOM plus vulnerability correlation and SLAs
"Do you provide VEX documents?" — increasingly common; see our VEX guide

Buyers rarely read every line of your SBOM. They check that it exists, that it is fresh, that it is machine-readable, and that your answers about process are consistent with it.

How to meet SBOM requirements

Inventory your products and decide which artifacts need SBOMs (customer-facing services, distributed binaries, container images).
Generate in CI per release using tools that emit SPDX and CycloneDX.
Include transitive dependencies—top-level-only SBOMs fail most buyer reviews.
Store SBOMs versioned alongside release artifacts with retention matching your contract obligations.
Define a sharing workflow: who approves external SBOM requests, under what terms (NDA, portal, trust center).
Document the process in your secure SDLC policy so auditors can test it—see our secure SDLC policy guide.

Common mistakes

One-time SBOMs generated for a single deal, stale within a sprint
PDF or spreadsheet SBOMs that fail the machine-readability expectation
Top-level dependencies only, hiding the transitive tree where most vulnerabilities live
No named owner for inbound SBOM requests, so responses take weeks
SBOMs disconnected from vulnerability management—an inventory nobody queries during incidents

SBOM requirements with SecureSlate

SecureSlate maps your SBOM and secure development practices to SOC 2, ISO 27001, PCI DSS, and customer questionnaires—so one pipeline satisfies auditors, regulators, and enterprise buyers from a single source of truth.

Get started for free · Free readiness score

FAQ: SBOM requirements

Is there one universal SBOM requirement?

No. The NTIA minimum elements are the common baseline, but each regulator and buyer adds scope details—depth of dependencies, format, delivery mechanism, and update cadence vary.

Do SaaS companies need SBOMs if they don't ship binaries?

Increasingly yes. Enterprise buyers request SBOMs for hosted services during due diligence, and U.S. federal customers may require them regardless of delivery model.

What format should we deliver?

SPDX or CycloneDX in JSON. Generate both if your tooling allows—it avoids re-work when different customers ask for different formats.

How deep must the dependency tree go?

The NTIA baseline expects at least top-level with known unknowns declared, but mature programs include full transitive dependencies because that is where most exploitable components sit.

Are SBOM attestations the same as SBOMs?

No. Attestations (like the CISA secure software development attestation) are statements about your practices; the SBOM is the component inventory itself. Federal buyers may ask for both.

Disclaimer (legal note)

SecureSlate is not a law firm, and this article does not constitute legal advice or create an attorney-client relationship. Security and compliance obligations vary by industry, contract, and jurisdiction—consult qualified counsel as needed.