# The NTIA Minimum Elements, Explained: The SBOM Checklist FDA References > When a buyer, a regulator, or a vendor says an SBOM needs to be "compliant," the checklist they almost always mean is the NTIA minimum elements: seven fields, published July 12, 2021, that turn a file from an inventory into something a buyer can actually use. FDA's cybersecurity guidance recommends SBOMs consistent with them, and the EU Cyber Resilience Act's documentation requirements rhyme with them. Here is each element, what it is for in practice, the failure modes buyers see most, and the two fields FDA adds on top. And to untangle the search confusion up front: the minimum elements are NTIA's, not CISA's: CISA publishes the guidance on SBOM types and levels; NTIA defined the field list. - **Published**: 2026-10-26 - **URL**: https://vendorquals.com/blog/sbom-minimum-elements --- # The NTIA Minimum Elements, Explained: The SBOM Checklist FDA References *When a buyer, a regulator, or a vendor says an SBOM needs to be "compliant," the checklist they almost always mean is the NTIA minimum elements: seven fields, published July 12, 2021, that turn a file from an inventory into something a buyer can actually use. FDA's cybersecurity guidance recommends SBOMs consistent with them, and the EU Cyber Resilience Act's documentation requirements rhyme with them. Here is each element, what it is for in practice, the failure modes buyers see most, and the two fields FDA adds on top. And to untangle the search confusion up front: the minimum elements are NTIA's, not CISA's: CISA publishes the guidance on SBOM types and levels; NTIA defined the field list.* ## Key takeaways - **Seven fields, one page: supplier name, component name, version, other unique identifiers, dependency relationship, SBOM author, and timestamp.** Published by the National Telecommunications and Information Administration on July 12, 2021, under Executive Order 14028. - **The unique identifier is the load-bearing element.** A purl or CPE per component is what makes a vulnerability match possible; without it, the SBOM is a list of names nobody can check against anything. - **FDA references this list and adds two fields per component:** the software level of support and the end-of-support date. Those two answer what the seven cannot: is the component alive? - **The CISA/NTIA confusion is real and worth resolving:** CISA's SBOM guidance covers the three levels at which an SBOM can be generated (source, build, analyzed); NTIA's document defines what fields the result must carry. "A CISA-compliant SBOM" as a search phrase almost always means NTIA's minimum elements. - **The check is free and instant.** [The Vendor SBOM Checker ->](/tools/sbom-checker) validates all seven per file, in your browser, nothing stored. ## Where the list came from Executive Order 14028, "Improving the Nation's Cybersecurity" (May 12, 2021), directed a sweeping federal look at software supply chain security. One of its work products was NTIA's minimum elements document: the interagency and industry agreement on the least an SBOM must contain to be usable. It recognized three machine-readable formats from day one: SPDX, CycloneDX, and SWID tags. The document is deliberately a floor, not a ceiling. Its point is that an SBOM missing any of the seven fields fails the minimum bar regardless of how many components it lists. ## The seven elements, and what each fails without **1. Supplier name.** Who is behind the component. In practice: without it, you cannot tell the vendor's own code from inherited dependencies, and when a component hits the news you do not know whose advisory to watch. Failure mode: the supplier appears only in prose, not per component, so the file cannot be sorted by origin. **2. Component name.** The common designation. The failure is rarer than the others because generators fill it by default, but hand-built inventories sometimes carry internal codenames instead. If your vulnerability tooling cannot match the name to a package, the entry is dead weight. **3. Version of the component.** Enough to tell this build from the last. This is the most common real-world gap: component lists arrive with names but no versions, and every vulnerability match becomes a guess. The version is also what makes the SBOM ageable: you can compare what you hold against what shipped later. **4. Other unique identifiers.** A purl (package URL), a CPE, or an equivalent unique handle per component. This is the element the whole check turns on: vulnerability databases resolve identifiers, not names. A purl like `pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1` resolves to exactly one package at one version; the name "log4j-core" alone could match dozens of ecosystems. Components without an identifier cannot be checked against OSV, NVD, or anything else, and no checker, free or paid, can fix that after the fact. **5. Dependency relationship.** What depends on what. When a component turns up vulnerable, this is the data that answers whether the vulnerable library sits in an executed code path or in a leaf dependency nothing calls. Without it, every finding carries the same weight, and triage becomes a judgment call about severity instead of a fact about reachability. **6. Author of the SBOM data.** Who produced the document and with what tooling. The difference between "generated by the build pipeline" and "assembled by a person from a spreadsheet" is the difference between an inventory and a claim. This field is also what makes a vendor's SBOM reproducible: same author, same tool, regenerates the same file. **7. Timestamp.** When the SBOM was generated. An SBOM is a photograph of the build at a moment; the timestamp is the staleness clock. Every advisory published after it applies to what you are holding until the file is regenerated: which is why a stored SBOM needs re-checking, not filing: [how to verify one ->](/blog/vendor-sbom-verification), and [what a standing watch does ->](/sbom-shield). ## What FDA adds FDA's premarket cybersecurity guidance recommends SBOMs "consistent with" the NTIA minimum elements, and adds two fields per component: - **The software level of support.** Whether the component version is still maintained by its project or vendor. - **The end-of-support date.** When it stops being. For a cyber device manufacturer, these two fields are how an SBOM connects to the postmarket obligations section 524B imposes: a device built on a component that went end-of-support is a finding waiting for an inspection. ## The CISA question, answered Searches for "CISA compliant SBOM" conflate two documents, and the confusion is worth naming because buyers inherit it from vendors: - **CISA's** SBOM work covers the levels at which an SBOM can be generated: source (from the development environment), build (during the pipeline), and analyzed (from the finished artifact). CISA also publishes the federal guidance on SBOM consumption. - **NTIA's** minimum elements document defines the seven fields the result must contain, whichever level it was generated at. So "a CISA-compliant SBOM" is not a distinct artifact; if the vendor means anything concrete, they mean NTIA's field list, possibly generated at one of CISA's levels. Ask them which: the answer is usually informative. ## Frequently asked questions **How many NTIA minimum elements are there?** Seven: supplier name, component name, version of the component, other unique identifiers, dependency relationship, author of the SBOM data, and timestamp. FDA adds two per component for medical devices: level of support and end-of-support date. **Is the checklist a regulation?** No, it is the floor NTIA defined under Executive Order 14028: but FDA's guidance recommends consistency with it for cyber devices, and the EU Cyber Resilience Act's documentation requirements overlap heavily, which is why it functions as one in regulated procurement. **What is the most commonly missing element?** In files buyers actually receive: unique identifiers (no purl or CPE per component) and versions. Both make the file unmatchable, which is why the checker reports them first. **How do I check a file against the list?** [The Vendor SBOM Checker ->](/tools/sbom-checker) parses CycloneDX and SPDX in your browser and reports each element as present or missing, per component, plus the OSV match for everything that carries a purl. Nothing is stored. Check a vendor's SBOM against all seven elements, in your browser. [Run the check ->](/tools/sbom-checker) --- *The elements and dates here reflect NTIA's minimum elements document (July 12, 2021, under EO 14028), FDA's premarket cybersecurity guidance, CISA's SBOM guidance, and the EU Cyber Resilience Act as published, as last reviewed; requirements change, so verify current versions before relying on them. Last verified: October 2026. Have a correction or addition? [Request inclusion or a correction ->]* Source: https://vendorquals.com/blog/sbom-minimum-elements. This page is also served as HTML at https://vendorquals.com/blog/sbom-minimum-elements. --- - [All articles](https://vendorquals.com/blog)