FDA SBOM requirements: what the law requires and what FDA recommends

By The PenTest Index · Sources checked October 10, 2026

FDA SBOM requirements start with one legal duty: if you file a covered premarket submission for a cyber device, section 524B of the FD&C Act says you must give FDA a software bill of materials covering commercial, open-source and off-the-shelf software. FDA's February 2026 guidance then recommends what to send with it, including each component's support status and known vulnerabilities.

You don't need to buy a penetration test to meet this rule. An SBOM can come out of your own build process and your suppliers' answers. Below, every item is marked law or recommended, with the section it comes from, followed by a checklist you can copy.

What are the FDA SBOM requirements?

There is one requirement in law and a set of FDA recommendations around it. An SBOM (software bill of materials) is a structured list of the software inside your product and how the pieces depend on each other. The law says you must provide one. FDA's guidance says what a good one looks like and what should travel with it.

Think of the statute as the building code and the guidance as the inspector's written advice. The guidance itself says "should" means recommended, not required, and that you may use another approach if it satisfies the law. FDA still decides what is enough for your submission, so most teams build to the advice.

We read both texts on October 10, 2026 and sorted every SBOM item:

The guidance is Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, final, issued February 3, 2026. It replaced the June 27, 2025 edition.

One caution about the word "recommended." It does not mean "skip it." FDA's own FAQ says that an electronic 510(k) submission "will be put on a Technical Screening hold if it does not contain accurate responses and relevant attachments" in its cybersecurity section. Know which line is law so you can argue from the right source. Then build the whole package.

Which devices need an SBOM?

By law, cyber devices. A device is a cyber device only if all three of these are true, in the statute's words:

1. It "includes software validated, installed, or authorized by the sponsor as a device or in a device."
2. It "has the ability to connect to the internet."
3. It "contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats."

The second test is wider than it sounds. It says ability to connect, not "connects." In section VII.B of the guidance, FDA says it counts devices with network, server or cloud connections; radio links such as Wi-Fi, cellular and Bluetooth; magnetic inductive links; and hardware connectors "capable of connecting to the internet (e.g., USB, ethernet, serial port)." FDA's example is a device that is plugged in by USB for servicing. FDA treats that as able to connect.

Here is how that plays out:

Two more things. The law attaches to the submission, and it says nothing about where the maker is based. And section 524B(d) lets FDA exempt device types by publishing a list in the Federal Register. We searched for such a list and did not find one, so ask your regulatory lead before counting on an exemption.

Not sure whether your device qualifies? FDA's FAQ says manufacturers who are unsure "may contact" the agency. Your regulatory lead should make this call, not a vendor's quiz.

If the rule applies to you, go to the checklist and check the package for the release you plan to submit.

What should an FDA SBOM include?

It should include the eight baseline attributes from the document FDA names, plus two things FDA adds for every component: its level of support and its end-of-support date.

Many checklists stop at seven fields. Here is why that can leave a gap. FDA's guidance points to NTIA's October 2021 paper, Framing Software Component Transparency (second edition). That paper lists eight baseline attributes. It also says the seven-field "Minimum Elements" list that most articles quote is the same set "except component hash."

The first two describe the SBOM as a whole. The other six describe each component.

The NTIA paper does not expect perfection. It says an SBOM "must gracefully handle cases of missing or non-applicable attributes," and it separates "no assertion" (you don't have the data) from "no value" (the field doesn't apply). For dependencies, it lets you say whether your knowledge is unknown, partial or complete. So an honest "we don't know yet" has a proper place in the file. A missing field can also have a format-defined default of "no assertion" or "no value".

The two things FDA adds

For each component, the guidance asks for:

• Level of support. FDA's examples: "actively maintained, no longer maintained, abandoned."
• End-of-support date. The day the component's supplier stops supporting it.

You can put these inside the SBOM or in a separate addendum. FDA allows either.

A filled-in example

Say you make a Wi-Fi infusion pump and you are submitting software release 2.4. This company and every detail below are made up.

Read it the way a reviewer might. Row one is missing your own end-of-support plan. Row three has four unknowns. Nothing here means you need to buy a test. It means you need one internal decision and answers about the open-source library.

