FDA Deficiency: Non-Conformant SBOM

What FDA reviewer language looks like

Paraphrased patterns from real deficiency letters. Not verbatim FDA quotes.

• Pattern 1

  The provided Software Bill of Materials does not include all NTIA minimum elements. Specifically, supplier name and unique identifier are missing for several components. Provide an updated SBOM that contains the minimum elements for every component.

• Pattern 2

  The submitted SBOM appears to enumerate top-level dependencies only. Provide an SBOM that includes transitive (sub-)dependencies and identifies the relationship between components.

• Pattern 3

  Provide the SBOM in a machine-readable format (SPDX or CycloneDX) consistent with the format referenced in the cybersecurity management plan, and ensure the version reported in the SBOM matches the device version under review.

Why this happens

• The SBOM is generated from a package manifest (package.json, requirements.txt) instead of from the actual built binary, so it captures declared rather than shipped components.
• Engineering exports an SBOM from one tool while the regulatory team writes the cybersecurity narrative referencing a different format or version, and the two no longer match.
• Operating-system-level packages and firmware blobs are excluded because no one owns generating an SBOM for them.
• The SBOM is treated as a one-time deliverable rather than a build-pipeline artifact, so it goes stale before the submission is filed.

How to fix it

• Generate the SBOM from the build pipeline against the actual shipped artifact (binary, container image, firmware image), not from source manifests.
• Verify every component carries: supplier, name, version, unique identifier (PURL or CPE), cryptographic hash, dependency relationship, author of the SBOM data, and timestamp.
• Use SPDX 2.3+ or CycloneDX 1.5+ — and explicitly state the chosen format in the cybersecurity management plan so reviewers know what to validate against.
• Include OS packages, third-party firmware, and any pre-loaded ML models or rule packs as components.
• Cross-reference the SBOM with the vulnerability management plan and CVE/CWE mapping so reviewers see one consistent component inventory across all three artifacts.

Why machine-readability matters more than completeness

Reviewers run automated tooling against submitted SBOMs before they read your narrative. A component that is technically present but missing a unique identifier (PURL or CPE) cannot be matched against vulnerability databases by their tools, and the reviewer treats it as 'not in the SBOM.' This is the most common reason teams that 'have an SBOM' still get a non-conformance. The fix is not adding more components; it is adding the identifier and version data that lets the SBOM round-trip through a tool.

Keeping the SBOM and the rest of the package consistent

An SBOM deficiency rarely arrives alone. If the SBOM lists a component the vulnerability management plan does not address, you will also receive a vulnerability management deficiency. If the SBOM version does not match the device version under review, you will receive a configuration management deficiency. If the SBOM contains a known-vulnerable component with no risk treatment in the CVE/CWE mapping, you will receive a third deficiency on that as well. Treat the SBOM as the spine of the cybersecurity package and verify every other artifact references the same component inventory before you file.

Standards involved

• SBOMSoftware Bill of Materials (SPDX or CycloneDX)
• FDA 2026FDA Premarket Cybersecurity Guidance (Feb 3, 2026)
• Section 524BSection 524B of the FD&C Act
• IEC 81001-5-1IEC 81001-5-1:2021 - Health Software and Health IT Systems Safety, Effectiveness and Security

Already responding to this deficiency?

Our deficiency response engagement rebuilds the underlying artifact and produces a reviewer-ready response narrative.