A few years ago, the software bill of materials was a best practice you adopted voluntarily. In 2026, it is a compliance artifact you are asked to produce across an expanding range of regulations, sectors, and geographies. This guide is a practical map: what an SBOM is, the formats and data that count, and — framework by framework — where you now need one and why.
What an SBOM is and what makes it compliant
A software bill of materials is a formal, machine-readable inventory of the components that make up a piece of software, including their versions, suppliers, unique identifiers, and dependency relationships. Think of it as an ingredients label for software.
For an SBOM to be useful for compliance, it generally needs to satisfy three things. First, format: the two dominant machine-readable standards are SPDX (an ISO/IEC standard) and CycloneDX (an OWASP project); either is broadly accepted where a machine-readable SBOM is expected. Second, minimum data elements: NTIA's baseline calls for supplier, component name, version, unique identifiers, dependency relationships, author, and timestamp. Third, currency: an SBOM generated once and left to age is nearly worthless — it must reflect what actually ships in each release, which means generating it automatically in the build.
A common misconception is that an SBOM by itself demonstrates security. It does not. It is a foundation; the value comes from continuously matching it against known vulnerabilities and maintaining provenance for the components it lists.
Where SBOMs are required or expected in 2026
The requirement has propagated well beyond its origin. Here is the landscape:
| Framework / regime | SBOM status | Who it reaches |
|---|---|---|
| US Executive Order 14028 & OMB guidance | Expected; may be requested by agencies | Software producers selling to the US federal government |
| EU Cyber Resilience Act (2024/2847) | Required (at least top-level components) | Manufacturers of products with digital elements sold in the EU |
| US FDA premarket guidance | Required for cyber devices | Medical device manufacturers seeking US market clearance |
| PCI DSS 4.0 (Req 6.3.2) | Effectively required via component inventory | Merchants and service providers handling card data |
| NIST SSDF (SP 800-218) | Implicit under component management (PW.4) | Anyone attesting to SSDF-aligned development |
| Enterprise procurement contracts | Increasingly contractually required | Vendors selling to large or regulated buyers |
The pattern is clear: whether the word "SBOM" appears explicitly (as in the CRA and FDA guidance) or is implied through a component-inventory requirement (as in PCI DSS 4.0 and the SSDF), the underlying obligation is the same. You must know, and be able to show, what is in your software.
The framework-by-framework nuance
- EU CRA. Requires an SBOM covering at least top-level dependencies, in a commonly used machine-readable format, available to authorities on request. Paired with binding vulnerability handling and reporting obligations.
- FDA medical devices. For "cyber devices," premarket submissions are expected to include an SBOM covering commercial, open source, and off-the-shelf components, along with vulnerability management plans.
- PCI DSS 4.0. Requirement 6.3.2 mandates an inventory of bespoke and custom software and the third-party components it uses — an SBOM by another name — to drive vulnerability management.
- US federal. Following EO 14028, agencies may request SBOMs from software producers, and secure-development attestation references SSDF practices that include component management.
A universal SBOM compliance checklist
Regardless of which framework applies, the same operational checklist gets you most of the way:
- Generate an SBOM automatically on every build (not manually, not once)
- Use a standard format: SPDX or CycloneDX
- Include the NTIA minimum data elements and dependency relationships
- Cover open source, commercial, and off-the-shelf components
- Continuously match the SBOM against known vulnerabilities
- Maintain provenance linking the SBOM to its build and artifact
- Be able to produce a current SBOM on request, per release
- Retain historical SBOMs to answer "what was in the version we shipped then?"
Why "generate on demand" beats "have one on file"
The single most important shift is treating the SBOM as a live output of your pipeline rather than a document in a folder. Regulators and buyers increasingly ask not just "do you have an SBOM?" but "what was in the specific version affected by this vulnerability, and when did you know?" Answering that requires historical, per-release SBOMs tied to build provenance — something you can only produce if generation is automated and versioned from the start.
How Safeguard helps
Safeguard is built to make the universal checklist automatic. SBOM Studio generates SPDX or CycloneDX SBOMs with the NTIA minimum elements on every build, covering open source, commercial, and off-the-shelf components, and versions them per release so you can always answer "what was in the version we shipped then." Software composition analysis does the part a static file cannot — continuously matching each SBOM against new vulnerability disclosures so the inventory drives action, not just documentation.
Because the Safeguard CLI runs in your pipeline, each SBOM is tied to a specific build and artifact, giving you the provenance trail that separates a credible SBOM program from a checkbox one. Griffin AI prioritises the resulting findings by real exploitability so remediation stays focused. And our compliance pages map SBOM capabilities to the CRA, PCI DSS, FDA, SSDF, and federal expectations, so whichever regime asks, you can point to the evidence.
The SBOM has become the common denominator of software supply chain compliance across every major framework. Automate it once, and you are ready for all of them.
Make the SBOM a byproduct of your build, not a project. Sign up free or read the Safeguard documentation to generate your first one.