Is a CycloneDX or SPDX file enough for an FDA submission?

The format alone doesn't settle it. FDA asks for a machine-readable SBOM and says "industry-accepted formats of SBOMs are encouraged." The SBOM section of the guidance names no format, and we did not find "SPDX" or "CycloneDX" anywhere in the document. Both are widely used. Pick the one your build tools produce cleanly.

What decides "enough" is what's in the file and what comes with it. Check four things:

1. It matches the release. The SBOM describes the exact build you are submitting, not last quarter's.
2. The baseline attributes are there, with unknowns marked as unknown.
3. Support information exists for every component, in the file or an addendum.
4. The vulnerability write-up exists and points back to the components in the file.

A file that passes its format's validator has answered a formatting question. It hasn't told you whether items 1 to 4 are covered.

What vulnerability information goes with the SBOM?

FDA asks for every known vulnerability, how you found it, what it means for safety and security, and what you did about it. This is the part of the package that takes real thought.

From section V.A.4(b), for the device and its components:

• Identify all known vulnerabilities, "including those identified in CISA's Known Exploited Vulnerabilities Catalog."
• Describe how each was discovered, so FDA can judge whether your methods were strong enough.
• Give "a safety and security risk assessment of each known vulnerability (including device and system impacts)."
• Give "details of applicable safety and security risk controls." If you rely on a workaround instead of a fix, describe it.

Having known vulnerabilities is not an automatic fail. The guidance says "no device is, or can be, completely secure." What FDA wants to see is that you know what's there and have a reason for each decision. One line is stricter: vulnerabilities in CISA's catalog "should be designed out of the device," because they are already being exploited.

In the made-up pump, one entry might read: Known issue in Telemetry Library 3.2. Found by a software composition scan of the release build. The affected function is not compiled into our build, so it cannot be reached. Control: build setting documented and rechecked every release. That is four short facts, and they are the four FDA asks for.

What if a component has no end-of-support date?

Keep the gap visible and write down what you did about it. The guidance says that if you are "unable to provide the SBOM information to FDA," you "should provide a justification for why the information cannot be included."

Open-source projects often publish no support promise at all. Don't make one up from how recently someone updated the code. Record what you asked, who you asked, and what you'll do if support stops. FDA also asks for "plans for how third-party software components could be updated or replaced if support ends."

For commercial components, send the supplier one question and keep the answer:

For [component name and exact version], please send: the components it includes that you can substantiate, your current support terms, and any stated end-of-support date. Tell us what you cannot provide and why. Confirm which version your answer covers.

SBOM checklist for an FDA submission

Use this to check one release. Mark each line yes, no or unknown, and write who owns the gap. "Unknown" is a real answer. Don't count it as done.

This is our own checklist, built from the sources above. It is not an FDA form, and FDA decides what is enough for your submission.

Does the rule apply?

• The device meets all three cyber device tests, or our regulatory lead has recorded why not. (Law: 524B(c))
• We know which submission type we are filing and that it is a covered one. (Law: 524B(a))

The SBOM file

• It includes commercial, open-source and off-the-shelf components. (Law: 524B(b)(3))
• It also includes our own code and upstream dependencies. (Recommended: V.A.4(a))
• It is machine-readable, in an industry-accepted format. (Recommended: V.A.4(b))
• It carries the eight baseline attributes, with missing values marked as missing. (Recommended: V.A.4(b))
• It matches the exact product, software version and build we are submitting. (Our check)

For every component

• Level of support is stated. (Recommended: V.A.4(b))
• End-of-support date is stated, or the reason it can't be is written down. (Recommended: V.A.4(b))
• There is a plan to update or replace it if support ends. (Recommended: V.A.4)

The vulnerability write-up

• All known vulnerabilities are listed, and we checked CISA's Known Exploited Vulnerabilities catalog. (Recommended: V.A.4(b))
• Each entry says how it was found. (Recommended: V.A.4(b))
• Each entry has a safety and security risk assessment. (Recommended: V.A.4(b))
• Each entry names the controls. (Recommended: V.A.4(b))

After submission

