Medical device vulnerability management: what FDA requires
By The PenTest Index · Sources checked October 10, 2026
Medical device vulnerability management is the ongoing work of finding, judging and fixing security flaws in a device after it ships. If you submit an FDA "cyber device" for premarket review, the law makes you send FDA a written plan for it. For uncontrolled-risk flaws, FDA's guidance sets 30- and 60-day conditions for a Part 806 reporting exception. Hospitals have a different job, covered below.
Below: what is law and what is advice, how to handle one new flaw, your own two dates, and the nine things the plan should cover.
Does the FDA require medical device vulnerability management?
Yes, if your product is a cyber device going through a premarket submission. The law asks for three things: a plan, cybersecurity processes and patches, and a software parts list. The day counts and most of the detail you'll hear quoted come from guidance, which is advice.
We read the statute and both FDA guidance documents on October 10, 2026 and set them beside what vendors tend to say.
| What you'll hear | What the text says | Where |
|---|---|---|
| "FDA requires vulnerability management" | Law. The sponsor must submit a plan to "monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure." | Section 524B(b)(1) |
| "You must patch within 30 days" | Not in the law. It gives no day count. Patches for known unacceptable flaws come "on a reasonably justified regular cycle." Critical flaws that could cause uncontrolled risks get fixed "as soon as possible out of cycle." | Section 524B(b)(2)(A) and (B) |
| "30 and 60 days is the rule" | Guidance. The numbers are conditions under which FDA "does not intend to enforce" one reporting rule for a serious flaw. All four conditions must be met. | Postmarket guidance, Section VII.B |
| "Every security patch gets reported to FDA" | Guidance says no. Routine updates and patches for lower-risk flaws are "generally not required to be reported." | Postmarket guidance, Sections IV.C and VII.A |
| "FDA requires a yearly penetration test" | Guidance, and softer. Testing after release "should be performed at regular intervals commensurate with the risk (e.g., annually)." | Premarket guidance, Section V.C |
| "The software parts list is optional" | Law. A software bill of materials (SBOM) is required for a cyber device. | Section 524B(b)(3) |
Both guidance documents say "Contains Nonbinding Recommendations" on every page, and both say "should" means recommended. FDA still decides what is enough for your device. Nothing here guarantees a clearance.
Is your product a cyber device? All three must be true. It includes software you validated, installed or authorized. It can connect to the internet. And it has features that could be open to cyber threats. FDA reads "can connect" widely: its examples include Wi-Fi, Bluetooth, USB and serial ports. Your regulatory lead makes this call, not a vendor's quiz.
Which devices does the law reach? FDA's guidance says the duty applies to premarket submissions from March 29, 2023. For devices already on the market, FDA's separate postmarket guidance covers "legacy devices" too, so the advice on handling flaws applies to older products. FDA also publishes its own questions and answers on section 524B.
For editions and what changed in 2026, see our FDA cybersecurity guidance tracker.
How do you handle one new vulnerability?
Answer five questions in order and write down the evidence for each. A match on a parts list is where you start. It is not proof your device can be attacked.
A vulnerability is a weakness someone could use. A CVE is a public ID number for one. When a new CVE names a part your device uses, work down this table. The five questions are our suggested order, built from FDA's guidance. They are not an FDA form.
| Question | Evidence you need | If you can't answer yet |
|---|---|---|
| 1. Is the affected part in a build we shipped? | SBOM and build records for each released version | Don't treat a name-only match as confirmed |
| 2. Can an attacker reach it on our device? | Whether the weak function is switched on, how it is reached, what protections sit in front | Mark it unknown. Unknown is not "not affected" |
| 3. If used, could it hurt a patient? | Which device function it touches and how bad the harm could be | Take it to your safety and clinical people |
| 4. So is the risk controlled or uncontrolled? | Answers 2 and 3 together, plus controls already in place | Treat it as open and assign an owner and a date |
| 5. What did we do, and who checked it? | The fix or control, test results on the fixed build, customer notice, release record | It stays open |
Question 4 is FDA's own test. Its postmarket guidance says to weigh how easy the flaw is to use against how badly a patient could be hurt, then make a yes-or-no call. Controlled means the leftover risk of patient harm is acceptably low. Uncontrolled means it is not. FDA suggests a scoring tool such as CVSS for the first half and a five-step harm scale (negligible, minor, serious, critical, catastrophic) for the second. A score alone doesn't settle it. FDA's example: a flaw that changes a thermometer reading is a different risk from one that changes an insulin pump's dose.
A made-up example. Say you ship firmware version 4.2, and a supplier warns about version 2.1 of a library. Your SBOM for 4.2 lists that library at 2.1. No real product or CVE is involved here.
- Question 1 is answered: the part is in a shipped build.
- Question 2 is unknown. Your build may not switch on the weak function.
- So today you record an owner, the affected builds, a date to finish the check and any stopgap protection. You don't write "not affected," and you don't call it a recall.
- If your engineers can show from the code that the function is never reachable, write that down with the evidence and close it. If they can't tell, that gap is what an outside tester can answer.
Copy this record and fill one in per flaw. Keep device secrets, passwords and patient data out of it.
Vulnerability decision record
Report: ID, date received, where it came from. Product: model, hardware revision, software or firmware builds affected. Part: name and version, and how we matched it. Reachable on our device? Yes / no / unknown, and the evidence. Patient harm if used: which function, how severe, who judged it. Controls already in place: Decision: controlled or uncontrolled, decided by, date. Action: fix, stopgap control or no change, with the reason. Checked by: test done, build tested, result. Told: customers, the information-sharing group, FDA if needed, with dates. Closed on: date, and what would reopen it.
How fast do you have to act, and do you report it to FDA?
It depends on your answer to question 4. For a controlled risk, fix it on your normal update cycle and you generally don't report it. For an uncontrolled risk, FDA says fix it as quickly as possible, and the 30- and 60-day conditions affect whether FDA intends to enforce a Part 806 report.
Under a rule called 21 CFR Part 806, makers report certain device corrections to FDA. The postmarket guidance says uncontrolled-risk flaws are reportable under Part 806 unless reported under Parts 803 or 1004. FDA "does not intend to enforce" Part 806 reporting when all four of these are true:
- No known serious adverse events or deaths are tied to the flaw.
- Within 30 days of learning of it, you tell customers and the user community, name stopgap controls, write a fix plan to bring the risk down and document why the timeline makes sense.
- Within 60 days, you fix it, validate the change and send a deployable fix to customers and the user community so the risk becomes acceptable. FDA notes a stopgap control can sometimes be the long-term answer if it makes the risk acceptable.
- You are an active member of an ISAO (a group that shares threat information) and you give it your customer notice when you notify customers.
Miss one and the exception is gone. If a Part 806 correction or removal report is required, it is due within 10 working days after you begin that action—not 30 or 60 days after learning of the flaw. FDA adds that a device left with uncontrolled risk may be treated as violating the law.
Work out your two dates. Example: you learned of the flaw on October 10, 2026. Day 30 is November 9, 2026. Day 60 is December 9, 2026.
Calculate your two dates
Only for flaws you judged to be uncontrolled risk. A Part 806 report, when required, is generally due within 10 working days after initiating a reportable correction or removal. It says nothing about death or injury reports under 21 CFR Part 803. Not legal advice.
| Situation | Report to FDA? | Source |
|---|---|---|
| Routine patch for a controlled-risk flaw | Generally no | Postmarket guidance, IV.C and VII.A |
| Uncontrolled risk, all four conditions met | FDA does not intend to enforce the Part 806 report | VII.B |
| Uncontrolled risk, any condition missed | Part 806 reporting may be required; check the correction or removal and other reporting paths | VII.B; 21 CFR 806.10 |
| PMA device with periodic reporting requirements, either kind | Include it in the periodic (annual) report | VII.A and VIII |
| The flaw may have caused a death or serious injury | Different rules apply (Part 803), outside this page | Guidance introduction |
What goes in a vulnerability management plan?
FDA's premarket guidance lists nine things the plan should cover. You'll run most of them yourself. Two or three are commonly bought, and one calls for periodic security testing.
The nine items are FDA's (Section VI.B). The "who does it" column is our judgment for a small maker.
| # | Plan item | Who usually does it | Have this in writing |
|---|---|---|---|
| 1 | Personnel responsible | You | Names and backups |
| 2 | Sources, methods and frequency for watching for flaws | A platform, a service or your own engineer | Which feeds and how often |
| 3 | Finding and fixing flaws on CISA's Known Exploited Vulnerabilities list | A platform or service | How a match gets flagged. FDA says these "should be designed out of the device" |
| 4 | Periodic security testing | An independent internal or outside tester | Scope, interval, report |
| 5 | Timeline to develop and release patches | You | Your regular cycle and the reason for its length |
| 6 | Update processes | You | How a fix is validated |
| 7 | Patching capability | You | How fast an update reaches devices in the field |
| 8 | Coordinated vulnerability disclosure process | You, or a service | A public address and policy for outside reports |
| 9 | How you'll tell customers about fixes | You | The template and the channel |
On item 5, FDA's guidance says the cycle length depends on risk and should be justified in the plan. Its example sets a connected thermometer beside a surgical robot.
FDA also recommends tracking three numbers: the share of found flaws you patched, the time from finding a flaw to patching it, and the time from a patch being ready to it being installed in the field. If you can't produce those today, start logging them now.
For the parts list itself, see FDA SBOM requirements.
Should you build it, buy it or hire a tester?
Most small makers end up doing all three. Run the decisions yourself, buy the flaw-watching if nobody on staff can own it weekly, and budget the testing separately, because Medcrypt lists testing as an add-on and Blue Goat Cyber's listed postmarket offer does not say whether one is included.
Say you make one connected Class II monitor that is already on the market. You have an SBOM and two firmware engineers, and no security staff. You need flaw monitoring (items 2 and 3), a way into an ISAO, periodic testing (item 4) and a yearly total you can budget. This buyer is made up.
We checked two published offers against those needs on October 10, 2026. Everything below is what each provider publishes. We have not bought either one.
| Offer | Need | Finding | Question to send |
|---|---|---|---|
| Medcrypt MSI, from $35,000 per product line per year (US dollars) | Monitoring | Supported. The plan lists "Helm SBOM and vulnerability management" and "Continuous vulnerability monitoring" | — |
| Medcrypt MSI | ISAO | Unresolved. "MedISAO membership" is included. FDA's test is active participation, which includes you sharing information and keeping records | "Beyond membership, what must we do to meet FDA's four active-participation criteria?" |
| Medcrypt MSI | Periodic testing | Mismatch at the listed price. Penetration testing is an "Add-on" and no test price is shown | "What is the test's own price and scope, and who performs it?" |
| Blue Goat Cyber postmarket program, no price published | Monitoring | Supported. Lists SBOM monitoring against the national vulnerability database, CISA's exploited list and vendor advisories | — |
| Blue Goat Cyber | Yearly total | Unresolved. "Monthly retainer or annual fixed fee," quoted after a call | "What is the annual total for one product line, and what is the minimum term?" |
| Blue Goat Cyber | Periodic testing | Unresolved. The page says "Unlimited retests," but the program list doesn't name a penetration test | "What exactly is retested, by whom, and is a yearly test inside the fee?" |
"Supported" means that one need matches what the provider published. It is not a quality rating, and a written proposal can change any finding.
Our read for that buyer: either offer can cover the watching. Medcrypt is the only one with a number to budget against, and that number is for a year of platform and advisory services, not a test. Ask Blue Goat Cyber for its annual total before comparing. Neither is a fit if all you need is a one-time test.
See Medcrypt's plans and what $35,000 includes
See Blue Goat Cyber's postmarket program scope
When you may not need to buy monitoring at all: one simple product, a clean SBOM and an engineer who will check the feeds on a set day each week. Write that down as items 1 and 2 of your plan. The risk is that it lapses when that person gets busy, so name a backup.
When does a vulnerability need a penetration test?
When you can't tell from your own evidence whether a flaw is reachable or whether your fix worked, or when your plan's testing interval comes due. A penetration test doesn't run the program for you.
Three things get mixed up here. A vulnerability scan is a tool listing known flaws. A penetration test is people trying to break in. Vulnerability management is the standing process that takes both as inputs and decides what to fix and when. Think of a smoke alarm, a fire inspection and the building's fire plan. The plan says who does what. The other two feed it. More on the first two in penetration testing vs vulnerability scanning.
A targeted test can answer question 2 (can it be reached on this build?) and question 5 (did the fix hold?). It can't decide whether the patient risk is acceptable, prove your SBOM is complete or roll a patch out to the field. Those stay with you.
If you do hire a tester, FDA's guidance lists five things the report should show: who tested and how independent they were, the scope, the duration, the methods and the findings. Test a spare unit in a lab, never a device connected to a patient, and get written permission that names the exact targets. A scope list is for buying. It is not permission to test.
Item 4 on FDA's list is periodic security testing, and a fix isn't finished until someone checks it. Our device page puts five testing offers side by side, two with published prices, and has a brief you can send so every quote answers the same question: compare medical device penetration testing offers.
Is the part you need tested the device's cloud app or API, not the hardware? Find My PenTest Match is free and needs no email or sign-up. It shows which of the web app and API offers we compare fit your answers and gives you a brief to send. It does not list device-testing firms.
After a test, see what to do with the findings and how often to test.
What can a hospital do about a medical device it can't patch?
Find out exactly what you have, get the maker's answer in writing and limit what the device can talk to until a fix arrives. You usually can't change the maker's software yourself, and you shouldn't probe a device that is in use.
FDA calls device security a shared responsibility. Its guidance says makers should give users the parts list, end-of-support dates and stopgap controls users can apply. That is what you ask for.
| Question | The maker answers | You do |
|---|---|---|
| Which models and versions are affected? | Affected list | Match it to your inventory, version by version |
| Does it apply the way we've set it up? | Impact statement | Share how the device is connected |
| Is there a fix, and when? | Patch and date | Schedule it with clinical staff and a backup unit |
| What do we do until then? | Stopgap controls | Apply network limits and watch for odd behavior |
| When does support end? | End-of-support date | Plan replacement |
FDA's own example of a stopgap: the maker tells users to cut the device off from the hospital network when it can run safely without it.
Send the maker this:
Please tell us which models and software versions this advisory affects, whether it applies in our configuration and why, the fix or control you recommend, any safety or service limits, when the fix will be available, and who to contact.
Also ask for the maker's MDS2 form, a standard security disclosure, for your exact model and version. Our MDS2 page explains where to get it and how to read it. One caution from the vendor side: Asimily, which sells hospital device-security software, states that ordinary active scanning can disrupt medical equipment. Agree any testing with clinical engineering first. See testing a device in a hospital and penetration testing for healthcare.
Questions people still ask
Does a CVE in our SBOM mean our device is vulnerable?
No. It means a part you ship has a known weakness. Whether your device can be attacked through it depends on how you built and set up that part. Record the evidence either way.
Do we have to join an ISAO?
The law doesn't say so. FDA "strongly" recommends it, and active membership is one of the four conditions for the reporting exception. FDA looks at four things: you're a member, the group has written policies, you share flaw information with it, and you have a documented way to act on what it sends you.
Does this apply to a device cleared years ago?
FDA's postmarket guidance covers devices already on the market, including legacy devices, so its advice on judging and fixing flaws applies. Whether the section 524B plan duty reaches a particular older device, for example after a change that needs a new submission, is a question for your regulatory lead. FDA's questions and answers on section 524B are the place to start.
Is there a standard we can follow?
FDA's premarket guidance points to AAMI TIR57 and ANSI/AAMI SW96 for security risk management. Following a standard helps you organize the work. It doesn't certify you or guarantee FDA's answer. See which standards name testing for medical devices.
What about Europe?
Agree the evidence with your regulatory team and notified body. We did not review European rules for this page.
How we checked
We compare specific offers against stated buying needs and show our sources. For this page we read the statute, FDA's 2016 postmarket guidance in full and FDA's February 2026 premarket guidance through its section on vulnerability plans, plus two providers' public pages, all on October 10, 2026. We did not buy a service, talk to a provider or read anyone's actual plan. The example buyer and the firmware example are made up. We don't perform, authorize or certify testing, and this page is not 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, section 524B of the FD&C Act: plan, patches, SBOM, cyber device definition
- FDA, Postmarket Management of Cybersecurity in Medical Devices (PDF): final, December 28, 2016. Controlled and uncontrolled risk, the four conditions, reporting, ISAO criteria
- FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (PDF): final, February 3, 2026. Plan items, metrics, testing, labeling
- Medcrypt pricing: price, unit and what the plan lists
- Blue Goat Cyber, postmarket vulnerability management: program scope and fee wording
- Asimily, medical device vulnerability management: the scanning statement attributed above
More from us: medical device vulnerabilities, the CISA count.