The FDA can now refuse to even review your medical device submission if it's missing a software bill of materials. Since October 1, 2023, the agency has applied a "refuse to accept" (RTA) policy to premarket submissions for any "cyber device" — a category defined in Section 524B of the Food, Drug, and Cosmetic Act, added by the Consolidated Appropriations Act, 2023 (FDORA), signed December 29, 2022. If your 510(k), PMA, or De Novo submission includes software that connects to the internet and lacks the required cybersecurity documentation, the FDA won't open the file. This isn't a future requirement or a draft guidance suggestion — it has been enforced for over two years. Manufacturers of insulin pumps, infusion systems, imaging software, and connected diagnostics have already had submissions rejected on these grounds. Here's exactly what the SBOM requirement covers, what format it must take, and what happens when a device manufacturer gets it wrong.
What does the FDA actually require in an SBOM for a medical device?
The FDA requires a machine-readable SBOM listing every software component in the device, including commercial, open-source, and off-the-shelf elements, per its final guidance "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions," issued June 27, 2023. The guidance builds on the NTIA's 2021 minimum elements — supplier name, component name, version string, other unique identifiers, dependency relationships, SBOM author, and timestamp — and adds FDA-specific fields: the support level provided for each component (e.g., actively maintained vs. end-of-life), the component's end-of-support date, and licensing terms. Section 524B(b) of the FD&C Act also requires manufacturers to submit a plan for identifying and addressing postmarket vulnerabilities, including a coordinated vulnerability disclosure process. In practice, a single infusion pump submission can list 40-80 third-party components once RTOS libraries, communication stacks, and embedded Linux packages are counted, and the FDA expects the SBOM to reflect the exact build shipped in the 510(k), not a generic product-line inventory.
Which medical devices are actually covered by this mandate?
The mandate covers any device that meets the FD&C Act's definition of a "cyber device": it includes software (including firmware), can connect to the internet, and contains technological characteristics validated by the manufacturer that could be vulnerable to cybersecurity threats. That three-part test sweeps in far more products than manufacturers expect — not just networked imaging systems and hospital infusion pumps, but Bluetooth-connected continuous glucose monitors, cloud-syncing cardiac implants, and even standalone diagnostic software that later gets a network-connected update path. The FDA's Center for Devices and Radiological Health (CDRH) has stated publicly that it expects the large majority of new premarket submissions received after October 1, 2023 to qualify as cyber devices requiring Section 524B compliance. Legacy devices already on the market aren't automatically exempt either: any modification requiring a new 510(k) or PMA supplement triggers the same cybersecurity documentation requirements, which has pushed manufacturers with 10+ year-old product lines to build SBOMs retroactively for codebases with no existing dependency records.
What format does the SBOM need to be submitted in?
The SBOM must be delivered in a machine-readable, automatable format — the FDA's guidance specifically names SPDX, CycloneDX, and SWID tags as acceptable standards. A PDF table listing component names and versions, which was common practice in submissions before 2023, does not satisfy this requirement, and reviewers have flagged submissions for exactly this reason. The format matters because FDA reviewers and, downstream, hospital procurement and biomedical engineering teams need to programmatically diff an SBOM against vulnerability feeds like the National Vulnerability Database and CISA's Known Exploited Vulnerabilities catalog. CycloneDX has become the more common choice in medical device submissions because its schema includes native support for vulnerability exploitability exchange (VEX) statements, which let a manufacturer assert that a listed component contains a known CVE but isn't exploitable in the device's specific configuration — a distinction that matters enormously when a single OpenSSL or curl CVE otherwise appears to affect thousands of fielded devices.
What happens if a submission is missing SBOM information?
The FDA refuses to accept the submission for review, full stop — RTA means the review clock never starts, and the manufacturer has to resubmit with the missing cybersecurity information before FDA staff will look at the application at all. This isn't a follow-up deficiency letter after months of review; it's a front-door rejection, which the FDA began enforcing on all applicable submissions received on or after October 1, 2023, per its own transition-period announcement. For a manufacturer targeting a specific launch quarter, an RTA on cybersecurity grounds can add months of delay, because the resubmission re-enters the queue rather than being fast-tracked. The FDA's premarket cybersecurity guidance also requires a "cybersecurity management plan" and threat model alongside the SBOM, so an incomplete SBOM often surfaces alongside other missing artifacts — meaning device makers who treat SBOM generation as an afterthought typically face compounding delays across several review criteria simultaneously, not just one.
How do postmarket vulnerability monitoring obligations work after clearance?
Clearance doesn't end the obligation — Section 524B(b) requires manufacturers to monitor, identify, and address postmarket vulnerabilities for the life of the device, including issuing patches on a "reasonably justified regular cycle" and out-of-cycle updates for critical vulnerabilities "as soon as possible." That means the SBOM submitted at clearance becomes a living artifact: when a new CVE lands against a component the device ships — say, a vulnerable version of a TLS library or an embedded RTOS — the manufacturer needs to already know, from its own SBOM, whether that component is present and in which fielded product versions. The FDA has specifically called out the 2019 "Urgent/11" vulnerabilities in the VxWorks real-time operating system (CVE-2019-12255, CVE-2019-12260, and related CVEs) as the kind of event this requirement exists for, since Armis research at the time identified VxWorks running in over 200 million devices across industries, including a substantial share of the medical device install base, with no centralized way for hospitals to know which specific devices were affected. Manufacturers without an up-to-date, queryable SBOM cannot answer "are we affected" questions in hours; they end up doing it in weeks.
What's a concrete example of why this actually matters?
The clearest recent example is the 2023 disclosure of CVE-2023-1968 and CVE-2023-1966, two vulnerabilities in Illumina's Universal Copy Service, a component bundled into multiple genomic sequencing instruments used in clinical labs. CISA's advisory rated CVE-2023-1968 a 9.8 CVSS score, and the flaw allowed a remote, unauthenticated attacker to access data on the affected instrument or potentially change device settings — a serious issue for equipment used to generate diagnostic genomic results. Because Illumina's software was embedded as a component inside other manufacturers' cleared devices, the impact didn't stop at Illumina's own product line: it required downstream device makers to determine, quickly, whether their own cleared products shipped the vulnerable component. That determination is trivial with an accurate SBOM and CycloneDX-formatted dependency data, and it can take weeks of manual firmware archaeology without one. It's a direct illustration of why the FDA moved from encouraging SBOMs to mandating them at the door of the review process.
How Safeguard Helps
Safeguard generates FDA-compliant SBOMs in CycloneDX and SPDX formats directly from your build pipeline, and ingests existing SBOMs from acquired product lines or third-party firmware suppliers so legacy devices aren't left with manual, error-prone inventories. Griffin AI cross-references every component against NVD and CISA KEV data continuously, not just at submission time, so postmarket monitoring obligations under Section 524B(b) are met automatically instead of through quarterly spreadsheet audits. Safeguard's reachability analysis distinguishes components that are merely present in your SBOM from ones whose vulnerable code paths are actually exploitable in your device's configuration — the same distinction VEX statements are meant to capture — which cuts down the noise engineering teams have to triage before an out-of-cycle patch decision. When a fix is available upstream, Safeguard opens an auto-fix pull request against the affected dependency so the regulatory clock on "as soon as possible" patching starts closing the same day the CVE is confirmed, not weeks later.