SBOM Requirements in 2026: A Practical Map
Published August 14, 2026 · 9 min read
SBOM requirements in 2026 come from three directions at once — US federal procurement rules, EU product regulation, and industry-specific guidance — and they do not all say the same thing. Here is what actually applies to whom, what the data has to contain, and how to tell if your product is in scope.
Who is actually required to produce an SBOM
US federal software vendors.Executive Order 14028, “Improving the Nation's Cybersecurity” (May 2021), directs federal agencies to require SBOMs from vendors of software sold to the government, with a particular focus on “critical software” — operating systems, identity management tools, browsers, and security software. If your product is procured by a US federal agency, an SBOM is very likely already a contractual requirement.
Medical device manufacturers.The FDA's cybersecurity guidance, effective October 2023, requires SBOMs as part of premarket submissions for devices that contain software or connect to networks — a category that covers most modern medical devices.
Products sold in the EU. The EU Cyber Resilience Act extends the obligation furthest: Article 13 requires manufacturers of products with digital elements to document their components, including via an SBOM, with enforcement phasing in through 2027. As with any cross-border regulation, whether and how it applies to a specific product is a question for counsel, not a blog post.
Everyone else.Outside these direct mandates, SBOMs are increasingly requested as a procurement condition by enterprise customers and during M&A due diligence, even when no law requires one. A vendor that cannot produce an SBOM on request is at a competitive disadvantage against one that can.
What the requirements actually specify
Most of these rules describe required data, not a required file format. The NTIA Minimum Elements — the baseline reference most US guidance points back to — define seven fields every SBOM should carry:
| Field | What it captures |
|---|---|
| Supplier name | Who publishes the component |
| Component name | The package as named by its supplier |
| Version | The exact version identifier |
| Other unique identifiers | e.g. a Package URL (PURL) |
| Dependency relationship | Which components depend on which |
| Author of SBOM data | Which tool or team generated the SBOM |
| Timestamp | When the SBOM was assembled |
Both major SBOM formats can express all seven fields, which is why the requirements above rarely mandate one format over the other — our guide to reading CycloneDX and SPDX walks through both with annotated examples. Check your specific contract or agency guidance for a format preference before choosing.
Where enforcement stands in 2026
Federal procurement enforcement has matured furthest: agencies increasingly ask for an SBOM as a standard part of the vendor onboarding process rather than a special request. FDA premarket review has treated SBOM submission as a routine expectation since the guidance took effect. The EU CRA is the newest and furthest from full enforcement — its vulnerability-handling and reporting obligations phase in over a multi-year window, so a product not yet enforced against today may be in scope well before it reaches end of life. Treat CRA timelines as a planning horizon, not a reason to wait.
Common mistakes teams make
Treating the SBOM as a one-time deliverable.A vendor that generates a single SBOM at initial certification and never updates it is not meeting the spirit of any of these requirements — the whole point is knowing what is in a product as it changes over its supported life, not what it contained on one specific date.
Assuming a tool's output is automatically compliant.Running a generator and getting a CycloneDX or SPDX file does not guarantee the NTIA minimum elements are all populated correctly — some generators leave supplier or dependency-relationship fields blank by default. Check the actual output, not just that the command exited successfully.
Conflating an SBOM with a security certification. An SBOM inventories components; it does not certify that a product is secure or free of vulnerabilities. Presenting an SBOM as proof of security to a customer or regulator overstates what the document actually claims.
Waiting for full enforcement before starting. Given how long it takes to wire SBOM generation into an existing build pipeline properly, teams that start only when a deadline is imminent tend to ship incomplete or inconsistent SBOMs under time pressure.
A practical checklist
- Identify which of your products touch US federal procurement, medical devices, or the EU market — that determines which specific rule applies.
- Generate an SBOM with every build, not on a periodic schedule; a stale SBOM that does not reflect what actually shipped is worse than none.
- Confirm the SBOM contains all seven NTIA minimum element fields, regardless of which format you choose.
- Store SBOMs alongside build artifacts and make them retrievable on request — a procurement team asking for one during a deal should not trigger a scramble.
- Pair the SBOM with vulnerability enrichment; an inventory without a risk assessment answers “what do we ship” but not “are we exposed.”
- Consult counsel before making compliance claims to customers or regulators — this article describes the general landscape, not legal advice for your specific product and market.
How ScanRook fits into an SBOM program
ScanRook generates CycloneDX and SPDX SBOMs directly from a container image, binary, or source archive, and enriches every component with vulnerability data from OSV, NVD, and Red Hat OVAL in the same pass — so the inventory and the risk assessment ship together instead of as separate steps. Our complete SBOM guide covers the generation and enrichment pipeline in detail, including SBOM diff for tracking what changed between releases.
Frequently asked questions
Is an SBOM legally required in 2026?
Depends on the market: yes for US federal software and FDA-regulated medical devices, phasing in for the EU CRA, and increasingly a procurement expectation everywhere else.
What must an SBOM contain?
The NTIA Minimum Elements: supplier, component name, version, unique identifiers, dependency relationships, SBOM author, and timestamp.
Do I need both CycloneDX and SPDX?
No single format is universally mandated; both can express the required data. Check your specific contract for a format preference.
Does an SBOM mean my software has no vulnerabilities?
No — it is an inventory. A vulnerability scanner checks that inventory against advisory databases to assess actual risk.
Generate a compliant SBOM in one scan
ScanRook produces CycloneDX and SPDX SBOMs with the NTIA minimum elements, enriched with vulnerability data, from a single container image or source archive scan.