Unpatched medical devices can turn a cyber issue into a patient-care problem fast. In many hospitals, connected devices still run old software, weak login controls, or unsupported systems. That can lead to missed alarms, wrong readings, delayed scans, therapy changes, or device outages during care.
Here’s the short version:
- Many devices are still exposed: 52% of infusion pumps had a critical OS flaw first found in 2019, and 83% of imaging devices run on outdated software.
- The care impact is direct: One study found 44.4% of ransomware attacks on healthcare groups disrupted care delivery.
- Patching is hard: Device updates often need vendor review, testing, downtime planning, and change control.
- One weak device can affect more systems: Flat hospital networks can let malware move from one device to EHRs, lab systems, pharmacy tools, and workstations.
- Hospitals need a clear plan: Keep a device inventory, rank devices by patient-care risk, isolate exposed devices, use extra controls when patches are delayed, and link all of that to downtime and incident plans.
What I take from this is simple: patching medical devices is not just an IT task. It should be treated as a patient safety process with shared ownership across IT, HTM, security, vendors, and clinical teams.
To cut risk, I’d focus on three things first:
- Know every connected device
- Reduce exposure when a patch is delayed or missing
- Plan for outages before they happen
That’s the core message of the article, and it’s where the biggest risk reduction starts.
Unpatched Medical Devices: Key Cybersecurity & Patient Safety Statistics
The Problem: How Unpatched Devices Create Risk in Care Delivery
Common Vulnerabilities in Connected Medical Devices
Unpatched medical devices often expose the same weak spots: outdated operating systems, weak or default passwords, hard-coded credentials, unencrypted network traffic, and insecure remote access channels.[10][1][14] In some cases, there isn't even a supported update path, which means fixes simply can't be deployed.[7][9] That becomes a patient care issue fast when a flaw can change therapy, suppress alarms, or block access to care data.
The scale of the problem is hard to ignore. Claroty found that 23% of medical devices have at least one known exploited vulnerability, and 63% of vulnerabilities in CISA's Known Exploited Vulnerabilities catalog are present on healthcare networks.[3] Armis also reported that 1 in 5 connected medical devices run on unsupported operating systems, including 32% of medication dispensing systems.[2]
These gaps line up directly with the FDA's cybersecurity objectives: safety, confidentiality, integrity, and device availability.[5][7][9] If communications aren't encrypted, patient data and therapy commands may be exposed. If authentication is weak, unauthorized users may be able to issue commands. And when patching isn't an option, known flaws can stay open for years.[7][6][8]
Safety-Critical Device Scenarios to Know
This isn't just an IT headache. At the bedside, the risk changes depending on the device.
| Device Type | Vulnerability Path | Potential Clinical Impact |
|---|---|---|
| IV infusion pumps | Legacy firmware, hard-coded passwords | Altered infusion rates, drug overdose or underdose, missed therapy[10][1] |
| Insulin pumps | Intercepted or spoofed wireless communications | Dosage manipulation, hypoglycemia or hyperglycemia risk[11][1] |
| Implantable cardiac devices | Insecure wireless protocols, unpatched firmware | Altered pacing thresholds, shock delivery changes, silent loss of monitoring[14][12] |
| Bedside monitors and ventilators | Service interruption, outdated OS | Forced device shutdown, false alarms or no alarms, delayed clinical response[12][13] |
The FBI has specifically cited insulin pumps and implantable cardioverter-defibrillators as devices where malicious actors could cause inaccurate readings or trigger overdoses by manipulating settings remotely.[1] FDA safety communications have described vulnerabilities in St. Jude Medical implantable cardiac devices that allowed unauthorized remote access - potentially enabling attackers to alter therapy parameters or interfere with telemetry.[14][12] Cynerio's research found that 73% of IV pumps have a vulnerability that could jeopardize patient safety, data confidentiality, or service availability if exploited.[19]
How One Vulnerable Device Can Affect an Entire Clinical System
On a shared hospital network, one exposed device rarely stays "just one device." A single unpatched asset can open the door to the wider clinical network. Many IoMT devices sit on flat or lightly segmented networks, so once an attacker gets in through one system, they may scan nearby systems and move laterally to EHR servers, pharmacy dispensing cabinets, radiology workstations, or lab systems.[15][1]
Forescout data shows that 59% of operating systems on medical VLANs are Windows, and 85% of those Windows devices have server message block protocol enabled by default.[18] That's a bad mix. It gives attackers an easier path to move from one machine to another. Once ransomware or remote-control malware spreads from the first device, whole clinical units can go dark. Staff then shift to manual workflows, procedures get delayed, and pressure builds across the unit.[15][13]
When that happens, the impact lands on three groups at once:
- Biomedical engineers must find similar devices and pull them from service.
- IT and security teams must isolate network segments, review logs, and contain the spread.
- Clinical leadership must keep care moving while systems are offline.
Even a suspected compromise can force devices offline for inspection. That eats up time, adds friction during care delivery, and increases the chance of human error when teams are already working under stress.[13][1]
sbb-itb-535baee
O&I Hearing: Examining Cybersecurity Vulnerabilities in Legacy Medical Devices
The Standards: What U.S. Guidance Requires Organizations to Do
These vulnerabilities now sit under clear U.S. cybersecurity guidance. Over time, that guidance has shifted in a pretty direct way: medical device cybersecurity is no longer treated as just an IT box to check. It is tied to patient safety and the quality system itself. That means HDOs need to apply these rules not only to new device purchases, but also to devices already in use.
FDA Expectations for Cybersecurity, SBOMs, and Device Updatability
FDA expects manufacturers to document a cybersecurity risk management plan, secure development practices, and lifecycle patchability.[4][6]
SBOMs are a central part of that setup. FDA expectations call for machine-readable SBOMs that identify software components and include vulnerability information, support status, and end-of-support dates.[6][24][25] For HDOs, that makes it much easier to connect known weak points to devices already deployed across the hospital.
FDA defines updatability and patchability based on how fast a device can receive security fixes.[6] Manufacturers are expected to document:
- supported update channels
- authentication steps
- expected patch timelines
- end-of-support dates[20]
Hospitals should verify update paths, package signing, and patch SLAs for high-severity vulnerabilities. Put simply, these are the standards hospitals should use when judging device risk before a purchase.
Postmarket Vulnerability Management and Coordinated Disclosure
Compliance is the floor, not the finish line. The FDA's postmarket guidance sets a risk-based program for continuously monitoring, assessing, and remediating vulnerabilities in devices already deployed.[21][23][26] The FDA does not require formal reporting for routine security patches, which is meant to cut friction so manufacturers can patch faster.[22][23]
For HDOs, that turns into an ongoing operational duty: monitor manufacturer advisories, ISAC alerts, CISA bulletins, and FDA communications, then validate and deploy patches through change control.[21][23][26] The Health Sector Coordinating Council (HSCC) has pushed this further with model contract language that sets concrete timing expectations - communication within 30 days of a discovered vulnerability and validated, deployable fixes within 60 days.[28][31]
HHS 405(d) Health Industry Cybersecurity Practices (HICP) reinforces the same direction. It names network-connected medical device security and vulnerability management as top governance priorities.[27][29][30] So this isn't just policy on paper. HDOs must turn postmarket vulnerability management into day-to-day practice with collaborative risk operations through policies, device inventories, and risk-based maintenance. That puts inventory and prioritization next in line operationally.
The Solution: Steps to Reduce Risk from Unpatched Devices
Reducing risk comes down to three moves: know what you have, lock down what you can’t patch, and prepare for device incidents before they happen.
Build a Full Medical Device Inventory and Rank Devices by Clinical Risk
You can't protect what you can't inventory. Yet Ponemon research found that only 36% of healthcare delivery organizations say they are effective at knowing where all their medical devices are, and only 35% know when vendor operating systems are end-of-life or out-of-date.[33][34] That’s a serious blind spot. Risk tends to sit in the places no one is tracking closely.
For every connected device, document the basics and the details: device type, model, serial number, firmware and OS version, network location, physical location, owner, support status, end-of-support date, connectivity type, authentication methods, and clinical function. That level of detail helps teams spot which devices are most likely to disrupt care and impact patient safety.
Then layer in clinical criticality. A life-supporting device in the ICU and an ancillary workstation in an outpatient clinic may both be connected, but the stakes are not even close. Rank devices by clinical criticality and patient dependence. That ranking should drive triage, so devices with the highest clinical impact and known vulnerability exposure go to the top of the patching queue.
Use the inventory to do three things well:
- Set patch priorities
- Segment high-risk devices
- Define escalation paths
Apply Risk-Based Patching, Network Segmentation, and Compensating Controls
Patching medical devices is rarely simple. It often means vendor coordination, scheduled downtime, and post-patch testing. When patching is blocked, compensating controls can reduce cybersecurity risk to an acceptable level.[16][32]
Put vulnerable devices on dedicated VLANs so an attacker has less room to move if a device is compromised. Use least-privilege access so devices can communicate only with the systems they need. And if a device supports remote vendor access, protect that access with MFA.
When a patch can’t be deployed right away, these steps can keep the device safe enough to remain in service.
| Control Type | Primary Purpose | Example Actions | Patient Safety Impact |
|---|---|---|---|
| Proactive – Patching | Remove the vulnerability | Coordinate with manufacturer, validate patch, deploy in a maintenance window | Eliminates the exploit path before an incident occurs |
| Proactive – Segmentation | Limit lateral movement | Isolate vulnerable devices on dedicated VLANs, restrict inter-device traffic | Helps prevent one compromised device from affecting the broader clinical network |
| Proactive – Least-Privilege Access | Reduce attack surface | Restrict device communication to required systems only, enforce MFA for remote support | Limits unauthorized access to clinical systems |
| Reactive – Behavioral Monitoring | Detect exploitation early | Use anomaly detection and behavioral alerts on unpatched devices | Shortens time to detection and speeds response |
| Reactive – Compensating Controls | Reduce risk when patching is blocked | Apply vendor-recommended workarounds, increase manual oversight, restrict network access | Maintains acceptable risk until a patch is available |
Some devices simply can’t be patched at all. That’s often the case with older equipment running end-of-life operating systems, which account for roughly 60% of devices in many hospital environments. And because only about 13% of IoMT devices support endpoint security tools such as antivirus,[10] network-level behavioral monitoring becomes the main way to spot trouble early.
Connect Device Risk to Incident Response and Clinical Continuity Planning
Controls on their own aren’t enough. They need to connect to response playbooks and fallback workflows so care can continue during containment.
Inventory and compensating controls won’t help much without a medical-device incident response plan. Escalation paths should be defined ahead of time across security, IT, biomedical engineering (HTM), compliance, and clinical operations.[16][4][17]
For every high-criticality device category, define the backup plan in plain terms:
- Replacement equipment
- Manual fallback workflows
- Conditions that require taking a device offline
That includes categories like infusion pumps, ventilators, and patient monitors. In a Runsafe survey of 605 healthcare executives, 43% reported 1–4 hours of downtime and 19% reported outages longer than 13 hours after device compromise.[35] When that kind of outage hits, a tested backup plan can be the difference between a contained disruption and a patient safety emergency.
Scaling the Response: Centralized Risk Management for Medical Device Security
When device-risk data is scattered across spreadsheets, CMMS tools, tickets, and email threads, things slip through the cracks. Teams miss vulnerabilities. Remediation slows down. And even well-meant controls start to break down once the environment gets bigger.
That’s why scale matters here. Device risk, vendor risk, and remediation status need to live in one shared workflow, not across five different systems.
How Censinet Supports Device and Vendor Risk Coordination
A centralized workflow cuts the lag between finding a vulnerability and taking clinical action. Censinet RiskOps™ gives healthcare organizations one workflow for vendor and device risk management.
When a new medical device vendor is brought on, security teams can send standardized questionnaires that cover:
- patch and update paths
- SBOM availability
- vulnerability disclosure practices
Those responses are scored and stored in one place, which creates an auditable risk profile for each product and device category.
When a vulnerability is disclosed, the vendor profile can show which devices are affected, where they’re deployed, and which controls are already in place. Risk owners can assign corrective action plans to named owners across clinical engineering, IT security, and vendor contacts, with due dates tracked in one shared view.
Censinet’s cybersecurity benchmarking capabilities also let HDOs compare vendors on patch release cadence and vulnerability disclosure timeliness. That data can then feed into purchasing and renewal decisions.
What Better Visibility Means for Patient Safety
A centralized dashboard changes how fast leaders can move. Instead of piecing together updates from multiple teams, they can see which high-risk devices are unpatched, which ones are under compensating controls, and where remediation tasks are overdue.
That kind of visibility helps prevent delayed isolation, missed remediation, and untracked high-risk devices. It also supports faster patch scheduling and more targeted communication to clinical staff about temporary device restrictions.
Centralized tracking improves speed, visibility, and accountability. When risk data is unified, security and clinical leaders can work from the same information without jumping between systems. The result is a more controlled, repeatable process instead of reactive triage.
Conclusion: Treat Patching as a Patient Safety Program
The FDA warns that unpatched vulnerabilities can let unauthorized users access or control devices and potentially cause harm.[4] U.S. regulatory guidance supports structured postmarket vulnerability management and coordinated disclosure, and organizations that treat patching as an optional IT task are out of step with both the threat landscape and compliance expectations.
Treat patching as a patient safety program: maintain an accurate inventory, rank devices by clinical risk, and route remediation through one coordinated workflow. Centralized risk operations shift patching from a scattered IT task into a managed patient-safety process.
FAQs
Why are unpatched medical devices a patient safety risk?
Unpatched medical devices can open the door to cyberattacks that interrupt care and day-to-day operations. If attackers find a weak spot, they may tamper with device behavior, shut down monitors, or change settings on life-critical equipment.
When that happens, care teams may have to fall back on manual workarounds. That can increase the chance of human error and slow treatment when time matters most. A compromised device can also expose sensitive patient data and interfere with healthcare networks.
What should hospitals do when a device can’t be patched?
When a medical device can’t be patched, hospitals should put patient safety first and use compensating controls to cut risk.
That usually means limiting exposure as much as possible while the device stays in service.
- Isolate the device with network segmentation and strict firewall rules
- Use passive network monitoring, rotate access credentials, and apply virtual patching
- Perform a formal risk assessment, document measures, and work with vendors on secure decommissioning or replacement
How can one vulnerable device disrupt other hospital systems?
Many medical devices run on the same clinical networks. If an attacker gets into just one device, that device can become the front door to other hospital systems.
From there, the damage can spread fast. Attackers may disrupt connected equipment, shut down imaging systems, change patient data, or push hospitals into slower, paper-based workflows.
