FDA SBOM Requirements for Medical Devices: The Complete 2026 Guide
| Interlynk
A complete 2026 guide to FDA SBOM requirements for medical devices. What Section 524B mandates, why the FDA can refuse to accept a submission, exactly what a compliant SBOM must contain, how the guidance has changed from 2023 to the February 2026 final version, and the postmarket obligations that outlast the submission.
Overview
What Section 524B requires, why submissions get refused, what a compliant SBOM must contain, and the postmarket obligations that begin after clearance.
If you make a medical device that qualifies as a "cyber device" under Section 524B, FDA requires an SBOM as part of the applicable premarket submission. The SBOM is one part of a broader cybersecurity package that FDA evaluates during premarket review.
This guide sets out what the requirement is, where it comes from, what your SBOM has to contain, and what happens after clearance. The rules have been stable in substance since 2023. The guidance around them has been revised twice in the past year, and the version numbers cause confusion, so this guide identifies the current one.
FDA SBOM Requirements at a Glance
Section 524B of the Federal Food, Drug, and Cosmetic Act requires manufacturers of cyber devices to provide an SBOM in premarket submissions. The SBOM must be machine-readable and cover commercial, open-source, and off-the-shelf components. The FDA has held refuse-to-accept authority for missing or inadequate cybersecurity information since October 1, 2023. The requirement did not loosen in 2026. The guidance was updated to align with new quality-system terminology, and the SBOM mandate stands.
Legal Basis: Section 524B of the FD&C Act
The legal basis is Section 524B, added to the FD&C Act by the December 2022 omnibus and effective March 29, 2023. It establishes requirements for "cyber devices," including devices that have software, are capable of connecting to the internet, and have technological characteristics that could be vulnerable to cybersecurity threats. The connection does not have to be a browser or a conventional internet-facing interface; the relevant question is whether the device is capable of connecting to the internet, directly or through an intermediary system.
For a cyber device, Section 524B requires the manufacturer to submit a plan to monitor and address postmarket vulnerabilities, design and maintain the device so it can be updated and patched, and provide an SBOM. The SBOM is one pillar of a larger cybersecurity package, and it is the focus of this guide.
The obligation belongs to the submitter, regardless of who wrote the code. Contract manufacturers, platform vendors, and open-source maintainers all contribute components, but the sponsor of the submission owns the SBOM. Treating a supplier's code as out of scope is a common path to an incomplete SBOM.
A note on requirements vs. guidance: Section 524B establishes statutory cybersecurity requirements for cyber devices. FDA's current guidance explains the agency's recommendations for demonstrating cybersecurity in premarket submissions. Not every recommendation in the guidance is itself a statutory requirement.
Refuse-to-Accept (RTA) and Premarket Review
Refuse-to-accept, or RTA, is an administrative gate applied before substantive review. FDA's specific cybersecurity RTA policy applied through October 1, 2023, and that policy subsequently expired. The underlying Section 524B cybersecurity requirements did not expire.
For a cyber device, sponsors still need to provide the cybersecurity information required by Section 524B and address the recommendations in FDA's current cybersecurity guidance. Missing or inadequate information can create delays during the premarket process, even though the expired 2023 cybersecurity RTA policy should not be described as an ongoing RTA rule.
The practical effect is still a schedule problem: incomplete cybersecurity documentation can lead to questions, deficiencies, or other delays before a submission can move forward. For a product with a launch date attached, that delay has a real cost.
Common SBOM problems include a file that is not machine-readable, components without versions or useful identifiers, third-party code left out, or an inventory that does not accurately describe the device being submitted.
Required Contents of a Compliant SBOM
The FDA does not mandate a single SBOM file format. The guidance calls for a machine-readable SBOM and points manufacturers to the NTIA minimum elements as a baseline. In practice, CycloneDX and SPDX are the two dominant machine-readable formats used by SBOM tools and organizations. For a deeper comparison of the two, see our guide on CycloneDX vs SPDX.
Beyond the format, a submission-ready SBOM needs to hold up in four areas.
Completeness. Every software component, not only the ones you wrote. Commercial, open-source, and off-the-shelf code all belong in the inventory. The sourcing of each component matters here, which is where the distinction between SBOM, SOUP, COTS, and OTS software becomes practical. We cover that terminology and how the FDA and IEC 62304 treat each category in SBOM, SOUP, COTS, and OTS in Medical Device Software.
Identity. Each component needs enough information to be tracked and matched against vulnerability data: producer, name, and version, with stable identifiers like purl or CPE. A component named in free text, with no version and no identifier, cannot be correlated against a CVE feed, which defeats the purpose of listing it.
Support status. The FDA expects manufacturers to address component supportability, including support status and end-of-support considerations, so reviewers can understand whether software components remain maintained and whether unsupported components create additional risk. This expectation is specific and often missed. We covered it separately in The FDA Wants to Know: Is Your Software Still Supported?.
Currency. The SBOM has to describe the software you are submitting, at the version you are submitting. An SBOM generated from an old build, or from source when you shipped a binary, describes a different device. Version it per device software version, and keep it retrievable for every version still in clinical use.
FDA Cybersecurity Guidance Timeline
SBOM expectations appear across several FDA documents, and older articles reference whichever version was current when they were written. The table below maps each document to its place in the chain.
Document | Date | What it did |
|---|---|---|
Section 524B enacted | Dec 2022, effective Mar 29 2023 | Created the statutory cyber-device category and the SBOM mandate |
Cybersecurity RTA policy | Through Oct 1 2023 | FDA's specific cybersecurity RTA policy applied through this date and then expired |
Final guidance | Sep 2023 | First final premarket cybersecurity guidance incorporating Section 524B recommendations |
Final guidance | Jun 27 2025 | Superseded the 2023 version and updated premarket cybersecurity recommendations |
Final guidance | Feb 3 2026 | Current final version, aligned with the QMSR framework |
The February 2026 revision causes the most confusion, so it is worth being precise about it. On February 3, 2026, FDA issued an updated final guidance, "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions." It superseded the June 2025 version. The revision was driven in part by the Quality Management System Regulation, the QMSR, which took effect February 2, 2026 and replaced the previous Quality System Regulation under 21 CFR Part 820 with a framework incorporating ISO 13485:2016 by reference.
In practice, the February 2026 update aligns the cybersecurity recommendations with the QMSR framework. It did not remove or weaken the SBOM requirement under Section 524B. It reinforces that cybersecurity processes belong within the device quality system rather than being treated as an isolated technical activity.
Postmarket SBOM Obligations
SBOM obligations do not end at submission. For cyber devices, the SBOM supports a broader set of postmarket cybersecurity obligations that extend across the device lifecycle.
Manufacturers have to monitor for new vulnerabilities, maintain a coordinated vulnerability disclosure process, and provide timely security updates and patches as required by the statute and applicable FDA expectations. None of that works well against a static file. When a new CVE lands in a third-party component, the manufacturer needs to answer one question quickly: which devices and versions contain it? A current, queryable SBOM makes that analysis much faster when it is correlated with vulnerability data.
Under the QMSR, vulnerability monitoring and response belong inside the quality system, in complaint handling and corrective action. SBOM maintenance is an ongoing process obligation, not a one-time submission deliverable.
Common SBOM Compliance Failures
These failure patterns recur across submissions.
A parts list with no maintenance behind it. An SBOM submitted once, never updated, with no monitoring process attached. It satisfies a premarket checkbox and fails the postmarket obligation the moment a CVE appears.
Supplier code treated as out of scope. The obligation is the sponsor's. Components from contract manufacturers and platform vendors have to be in the SBOM, with real identity and support status rather than blank fields.
A shallow inventory. Top-level dependencies only, with the transitive tree left out. A vulnerability in a transitive dependency still needs to be identified and assessed.
Version drift. The submitted SBOM describes a build other than the one going to market. Generate the SBOM from the actual release, and version it with the software.
Free-text components. Names with no versions and no identifiers, which cannot be matched to a CVE feed and add noise instead of transparency.
Each of these separates an SBOM that looks done from one that survives review and stays useful afterward.
Practical Steps for FDA SBOM Compliance
For a medical device manufacturer, FDA SBOM compliance comes down to three habits. Generate the SBOM from the actual build, so it describes the device you are shipping. Make it complete and identifiable, including third-party, open-source, and transitive components with useful versions and identifiers, while addressing component supportability. Keep it current after clearance and correlate it with vulnerability data, so you can answer exposure questions when a new vulnerability appears.
The submission is a single milestone in a long device lifecycle. When the SBOM is maintained as part of the broader cybersecurity process, preparing it for a submission becomes routine work instead of a scramble.
Interlynk helps medical device manufacturers automate audit-ready SBOMs across builds, map component identity and support status, and continuously monitor software exposure against vulnerability data. Generate in CycloneDX or SPDX, keep SBOMs current across the device lifecycle, and answer postmarket exposure questions faster. See our FDA 524B compliance solution. Trusted by security and compliance teams at 100+ regulated companies.
This guide reflects FDA guidance current as of the February 3, 2026 final version and was written for accuracy at the time of publication. FDA guidance evolves. For any submission, confirm requirements against the current FDA guidance and your own regulatory counsel. This article is informational and not legal or regulatory advice.