SBOM Submission Requirements Under FDA Medical Device Guidance

Software-defined medical devices, wireless infusion pumps, cloud-connected SaMD platforms, implantable devices that phone home to a monitoring server, all run on layered stacks of third-party code. The FDA now requires a software components list for a defined class of these products, and it treats that requirement as a matter of patient safety, not paperwork. Most manufacturers still confuse the binding legal mandate with the softer guidance language sitting next to it. That confusion is what turns a routine 510(k) submission into a six-month delay, and it's an entirely avoidable one.

A large majority of medical device software depends on external components: open-source libraries, third-party packages, off-the-shelf firmware nobody in the building wrote. When something goes wrong in one of those components, it goes wrong inside a device that's implanted, infusing, or monitoring a patient in real time. Most vulnerabilities reported against medical devices in 2024 traced back to exactly this kind of third-party code, not to flaws the manufacturer's own engineers introduced. Supply chain attacks against software are projected to keep growing sharply through 2026, and devices that stay in clinical service for a decade or more mean a vulnerability discovered in year eight still has to be traceable to the exact component version running in the field. That's the whole reason the FDA moved off voluntary guidance and onto statutory footing, and it's why the line between "required" and "recommended" deserves careful attention rather than a skim.

The legal foundation: what Section 524B actually requires versus what the guidance recommends

Section 524B of the Federal Food, Drug, and Cosmetic Act, added by the Consolidated Appropriations Act of 2023, is where the actual legal authority sits. It mandates SBOMs, secure product development frameworks, and postmarket vulnerability monitoring for a category of products the statute calls cyber devices. None of that is optional once a device meets the definition.

The FDA's June 27, 2025 final guidance, titled "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions," reads like a different animal on paper. It uses "should" throughout, language that technically makes it non-binding and advisory, the kind of document agencies issue to explain how they'll interpret a law rather than to create new legal duties. Don't read too much into that softness, though: in practice, the gap between the statute and the guidance is a lot narrower than the language suggests. Section 524B gives the FDA the authority to issue a Refuse to Accept decision on any submission missing required cybersecurity information, SBOMs included, and the agency has made clear it will use that authority.

For 510(k) submissions, this shows up concretely in the eSTAR electronic template, which has a dedicated cybersecurity section. Leave the SBOM attachment out, or submit one that's incomplete, and the technical screening step flags it before a reviewer ever gets to the substance of the application. The guidance's soft "should" doesn't mean much when the electronic intake system itself won't let a bare submission through. This June 2025 version replaced the September 2023 guidance, so any team still working from the older document is operating on an outdated map, full stop.

Which devices fall under the mandate and which do not

A device counts as a cyber device under Section 524B only if it clears three tests at once. It has to include software that the sponsor validated, installed, or authorized as part of the device. It has to be capable of connecting to the internet, directly or indirectly. And it has to have technological characteristics that could be vulnerable to cybersecurity threats.

That definition was written broad on purpose. A cloud-based Software as a Medical Device platform qualifies. So does a wireless infusion pump. A device with no software at all, or one that's fully air-gapped with no network capability whatsoever, generally falls outside the mandate. But "generally" is doing real work in that sentence: a device with only limited or indirect connectivity can still qualify if it's technically capable of forming a network connection, even one it rarely uses. Embedded firmware, an onboard operating system, dependence on a companion mobile app, a remote monitoring dashboard, any of these can pull a device into scope.

The mandate reaches across submission types. Traditional, Special, and Abbreviated 510(k)s, PMA, De Novo, HDE, and PDP submissions are all covered. Products that went through premarket review before March 29, 2023 are grandfathered in, but that protection evaporates the moment a modification triggers a new submission. Manufacturers unsure whether their device qualifies should ask before submitting, since misclassification can contribute to approval delay, and it's a self-inflicted one at that. Devices with network connectivity and validated software are the core of the affected population; devices with no software or no network capability whatsoever generally sit outside the requirement.

The compliance timeline: three dates every submission team must know

March 29, 2023 is when Section 524B took effect, meaning SBOM and broader cybersecurity requirements became binding law for new premarket submissions of cyber devices starting that day.

October 1, 2023 brought full enforcement alongside the eSTAR mandate for 510(k) submissions. Submissions with incomplete SBOM documentation became subject to rejection at that point, and the FDA's position was straightforward: manufacturers had already had enough runway to prepare.

June 27, 2025 marks the updated final guidance, which widened SBOM expectations to include lifecycle metadata, end-of-support dates being the clearest example, and established VEX file requirements coming into force starting in March 2026.

