The NTIA published its "Minimum Elements for a Software Bill of Materials (SBOM)" on July 12, 2021, seven weeks after Executive Order 14028 directed federal agencies to start requiring SBOMs from software vendors. The document defines three mandatory categories: seven Data Fields (Supplier Name, Component Name, Version String, Other Unique Identifiers, Dependency Relationship, Author of SBOM Data, and Timestamp), Automation Support in a machine-readable format such as SPDX, CycloneDX, or SWID, and Practices and Processes covering generation frequency, depth, known unknowns, and distribution. Meeting these elements is now a contractual requirement for federal software vendors under OMB Memo M-22-18 (September 2022), and a statutory one for medical device makers under Section 524B of the FD&C Act, enforced since March 29, 2023. Most teams that run a single sbom generate command satisfy the format requirement and fail the other two. This post breaks down what each element actually requires and where compliance efforts typically fall short.
What are the NTIA's minimum elements for an SBOM?
The minimum elements are three categories — seven required data fields, a machine-readable automation format, and a set of practices and processes governing how the SBOM is produced and shared — and all three have to be satisfied, not just the data fields. The seven fields are: Supplier Name (the entity that created, defined, or identified the component), Component Name, Version String, Other Unique Identifiers (a purl, CPE, or hash), Dependency Relationship (which components include or depend on which), Author of SBOM Data (who generated this specific document, as distinct from the software supplier), and Timestamp of creation. The Practices and Processes category is the one teams skip most often: it requires documenting generation frequency (per build, per release, or ad hoc), depth (do you resolve transitive dependencies or stop at direct ones), how "known unknowns" are handled when a field can't be populated, and how the SBOM is distributed and access-controlled once it exists. A document with all seven fields filled in for a shallow, one-time snapshot still fails the spirit of the standard because the process behind it isn't repeatable.
Which file formats satisfy the automation support requirement?
Three formats satisfy it: SPDX, CycloneDX, and SWID tags (ISO/IEC 19770-2:2015) — NTIA never mandated one over the others. SPDX 2.3 became an ISO/IEC standard (5962:2021) and SPDX 3.0 shipped in April 2024 with better support for AI and data-provenance fields. CycloneDX, maintained by OWASP, released version 1.6 in April 2024 and has become the de facto choice for teams that also need VEX (Vulnerability Exploitability eXchange) statements, since CycloneDX defines VEX natively while SPDX relies on a separate profile. SWID tags predate both and are mostly seen in enterprise software inventory tools rather than CI/CD-generated SBOMs. In practice, if you're a software vendor selling to the federal government, CycloneDX or SPDX in JSON form is what contracting officers expect to receive and what CISA's tooling is built to ingest.
Who is legally required to produce NTIA-conformant SBOMs today?
Three groups currently have binding requirements: federal software vendors under OMB M-22-18, medical device manufacturers under FDA's Section 524B, and — starting with a phased rollout beginning in 2026 and full enforcement in 2027 — companies selling connected products into the EU under the Cyber Resilience Act. OMB M-22-18 requires vendors to self-attest, via CISA's standard attestation form, that their software was developed following NIST SP 800-218 secure development practices, and agencies can request the underlying SBOM as evidence. FDA has rejected premarket submissions for cyber devices that lack an SBOM since March 2023, citing Section 524B directly. The CRA doesn't use NTIA's exact language but requires "an SBOM covering at least the top-level dependencies," which overlaps heavily with the minimum elements' data-field list. DoD has also proposed folding SBOM delivery into DFARS clauses for software-intensive contracts, though that rule hasn't been finalized as of mid-2026.
Does meeting the seven data fields guarantee a usable SBOM?
No — the minimum elements set a floor for what's recorded in the document, not how completely the dependency tree is captured. A typical React application might declare 40 direct dependencies in package.json while node_modules resolves to 1,200 or more packages once transitive dependencies are pulled in; an SBOM that only lists the 40 direct entries technically has all seven fields populated for each component but misses 95%+ of what's actually shipping in the artifact. NTIA anticipated this gap with the "known unknowns" practice: rather than requiring perfect depth, it requires you to disclose where depth is missing — for example, a statically linked closed-source library where you can't enumerate its own dependencies. An SBOM that says "we could not determine the transitive dependencies of libfoo.so" is more conformant than one that silently omits them, because the practices-and-processes category is being honestly documented either way.
How do you check whether an existing SBOM actually conforms?
Run it through a conformance checker that verifies each of the seven fields is populated for every component, not just present in the schema. CISA maintains an open source tool, ntia-conformance-checker, specifically for this; sbomqs from Interlynk scores SBOMs on a 0-10 scale across NTIA compliance and general quality; and both cyclonedx-cli and the SPDX tools support schema and field validation. The most common failure pattern in generated SBOMs is a Supplier Name field filled with "NOASSERTION" or "UNKNOWN" for a large share of components — it's common to see this on 25-40% of entries in an SBOM produced straight from a package manager, because npm, PyPI, and Maven metadata don't reliably carry a legal supplier name distinct from the package author. Timestamp and Author-of-SBOM-Data fields are the next most frequently missing, usually because the generating tool wasn't configured to stamp them at all.
What should you do when a component's supplier can't be identified?
Document it explicitly as a known unknown rather than leaving the field blank — that's the exact mechanism NTIA built into the standard for this case. A blank or "NOASSERTION" field with no accompanying explanation reads as incomplete data; a field marked "supplier unidentifiable — component sourced from unsigned public registry, no publisher metadata available" reads as a disclosed limitation, which is what conformance actually asks for. This matters most for anything pulled from public registries without cryptographic attestation: PyPI and npm packages published before Sigstore-based provenance became common (npm's provenance attestations launched in April 2023) frequently have no verifiable supplier at all. Teams that build this disclosure step into their SBOM pipeline once, rather than chasing it down per audit, tend to pass federal and FDA reviews on the first pass instead of the second.
How Safeguard Helps
Safeguard generates SPDX and CycloneDX SBOMs directly from your build pipeline and can ingest SBOMs you already produce elsewhere, then runs conformance checks against all seven NTIA data fields and flags gaps — including NOASSERTION suppliers and missing timestamps — before an auditor does. Griffin AI, Safeguard's reachability engine, goes past the minimum elements to tell you which of the components in your SBOM are actually reachable from your application's call paths, so a "known unknown" transitive dependency with a critical CVE gets prioritized differently from one that's never invoked at runtime. When a vulnerable or misidentified component is confirmed reachable, Safeguard opens an auto-fix pull request with the minimum version bump needed to resolve it, keeping the SBOM's dependency-relationship data accurate on every merge instead of stale between quarterly regenerations. That combination — automated generation, field-level conformance checking, and reachability-scoped remediation — is what turns an NTIA-conformant SBOM from a one-time compliance artifact into something your security team actually uses.