On this page
Published:
Key Takeaways
- Patch timing for medical devices follows patient safety risk and exploitability, not the vendor's release date or the CVSS base score alone.
- A controlled risk can usually be fixed in a planned release. An uncontrolled risk needs prompt customer notice and a fix or compensating control.
- A vendor-issued patch for a CVE is an input. You still assess applicability, verify the fix in your device, and decide how to release it.
- Many cybersecurity updates made only to strengthen security are not reportable as corrections or removals, but uncontrolled risks can change that answer.
- Document every decision, including a decision not to patch, so reviewers and customers can see the reasoning.
You patch a medical device vulnerability based on its risk to patient safety and device performance, not on the vendor's release date alone. If the risk is controlled, the fix can usually ship as a routine update. If the risk is uncontrolled, the FDA expects fast action: customer notice and a fix or mitigation on a short timeline. A vendor-issued patch for a CVE still needs your own assessment, testing, and release decision.
A third-party library in your device gets a new CVE. The vendor ships a patch the same week. Your hospital customers ask when they will get it.
The honest answer depends on risk, not on the vendor's schedule. A patch that is urgent for an office laptop may be low priority for a device where the vulnerable code is unreachable. The reverse is also true.
The FDA's Postmarket Management of Cybersecurity in Medical Devices guidance (December 28, 2016) frames this decision around controlled and uncontrolled risk. Section 524B of the FD&C Act requires cyber device manufacturers to provide updates and patches on a reasonably justified regular cycle for known unacceptable vulnerabilities, and as soon as possible out of cycle for critical vulnerabilities that could cause uncontrolled risks.
This article explains how to make that call and document it.
Why This Matters
Patching decisions are where a postmarket plan meets the field. A plan that says "we patch critical issues promptly" means little without a defined way to decide what is critical.
The FDA's Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 3, 2026) asks manufacturers to describe how they will maintain safety and effectiveness through updates and patches. Section 524B(b)(2) makes update and patch processes a statutory duty for cyber devices.
The pressure is real. CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities confirmed as exploited in the wild, and many affect common components found in device software, such as operating systems and network libraries. A KEV listing changes how quickly a team should look at a finding.
Relevant standards include ISO 14971 for safety risk management, AAMI TIR57 for security risk management, and IEC 81001-5-1 for health software security activities, including maintenance and vulnerability handling. AAMI SW96 links security risk management to device risk management across the lifecycle.
What Is the Difference Between Controlled and Uncontrolled Risk?
Controlled risk means the residual risk of patient harm from a vulnerability is acceptable. Uncontrolled risk means it is not, because existing controls do not adequately reduce the chance of exploitation or the severity of harm.
The FDA's 2016 postmarket guidance uses this split to set expectations. It asks manufacturers to assess exploitability and the severity of patient harm together.
| Factor | Controlled risk | Uncontrolled risk |
|---|---|---|
| Residual patient harm risk | Acceptable | Unacceptable |
| Typical response | Planned or routine update | Prompt notice and fix or mitigation |
| Customer communication | Release notes or regular bulletins | Direct notice to customers |
| FDA reporting | Often not required for security-only updates | May require reporting unless policy conditions are met |
[FDA LANGUAGE] The 2016 guidance describes enforcement discretion for certain uncontrolled-risk cases when the manufacturer communicates with customers within 30 days, fixes or mitigates within 60 days, and participates in an ISAO, among other conditions. Those timelines belong to that specific policy, not to every vulnerability.
Does a Vendor-Issued Patch for a CVE Have to Be Applied?
No vendor patch is automatically required, but every relevant CVE requires an assessment. The question is whether the vulnerable code is present, reachable, and able to affect safety or essential performance in your device.
Start with your SBOM. Confirm the affected component and version are in the shipped software, not just in a build tool. Then check whether the vulnerable function is used and whether an attacker can reach it through the device's interfaces.
If the vulnerability does not apply, record why. A VEX statement is a common way to communicate that result to customers. If it does apply, the vendor patch is often the preferred fix, but you still verify it in your device and run regression testing before release.
[KEY REQUIREMENT] Treat the vendor's patch date as the start of your assessment, not the end of your obligation. Your release decision depends on your device context and your verification evidence.
How Do You Decide the Patch Timeline?
Set timelines by risk level using a documented method. CVSS is one input. The MITRE rubric for applying CVSS to medical devices, qualified by the FDA as a Medical Device Development Tool, helps adapt scoring to clinical use.
See also: Vulnerability Management Metrics for Medical Device Manufacturers (2026), Documenting Update Cadence for an FDA Submission, and FDA MDDT for Cybersecurity: Using the CVSS Rubric for Devices.
A practical decision path looks like this:
- Applicability. Is the component present and the vulnerable code reachable?
- Exploitability. Is it in the KEV catalog, is exploit code public, and what access does an attacker need?
- Patient impact. What happens to the patient or the device's essential performance if it is exploited?
- Residual risk. With current controls, is the risk acceptable?
- Response. Choose a routine release, an expedited release, or a compensating control while a fix is built.
Compensating controls matter when a patch takes time. Examples include disabling an unused service, network segmentation guidance for hospitals, or a configuration change. Communicate them clearly and track them until the permanent fix ships.
When Must a Patch Be Reported to the FDA?
Many security patches do not require a report under 21 CFR Part 806. The 2016 guidance treats updates made only to strengthen cybersecurity, with no uncontrolled risk to patients, as cybersecurity routine updates and patches that are generally not reportable.
Uncontrolled risks are different. Fixing them can be a correction or removal that must be reported, unless the enforcement-discretion conditions in the guidance are met. Also check whether a software change requires a new premarket submission. A security fix that changes intended use or significantly changes function needs regulatory review.
Your regulatory team owns that decision. Cybersecurity analysis supplies the evidence it depends on.
Not sure how a specific CVE affects your device? Our FDA postmarket cybersecurity services include vulnerability triage and patch planning.
How Blue Goat Cyber Approaches This
We start with the vulnerability and your device, not with the score. We confirm the affected component through your SBOM, trace whether the vulnerable code is reachable through real interfaces, and check exploitation status, including KEV listings.
We then assess exploitability using our documented method and pair it with your ISO 14971 safety inputs. That gives a defensible controlled or uncontrolled risk call. Where a patch takes time, we help define compensating controls and the customer communication that goes with them.
We document each decision, including nonaffected findings and deferrals, so your postmarket records show the reasoning. We also help write the patch criteria and timelines into your cybersecurity management plan.
The manufacturer owns safety severity, risk acceptance, release, and FDA reporting decisions. We support the security analysis behind them. Blue Goat track record: 275+ FDA submissions supported, zero cybersecurity rejections. Learn more about our FDA postmarket cybersecurity services.
Frequently Asked Questions
When should you patch a medical device vulnerability?
Patch based on the risk to patients and device performance. If residual risk is acceptable, include the fix in a planned release. If risk is uncontrolled, notify customers promptly and deliver a fix or compensating control quickly. Section 524B also requires an out-of-cycle update as soon as possible for critical vulnerabilities that could cause uncontrolled risks.
Do you have to apply every vendor-issued patch for a CVE?
No. You must assess every relevant CVE, but a patch is needed only when the vulnerability applies to your device and the risk calls for it. Confirm the component is shipped and the vulnerable code is reachable. Record nonaffected results, often in a VEX statement, and verify any patch you do release.
Is a high CVSS score enough to require an urgent patch?
Not by itself. CVSS base scores come from enterprise IT and do not reflect clinical use or patient harm. A high score on unreachable code may be low risk. Combine CVSS with exploitation evidence, device context, and your safety risk assessment, as the MITRE rubric for medical devices recommends.
Are cybersecurity patches reportable to the FDA?
Often not. The FDA's 2016 postmarket guidance treats updates made only to strengthen security, without uncontrolled patient risk, as generally not reportable under 21 CFR Part 806. Fixes for uncontrolled risks may be reportable unless specific conditions are met, such as customer notice within 30 days, a fix within 60 days, and ISAO participation.
What if a patch cannot be released quickly?
Use compensating controls while the fix is built and verified. Examples include disabling an unused service, segmentation guidance for hospitals, or a configuration change. Tell customers what to do, track the control, and confirm the permanent fix ships. Document why the delay is acceptable under your risk method.
CTA
Need a clear, defensible way to decide when to patch? We help medical device manufacturers triage CVEs, set risk-based timelines, and document decisions. If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. Schedule a discovery session.
About the author
Christian Espinosa, MBA · Founder & CEO, Blue Goat Cyber
U.S. Air Force Academy graduate and veteran with 30+ years in cybersecurity. Founded Alpine Security in 2014 (acquired 2020), then Blue Goat Cyber in 2022. Blue Goat track record: 275+ FDA submissions supported, zero cybersecurity rejections. Author of three books including The Smartest Person in the Room. Ironman triathlete and mountaineer.