• Someone owns keeping the SBOM current with each release. (Recommended: V.A.4(a))
• We know how customers will get the SBOM. (Recommended: VI.A)
• The SBOM, threat model, risk assessment and test reports refer to each other. (Recommended: V.A)

SBOM checklist for an FDA submission

Does the rule apply?
[ ] The device meets all three cyber device tests, or our regulatory lead has recorded why not. (Law: 524B(c))
[ ] We know which submission type we are filing and that it is a covered one. (Law: 524B(a))

The SBOM file
[ ] It includes commercial, open-source and off-the-shelf components. (Law: 524B(b)(3))
[ ] It also includes our own code and upstream dependencies. (Recommended: V.A.4(a))
[ ] It is machine-readable, in an industry-accepted format. (Recommended: V.A.4(b))
[ ] It carries the eight baseline attributes, with missing values marked as missing. (Recommended: V.A.4(b))
[ ] It matches the exact product, software version and build we are submitting. (Our check)

For every component
[ ] Level of support is stated. (Recommended: V.A.4(b))
[ ] End-of-support date is stated, or the reason it can't be is written down. (Recommended: V.A.4(b))
[ ] There is a plan to update or replace it if support ends. (Recommended: V.A.4)

The vulnerability write-up
[ ] All known vulnerabilities are listed, and we checked CISA's Known Exploited Vulnerabilities catalog. (Recommended: V.A.4(b))
[ ] Each entry says how it was found. (Recommended: V.A.4(b))
[ ] Each entry has a safety and security risk assessment. (Recommended: V.A.4(b))
[ ] Each entry names the controls. (Recommended: V.A.4(b))

After submission
[ ] Someone owns keeping the SBOM current with each release. (Recommended: V.A.4(a))
[ ] We know how customers will get the SBOM. (Recommended: VI.A)
[ ] The SBOM, threat model, risk assessment and test reports refer to each other. (Recommended: V.A)

Prepared with The PenTest Index, sources checked October 10, 2026. Not an FDA form.

Do not paste passwords, keys, vulnerability details or network diagrams into a shared copy of this list.

Does the SBOM rule apply when you change a cleared device?

Yes, if the change needs a new covered premarket submission. FDA's FAQ says that when a previously authorized cyber device changes in a way that requires premarket review, "the law applies to the new premarket submission."

What surprised us is how little the SBOM part shrinks for small changes. Section VII.D of the guidance splits changes into two groups. For changes that may affect cybersecurity, such as new connectivity or a new update mechanism, FDA points you to the full documentation. For changes unlikely to affect it, FDA's examples are a change in materials, a new sterilization method, or an algorithm change that leaves the architecture alone. For that second group FDA trims what it asks for on security processes. It does not trim the SBOM. The text restates that the SBOM is required and recommends the same content as for a new device.

So if you are filing for a materials change on a connected device, plan to send a current SBOM anyway.

Do you have to keep the SBOM updated and share it?

FDA recommends both. Section V.A.4(a) says an SBOM "or an equivalent capability should be maintained as part of the device's configuration management" and "regularly updated to reflect any changes to the software in marketed devices." Section VI.A lists the SBOM among the things to give users, says makers "should provide or make available SBOM information to users on a continuous basis," and says it "should be in a machine-readable format."

If you run devices in a hospital, that last line is your opening. Ask the maker for the SBOM and for its MDS2 form, a standard security disclosure, for your exact model and software version. The guidance notes that an MDS2 "may address a number of" its labeling recommendations. For testing a device on your own network, see the hospital section of our medical device testing page.

Does an SBOM replace a vulnerability assessment or a penetration test?

No. They answer three different questions, and FDA's guidance lists them separately.

A penetration test is people trying to break into your product. A vulnerability scan is a tool checking for flaws that are already known. We explain the gap between them in penetration testing vs vulnerability scanning.

The three connect. In the testing section (V.C), FDA lists "software composition analysis of binary executable files" as one kind of testing to consider. That means checking what is really inside the shipped software, which is a direct check on your SBOM. FDA also asks for "traceability" between the threat model, the risk assessment, the SBOM and the testing. In practice, hand your tester the SBOM. Then ask:

"Will you take our SBOM as an input, check the shipped build against it, and try the known-vulnerable components you find?"