The date that marked a decisive shift was October 1, 2023, when full enforcement took effect and submissions missing SBOM documentation became subject to a Refuse to Accept decision, not a request for more information, but a decision that pulls the submission out of the review queue. Manufacturers who reached baseline compliance back in 2023 need to check whether their current SBOM process actually covers the 2025 lifecycle metadata additions and the 2026 VEX expectations. Baseline compliance from two years ago doesn't carry forward on its own; it has to be re-verified against each new guidance layer.

What an FDA-compliant SBOM must contain: the NTIA baseline and the FDA additions

The FDA anchors its content expectations to the NTIA's Minimum Elements framework, published in "Framing Software Component Transparency" in October 2021. Seven attributes form the floor for every component listed: Supplier Name, identifying who created or defines the component; Component Name, the designation the supplier assigned; Version, distinguishing a patched release from a vulnerable one; Other Unique Identifiers such as a purl or CPE string, which let automated tools match a component against CVE databases; Dependency Relationships, mapping how components connect so a vulnerability upstream can be traced downstream; SBOM Author, establishing who's accountable for the data; and Timestamp, confirming the SBOM reflects the actual build in question rather than an earlier snapshot.

The FDA layers additional expectations on top of that NTIA floor. Each component needs a Software Component Support Level, classifying it as actively supported, in a security-fixes-only legacy state, or unsupported and abandoned. An End-of-Support date matters enormously here, given that many devices stay in clinical use for ten to fifteen years, well past the point most commercial software reaches its own end of life. Known vulnerabilities need to be documented against each component, with the CISA Known Exploited Vulnerabilities Catalog serving as a recommended reference point. And where a compensating control or a patch has already been applied, the SBOM needs a mitigation description explaining it.

None of this is limited to direct dependencies, and this is where most SBOMs actually fail. Transitive dependencies, the packages a direct dependency itself relies on, make up a large share of the open-source code sitting inside a typical commercial codebase, and they're exactly the layer a manual review tends to miss. A component list that stops at direct dependencies looks complete and isn't. Device labeling has to state a "Support Life" figure too, the window during which security patching will actually be provided, so hospital IT departments can plan around it across their device inventories rather than discovering a gap after the fact.

Format requirements: why machine-readable matters and which formats the FDA accepts

An SBOM formatted as a spreadsheet or a PDF does not satisfy the requirement, full stop. The FDA's expectation is machine-readable data, because the entire point of an SBOM is that a tool can ingest it and check every listed component against a vulnerability database automatically. A human reading a document line by line can't do that at scale, and a device with hundreds of components makes manual cross-referencing impractical anyway.

The primary formats that meet the bar are SPDX and CycloneDX. SPDX treats VEX as a related but separate document. CycloneDX carries VEX natively inside the same schema as the SBOM itself, which matters more than it sounds like it should, since teams that pick CycloneDX get integrated vulnerability triage documentation without building a second workflow. If a team is starting from scratch today, CycloneDX is the more defensible choice precisely because it doesn't split the SBOM and VEX obligations into two systems that have to stay synchronized by hand.

For 510(k) submissions specifically, the eSTAR template's cybersecurity section requires the SBOM attachment in one of these machine-readable formats. An attachment that's missing or incomplete is subject to a technical screening hold before a reviewer examines the substance of the application. Teams standardizing on CycloneDX are effectively building ahead of the March 2026 VEX requirement, while teams on SPDX need to plan for a separate VEX workflow layered on top. Open, machine-readable formats also let a manufacturer hand the same evidence to a hospital system managing risk across its own device inventory, without producing a second version for that audience.

VEX: what it is, why it becomes required in March 2026, and what a missing VEX actually signals to reviewers

VEX, short for Vulnerability Exploitability eXchange, is a companion document that answers a question an SBOM alone can't: is a known vulnerability in a listed component actually exploitable in this specific product, in this specific configuration? A component can carry a published CVE and still pose zero real risk if the vulnerable function is never called or the vulnerable code path is disabled. VEX is how a manufacturer communicates that distinction to a reviewer instead of leaving them to guess.

Four status codes cover the possibilities: Not Affected, Affected, Fixed, and Under Investigation. Starting in March 2026, VEX files become a required part of SBOM submissions in premarket cybersecurity documentation, an expectation established under the updated FDA cybersecurity guidance. Strictly speaking, the FDA doesn't mandate a document literally titled "VEX" by name. What Section 524B does require is a postmarket vulnerability management plan and evidence of an active monitoring process that can identify, assess, and address vulnerabilities in a cyber device's components. VEX is simply the mechanism that makes that obligation visible at the level of an individual component, rather than as a vague policy statement.

