The FDA's authority to require cybersecurity documentation for premarket submissions came from section 524B of the FD&C Act, added by the 2022 omnibus. By 2026, the Center for Devices and Radiological Health has enough review experience that patterns have emerged. Some submissions sail through. Others stall for months because of preventable SBOM issues.
I have worked with device manufacturers on 510(k) and De Novo submissions, and the cybersecurity section is where avoidable mistakes cost the most calendar time. This post is a practical walkthrough of what 2026-era reviewers actually look for and how to prepare the SBOM portion of your cybersecurity documentation so it does not become the bottleneck.
What does the FDA actually want in the SBOM section?
The FDA expects a machine-readable SBOM in CycloneDX or SPDX format, covering every software component that executes on or is distributed with the device. This includes firmware, OS components, third-party libraries, and any first-party code the manufacturer ships. The SBOM must cover the as-shipped state of the device, which in practice means the SBOM needs to be generated from the production build artifacts, not from a developer workstation.
Beyond the machine-readable file, the cybersecurity documentation must include a narrative section explaining the SBOM, the methodology used to generate it, the tools involved, and how the manufacturer intends to maintain and update the SBOM over the device lifecycle. The FDA's 2026 guidance made clear that this narrative is where reviewers look for evidence that the SBOM is not a one-time compliance artifact.
Component identifiers matter more than many submitters realize. The FDA wants pURL, CPE, or equivalent identifiers for each component so that the SBOM can be automatically correlated against vulnerability feeds. An SBOM full of "unknown" or free-text component names is a reviewer red flag because it signals that the manufacturer cannot easily monitor their own device for vulnerabilities.
Which SBOM mistakes cause submissions to stall?
Incomplete firmware coverage is the single most common issue. Submitters generate SBOMs from their application code and forget that the underlying RTOS, bootloader, or vendor-supplied BSP is also in scope. Reviewers notice, because the component list looks suspiciously small for a device that runs a real-time operating system with dozens of middleware stacks.
Missing transitive dependencies is next. Some SBOM generation tools, especially when run against compiled binaries without the original manifests, produce flat lists of direct dependencies and miss the transitive graph entirely. The FDA expects a complete dependency graph, and reviewers who compare the SBOM to the binary will spot the gap.
Stale SBOMs cause delays during the review cycle. If a submission is in progress and the manufacturer ships a new firmware version, the SBOM in the original submission is out of date. Submitters who fail to update the SBOM during review end up answering additional information requests that extend the timeline by weeks or months.
Finally, vulnerability treatment without VEX is a problem. The FDA expects manufacturers to address known vulnerabilities in their components. If the SBOM lists a component with a public CVE and the submission does not explain whether the vulnerability is exploitable in the device context, reviewers will ask. Providing a VEX document alongside the SBOM preempts these questions.
How should manufacturers prepare the SBOM lifecycle documentation?
The premarket submission is only the first SBOM you will produce. The FDA's total product lifecycle approach means you must explain how SBOMs will be generated, reviewed, and distributed for every subsequent firmware update. Submissions that describe a repeatable, automated process fare better than submissions that describe manual SBOM generation tied to specific individuals.
Document your SBOM generation tool selection and version. If you use Syft, Tern, or a vendor-specific tool, say so explicitly, with version numbers. Reviewers compare across submissions and pattern-match against known tool behaviors. A submission that cannot name its tool invites questions.
Explain how SBOMs will be distributed to healthcare delivery organizations post-market. The 2023 guidance established that SBOMs must be made available to customers. The 2026 update tightened this expectation by asking manufacturers to describe their distribution mechanism in the premarket submission. A web portal, a customer-facing API, or a direct-to-integrator feed are all acceptable. Silence is not.
How do reviewers correlate SBOMs with vulnerability claims?
Reviewers are using automated tooling to cross-check SBOMs against the NVD, CISA KEV, and medical-device-specific vulnerability feeds from ICS-CERT. If your SBOM contains a component with an unpatched critical CVE and your submission does not address it, expect a hold letter.
The correlation works best when pURLs are present and accurate. A pURL like pkg:npm/lodash@4.17.19 correlates cleanly against public vulnerability data. A free-text entry like "lodash (latest)" does not. Submissions with high-quality identifiers get through automated triage faster than submissions with sloppy identifiers.
CISA KEV entries are treated with special weight. If your SBOM contains a component with a KEV-listed vulnerability, the FDA expects either a patch, a compensating control with a clear rationale, or a VEX statement explaining why the device is not exploitable. Anything less tends to trigger a deficiency letter.
What does 2026 look like for legacy devices already on the market?
Section 524B applies to premarket submissions, but the post-market cybersecurity management expectations apply to the entire fleet. Manufacturers with legacy devices that predate the SBOM era are under pressure to generate retroactive SBOMs for devices still in clinical use. This is hard when source code or build systems have been lost, but it is increasingly expected.
Binary-based SBOM generation tools have matured enough to make this feasible for most devices. The resulting SBOMs are less precise than build-time SBOMs, and manufacturers should document the methodology honestly. Reviewers prefer imperfect binary SBOMs with transparent limitations over no SBOMs at all.
The broader trend is that SBOM maturity is becoming a differentiator for device manufacturers selling to health systems. Purchasing organizations are asking for SBOMs as part of their own risk management, independent of the FDA mandate. Manufacturers who have solved this internally now have a procurement advantage.
What about post-market SBOM distribution and updates?
The FDA expects SBOMs to be updated when devices are updated. A firmware release that changes components should ship with an updated SBOM, and that SBOM should be available to healthcare delivery organizations within a reasonable window of the firmware availability. Manufacturers who treat SBOM distribution as a one-time premarket deliverable are misreading the expectation.
Distribution mechanisms vary. Some manufacturers publish SBOMs through customer portals alongside firmware downloads. Others expose an API that customer asset management tools can query. A few still email SBOM files on request, which is operationally weak but technically meets the bar for low-volume relationships. The direction of travel is toward machine-to-machine distribution, and forward-looking manufacturers are investing there.
Healthcare delivery organizations are standing up their own SBOM ingestion capabilities, often for the first time. This creates a two-sided maturation where manufacturers and providers are learning the practice together. Manufacturers who can onboard provider ingestion workflows quickly earn operational goodwill that translates into contract stickiness.
How Safeguard.sh Helps
How Safeguard.sh Helps
Safeguard.sh is purpose-built for the SBOM discipline that modern FDA submissions demand. Our ingestion pipeline accepts CycloneDX and SPDX at 100-level transitive dependency depth, normalizes pURL and CPE identifiers, and applies reachability analysis that cuts 60 to 80 percent of the vulnerability noise reviewers would otherwise question. Griffin AI drafts VEX statements for unreachable or non-exploitable components and generates the SBOM lifecycle narrative sections that premarket submissions require. With integrated TPRM for your firmware and BSP suppliers plus container self-healing for any Linux-based device components, Safeguard.sh turns FDA cybersecurity documentation from a submission-time scramble into a continuous process.