Do you need a tool, a supplier answer, or outside help?

Buy help for the task that is missing, after checking whether you already have it covered. Go back to the made-up pump. Its gaps were one internal decision and facts about an open-source library. A penetration test would not, by itself, resolve those gaps. If someone offers a "pentest for FDA SBOM compliance," ask which line of the checklist it fills.

FDA does not require an outside firm for testing. The guidance says only that "in some cases, it may be necessary to use third parties" to get enough independence from the developers.

If testing is your gap, our medical device page compares five offers, two with published prices, and has a brief you can send so every quote answers the same question. The brief already has a line for your SBOM.

Compare medical device penetration testing offers

Buying a test for something other than a device, like a web app or an API? Find My PenTest Match is our free scope checklist. It needs no email or sign-up and sends nothing to providers. It does not list device testing firms, so use the device page for that.

Find My PenTest Match

What you'll hear, and what the text says

Most pages on this topic are written by companies that sell SBOM tools or security services. Some of what they say is tighter than the source. We checked five common statements against the text on October 10, 2026.

One more that is easy to get wrong. The guidance says failing section 524B(b)(2), the duty to keep secure processes and provide patches, is a prohibited act under section 301(q) of the FD&C Act. The SBOM duty is the next paragraph, (b)(3). We are not saying a missing SBOM carries no consequence. We are saying that if someone quotes you a penalty, ask which clause it comes from.

What happens if the SBOM is missing or thin?

Expect a delay, at least. FDA's FAQ says an electronic 510(k) submission "will be put on a Technical Screening hold if it does not contain accurate responses and relevant attachments in the Cybersecurity section." FDA's earlier grace policy on refusing cyber device submissions "expired on October 1, 2023," and the FAQ says FDA now expects sponsors to have had enough time to prepare.

We can't tell you how FDA will rule on any file. No checklist, tool or test report guarantees clearance.

More questions

Did FDA relax the SBOM requirements in 2026?

Not that we can find. The February 2026 edition of the guidance still states that an SBOM is required for cyber devices and still carries the recommendations in the table above. The duty sits in the statute, which a guidance document cannot change. For what did change between editions, see our FDA cybersecurity guidance tracker.

Does a newer CISA SBOM document change FDA's baseline?

Not by itself. CISA and partner agencies published an updated general "Minimum Elements" document in 2026. FDA's February 2026 guidance still names the October 2021 NTIA paper, so that is the baseline to check against for a device submission until FDA says otherwise.

Does the law require posting the SBOM publicly?

No. The SBOM clause says to provide it "to the Secretary," meaning FDA. Sharing it with customers is a separate FDA recommendation, and the guidance leaves the method to you, such as an online portal.

Are software licenses one of the baseline attributes?

No. License is not among the eight attributes in the NTIA paper FDA names. Your SBOM format, your contracts or your legal team may still want it.

Is this the same as the SBOM rules for selling software to the U.S. government?

No. Those come from federal procurement policy and CISA. This page covers medical devices under the FD&C Act only.

How we checked

We read the statute, FDA's current guidance, FDA's cybersecurity FAQ and the NTIA paper on October 10, 2026, and built the tables, checklist and example from them. Quoted words are from those texts. The pump example is made up.

We did not review a real submission, talk to FDA, or test any SBOM tool. The PenTest Index is an independent buyer's index for penetration testing. We don't perform, authorize or certify testing, and nothing here is legal or regulatory advice. Read how we check offers and how we make money.

Sources, all checked October 10, 2026

• 21 U.S.C. 360n-2 (FD&C Act section 524B), read in full; clause (b)(3) and the definition also read in the official U.S. Code copy
• 21 U.S.C. 331(q)(3): the reference to section 360n-2(b)(2)
• FDA guidance page: edition, date, status
• FDA guidance PDF: sections I, II, IV.D, V.A, V.C, VI.A and VII.B to VII.D
• FDA cybersecurity FAQ: Q1 to Q5, Q9 and Q10; page marked current as of June 26, 2025
• NTIA, Framing Software Component Transparency, second edition, October 21, 2021: sections 2.2 and 2.3
• Qualysec, FDA SBOM requirements article: the two statements quoted above