The failure mode that actually matters to a reviewer, worse than most manufacturers assume, is an SBOM listing several hundred matched CVEs with zero triage evidence attached to any of them. A reviewer doesn't read that as thoroughness. A reviewer reads it as an unmanaged risk backlog, and that's a far worse signal to send in a premarket submission than a plain formatting gap. CycloneDX's native VEX support gives manufacturers a lower-friction path toward the March 2026 deadline; SPDX and CSAF handle VEX as a related but separate document, which means an extra workflow to keep in sync by hand. The principle that produces this consistency: cybersecurity isn't a one-time submission event, it's a lifecycle obligation, and VEX is the tool that makes that obligation auditable rather than aspirational.

The SBOM as a living document: postmarket obligations and what triggers an update

The June 2025 guidance is explicit that an SBOM is a living document, maintained through formal configuration management, not a file submitted once and archived. Several events reopen that document. A software update or patch applied after clearance is among the events that can trigger a revision. So does a change to connectivity features or network interfaces, a newly identified vulnerability in a component already on the list, a component crossing into end-of-support or end-of-life status, or any modification substantial enough to require a fresh premarket submission.

The FDA monitors submitted SBOMs on an ongoing basis for newly disclosed vulnerabilities in listed components, and the posture the agency expects flips the usual order of operations: the manufacturer is supposed to get there first, running continuous monitoring that surfaces a new CVE before the FDA's own review flags it. Under the June 2025 guidance, facility inspectors can ask to see the machine-readable SBOM (SPDX or CycloneDX) during an inspection, not only during premarket review. That's a meaningful expansion of where this document has to live and how current it has to stay.

Given that devices commonly stay in clinical service for ten to fifteen years, the postmarket SBOM obligation runs well past the commercial lifecycle most product teams actually plan around. Investigators reviewing postmarket compliance tend to flag the same handful of gaps repeatedly: incomplete dependency trees, no documented vulnerability analysis, and maintenance plans that are vague or simply absent.

What rejection actually looks like: RTA decisions, AI letters, and the 3-to-6-month delay

Two distinct outcomes await a submission with SBOM problems, and they cost very different amounts of time. A Refuse to Accept decision is what happens when required cybersecurity documentation, SBOMs included, is absent or fails the eSTAR technical screening. RTA pulls the submission out of the review queue completely; refiling means starting the clock over from scratch.

An Additional Information letter is the softer outcome. It shows up when an SBOM is present but deficient, an incomplete dependency tree, missing vulnerability analysis, absent lifecycle metadata, and it keeps the submission in process while the agency waits on a response. According to reporting from Censinet, an AI letter tied to SBOM deficiencies typically delays clearance by three to six months. That's a real cost, but it's not the same as being knocked out of the queue.

After October 1, 2025, the FDA has both the statutory authority and the stated intent to issue RTA decisions for SBOM omissions, and the grace-period logic the agency leaned on back in 2023 no longer applies to anyone. Most AI letters trace back to the same few root causes: transitive dependencies left off the tree, no vulnerability analysis run against CVE or KEV data, or a maintenance and support-life plan that's unclear. Blunt as it sounds, an SBOM that's correctly formatted but only lists direct dependencies, leaving the transitive layer out entirely, is the single most common and most avoidable source of delay in this entire process. It's a gap that's cheap to fix before submission and expensive to fix after.

Why accurate SBOMs require reproducible build environments, not just documentation discipline

An SBOM is only as accurate as the build process that generated it. If a component gets swapped, upgraded, or patched in the build pipeline without that change flowing back into the SBOM record, the document in the submission no longer describes the device actually shipping to a hospital. Documentation discipline, careful manual tracking, review checklists, doesn't close that gap on its own, because a person maintaining a spreadsheet by hand has no reliable way to catch a dependency version that shifted three layers deep in a build system they don't control line by line.

That's the deeper argument driving every requirement in this guidance, and it's the one most compliance teams miss because they treat the SBOM as a paperwork exercise rather than an engineering output. The FDA is asking for something more than a document. It's asking for proof that a manufacturer's build process is disciplined enough to produce the same, known set of components every time, and that any change to that set gets captured automatically rather than caught later by accident. A device that stays in clinical use for over a decade needs an SBOM history that can answer, precisely, what code was running in any given unit at any given point in its service life. It's a structural problem no template can fix. It's an engineering one, and it's the one the rest of this guidance is quietly built around.