Since October 1, 2023, every "cyber device" submitted to the FDA has been subject to a new legal requirement: manufacturers must provide a software bill of materials as part of their premarket filing. This isn't guidance anymore -- it's law. Section 524B of the Food, Drug, and Cosmetic Act, added by the Consolidated Appropriations Act of 2023, gives the FDA explicit statutory authority to reject 510(k), PMA, and De Novo submissions that don't meet FDA SBOM requirements. Medical device manufacturers who treated SBOMs as a nice-to-have during the 2022 draft guidance era are now finding that reviewers issue Refuse to Accept (RTA) letters for missing or incomplete SBOMs before a submission is even substantively reviewed. This post breaks down what 524B actually requires, who it applies to, and how to build a compliance process that survives FDA scrutiny.
What Are the FDA SBOM Requirements Under Section 524B?
The FDA SBOM requirements under Section 524B mandate that manufacturers of "cyber devices" submit a machine-readable SBOM listing commercial, open-source, and off-the-shelf software components, along with a plan to monitor, identify, and remediate vulnerabilities in those components throughout the device's lifecycle. The statute defines a cyber device as one that includes software validated, installed, or authorized by the sponsor; can connect to the internet; and contains technological characteristics that could be vulnerable to cybersecurity threats. In practice, that sweeps in nearly every network-connected infusion pump, imaging system, implantable cardiac device, and hospital monitoring platform on the market. The FDA's final guidance, "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions," published in June 2023, operationalizes 524B by specifying that SBOMs should follow a standard format -- SPDX or CycloneDX -- and include, at minimum, component name, version, supplier, and any known unresolved vulnerabilities at the time of submission.
Which Medical Devices Fall Under 524B Cybersecurity Requirements?
Medical device cybersecurity 524B obligations apply to any device meeting the statutory definition of a cyber device, regardless of device class. That means Class II devices going through the 510(k) pathway are just as exposed as Class III PMA devices -- classification doesn't create an exemption, network connectivity and software content do. The FDA has been explicit that this includes devices with Bluetooth, Wi-Fi, cellular modems, or even USB-based firmware update mechanisms, since those all represent an attack surface. Legacy predicate devices aren't automatically grandfathered either: if a manufacturer submits a new 510(k) for a modified version of an older device and that device meets the cyber device definition, the full SBOM and cybersecurity documentation package is required for that submission, even if the original predicate predates 524B entirely. The only devices clearly outside scope are those with no software component at all or software that cannot connect to any network, which is an increasingly small category as manufacturers add remote monitoring and OTA update capability to product lines that never had it before.
What Does FDA Premarket Cybersecurity Guidance Require in an SBOM?
FDA premarket cybersecurity guidance requires an SBOM that goes well beyond a flat component list -- it expects a structured, machine-readable artifact tied to a documented vulnerability management plan. The June 2023 guidance lays out specific data elements the agency expects reviewers to be able to extract: supplier name, component name, version string, and either a CPE, purl, or other unique identifier per component, plus support end-of-life dates where known. Submissions also need to include a description of how the manufacturer plans to monitor, identify, and disclose newly discovered vulnerabilities post-market, referencing processes like coordinated vulnerability disclosure and integration with a PSIRT function. Reviewers cross-reference submitted SBOM components against the National Vulnerability Database, and the guidance explicitly states that any known unresolved vulnerability with a CVSS score indicating exploitability should be accompanied by a risk assessment and mitigation rationale rather than left unaddressed. Submissions that provide a PDF component list instead of a structured SPDX or CycloneDX file are routinely flagged in review cycles because reviewers can't programmatically parse them against vulnerability feeds.
What Happens If You Submit an Incomplete Cyber Device Submission?
An incomplete FDA cyber device submission gets an RTA (Refuse to Accept) determination, which stops the review clock entirely and sends the submission back before FDA staff evaluate the device's safety or effectiveness. This is the mechanism that has made 524B compliance an acquisition-blocking issue for manufacturers rather than a documentation afterthought: since October 2023, the FDA's RTA checklist for 510(k) submissions has included specific cybersecurity items, and missing SBOM elements are grounds for an automatic bounce. Industry reports since the guidance took effect describe review delays running from several weeks to multiple months for manufacturers who had to reconstruct SBOMs after the fact -- pulling component inventories from engineering teams, chasing down OEM suppliers for version and vulnerability data, and converting spreadsheets into SPDX format under submission deadline pressure. For a device with a target market window, a single RTA cycle triggered by an SBOM gap can mean months of lost revenue and a scramble that pulls engineering resources away from the next product cycle.
How Do You Build a Compliant SBOM for FDA Submission?
Building a compliant SBOM starts with generating it at build time, directly from your CI/CD pipeline, rather than reconstructing it manually before a submission deadline. A build-time SBOM captures the actual dependency tree as compiled -- including transitive dependencies pulled in by third-party libraries -- which is the level of completeness FDA reviewers expect and manual spreadsheet audits routinely miss. From there, manufacturers need three things working together: a standard machine-readable format (SPDX 2.3 or CycloneDX 1.5, both accepted by the FDA), continuous vulnerability matching against sources like the NVD so that known-vulnerability disclosures in the submission stay current up to the filing date, and a documented lifecycle process showing how new CVEs affecting shipped devices get triaged and communicated post-market. Manufacturers with a portfolio of devices, each with their own firmware branch and component set, also need SBOM version control tied to specific device model numbers and software releases, since reviewers may ask for the SBOM matching an exact submission version months into the review cycle.
How Safeguard Helps
Safeguard builds SBOM generation and monitoring directly into the software supply chain so medical device manufacturers aren't assembling FDA submission packages by hand under deadline pressure. Our platform generates SPDX and CycloneDX SBOMs automatically from your build pipeline, capturing full dependency trees -- including transitive and firmware-level components -- so what you submit reflects what's actually shipping in the device. Safeguard continuously matches every component against live vulnerability feeds, flagging newly disclosed CVEs against components already in fielded devices so your PSIRT and regulatory teams get advance notice instead of finding out during a review cycle or, worse, from a security researcher. For manufacturers managing multiple device lines and submission histories, Safeguard maintains versioned SBOM records tied to specific releases, so when a reviewer asks for the exact SBOM behind a given 510(k) filing, it's a lookup, not a reconstruction project. That combination -- automated generation, continuous monitoring, and audit-ready version history -- is what turns FDA SBOM requirements from a submission risk into a routine part of how you already ship software.
For manufacturers still preparing their first 524B-covered submission, the practical starting point is an inventory audit: pull the actual dependency list from your build system rather than the one in your design history file, since those two often diverge after years of firmware patches and supplier substitutions. Pair that with a written vulnerability monitoring commitment reviewers can point to, and most of the FDA's premarket cybersecurity expectations are already met before a submission is drafted.