IoMT Vulnerability Management: When Patching Could Harm a Patient

A vulnerability scanner flags a critical remote code execution flaw on an infusion pump delivering chemotherapy to a 6-year-old in a pediatric oncology ward. CVSS 9.8. CISA KEV-listed. Ransomware-associated. Every signal in your vulnerability management program screams "patch immediately." But this device cannot be rebooted without interrupting a 72-hour medication protocol, the manufacturer has not released a validated firmware update, and the last time someone applied an unapproved patch to a device in this product line, it bricked the pump mid-infusion at a hospital in Michigan.

Welcome to IoMT vulnerability management, where the standard playbook does not apply and the consequences of both action and inaction can directly harm patients.

Why This Matters Now

Three converging pressures have elevated IoMT security from a niche concern to a board-level risk:

Ransomware targeting healthcare has intensified. The Change Healthcare attack in February 2024 disrupted claims processing for months. Attacks increasingly pivot through medical devices because they run outdated operating systems, lack endpoint detection, and sit on flat networks.

FDA cybersecurity requirements have teeth. Section 524B of the FD&C Act (effective March 2023) requires manufacturers to submit cybersecurity plans --- including SBOM delivery and coordinated vulnerability disclosure --- as a condition of premarket clearance.

The attack surface is larger than anyone admits. A 500-bed hospital typically has 10,000-15,000 connected devices, of which clinical engineering formally manages perhaps 60-70%. The rest constitute shadow IoMT that appears in no asset inventory.

The question is no longer whether healthcare organizations need IoMT vulnerability management. It is whether they can build programs that account for clinical risk without waiting for a patient safety incident to force the issue.

The IoMT Landscape: Broader Than You Think

When security teams think "medical devices," infusion pumps and patient monitors come to mind first. The reality encompasses:

Infusion pumps and IV controllers --- the most numerous connected devices in most hospitals, often thousands per facility
Patient monitors --- bedside vitals, telemetry, fetal monitors, pulse oximeters
Imaging systems --- MRI, CT, X-ray, ultrasound, PACS (Picture Archiving and Communication Systems)
Laboratory equipment --- analyzers, centrifuges, sequencers, all increasingly networked
Surgical robots --- high-precision systems where latency or malfunction is immediately life-threatening
Connected implants --- pacemakers, insulin pumps, neurostimulators with wireless management interfaces
Building management --- HVAC, pneumatic tube delivery, nurse call systems, medical gas monitoring

That last category catches people off guard. The HVAC system controlling operating room pressure differentials is absolutely a clinical device. If positive pressure fails in a surgical suite, infection risk climbs immediately. These systems sit at the intersection of OT and clinical operations, rarely managed by IT security, and almost never scanned.

Why Standard Vulnerability Management Fails Here

Standard vulnerability management assumes you can patch. IoMT breaks that assumption in five ways that fundamentally alter the discipline.

Patching Requires Clinical Validation --- and Sometimes FDA Clearance

When a device manufacturer releases a software update, the hospital cannot simply apply it. The update may require clinical validation to ensure it does not alter device behavior in ways affecting patient safety. In some cases, a patch modifying the device's intended function may require new FDA 510(k) clearance. A known vulnerability can remain unpatched for months or years --- not due to negligence, but regulatory reality.

Downtime Means Patient Harm, Not Revenue Loss

Taking a server offline for patching costs money. Taking an infusion pump offline during critical medication administration can cost a life. Remediation windows must coordinate with clinical staff, schedule around patient needs, and sometimes delay because backup devices are not available to maintain care during the patch cycle.

Device Lifecycles Outlast Their Software by a Decade

Enterprise IT refreshes hardware every 3-5 years. Medical devices --- especially capital-intensive imaging systems --- are designed for 10-15 year lifecycles. An MRI machine that cost $3 million in 2015 is not getting replaced because its embedded Windows 7 reached end-of-life. These devices routinely run operating systems that will never receive another security update.

Manufacturer Dependency Is the Norm

Unlike IT assets where the organization controls the software stack, medical devices are typically closed systems. Hospitals often cannot patch independently --- firmware updates must come from the manufacturer, on the manufacturer's timeline, with an on-site field service engineer. Some vendor contracts explicitly void the warranty if the hospital modifies device software in any way.

Network Segmentation Becomes the Primary Control

When you cannot patch, you must isolate. Network microsegmentation --- restricting what a device can communicate with, on which ports, using which protocols --- becomes the single most important security control. For many IoMT devices, it is the only control the hospital actually owns.

Clinical Risk Scoring: Beyond CVSS

Here is where most vulnerability management programs fail in healthcare: they apply the same severity scoring to medical devices that they use for workstations and servers.

A CVSS 9.8 remote code execution on an infusion pump and a CVSS 9.8 on a developer workstation are not equivalent risks. The pump vulnerability could enable dosage manipulation. The workstation vulnerability could lead to data theft. Both are serious. One is immediately life-threatening.

Clinical risk scoring must factor in dimensions CVSS was never designed to capture:

Patient safety impact --- Could exploitation directly harm or kill a patient?
Care delivery impact --- Would compromise or downtime disrupt critical care workflows?
PHI exposure --- Does the device store or display protected health information, triggering HIPAA breach obligations?
Compensating control effectiveness --- Is the device segmented? Is anomaly detection in place? Can physical access be restricted?
Device criticality classification --- Life-sustaining, life-supporting, or administrative?

Organizations that layer clinical risk on top of CVSS --- rather than replacing it --- make materially better remediation decisions. A CVSS 6.5 on a networked ventilator with no segmentation and direct patient contact may warrant faster action than a CVSS 9.8 on a well-segmented lab analyzer with no patient-facing function.

Compensating Controls for Unpatchable Devices

When a device cannot be patched --- and in IoMT, this is the rule, not the exception --- compensating controls become the entire security program for that asset.

Network microsegmentation is the foundation. Every IoMT device belongs on a dedicated VLAN with firewall rules restricting traffic to only the specific endpoints and protocols the device requires. An infusion pump needs to talk to its management server and the pharmacy system. It does not need internet access, email server connectivity, or radiology PACS access.

Application whitelisting prevents unauthorized code execution on devices that support it. Not all embedded systems have the capability, but where available, it is one of the most effective controls against exploitation.

Behavioral monitoring provides visibility into device activity. Medical devices have highly predictable network traffic patterns. An infusion pump initiating DNS lookups to unknown domains or scanning the network is anomalous behavior that detection systems should flag immediately.

Physical access controls matter more for IoMT than IT. Many exploits require physical proximity --- USB, console, or wireless management interfaces. Locked equipment rooms and staff-only areas eliminate entire attack vectors.

Procurement-stage security requirements are the most effective long-term control. Manufacturer patch SLAs, end-of-life commitments, SBOM delivery, and coordinated vulnerability disclosure timelines should be contractual requirements negotiated before the purchase order is signed --- not discovered as gaps after a vulnerability is disclosed.

The PHI Dimension

Medical devices that process or display patient data add HIPAA Security Rule requirements to every vulnerability management decision. An imaging system storing diagnostic images with patient identifiers, a bedside monitor displaying vitals linked to an EHR record, a lab analyzer processing samples tied to patient accounts --- all are HIPAA-covered assets.

A vulnerability on these devices is not just a cybersecurity finding. It is a potential HIPAA violation triggering specific breach notification, documentation, and remediation obligations. Security teams must track which IoMT assets handle PHI and ensure vulnerability management workflows account for the regulatory overlay.

MDS2: The Manufacturer Security Disclosure

The Manufacturer Disclosure Statement for Medical Device Security (MDS2) is a standardized questionnaire documenting device security characteristics: encryption, authentication, audit logging, update processes, and network requirements. MDS2 forms tell security teams what controls the device supports and how it can be updated. Without this data, teams guess --- and guessing wrong means over-investing in controls the device handles natively or missing gaps it cannot cover.

Every procurement should require a completed MDS2 before approval. Every vulnerability management program should reference MDS2 when assessing compensating controls.

Asset Inventory: The Problem Before the Problem

You cannot manage vulnerabilities on devices you do not know exist. Studies consistently find that hospitals undercount connected devices by 30-50%. Shadow IoMT --- devices connected by clinical staff without IT involvement --- is endemic. A physician plugs in a personal ultrasound probe. A nurse connects a Bluetooth thermometer. Facilities installs a smart HVAC controller. None go through procurement. None appear in inventory. All become attack surface.

Passive network discovery --- monitoring traffic to identify devices by communication patterns, MAC addresses, and protocol fingerprints --- is the standard approach. Active scanning is often unsuitable because many medical devices respond poorly to scan traffic, sometimes crashing or rebooting when probed. Getting to a complete, continuously updated IoMT inventory is step zero for everything else.

Bridging the IT-Biomed Divide

In most hospitals, medical devices are managed by clinical engineering (biomed), not IT. These teams report through different organizational structures, use different terminology, and optimize for different outcomes. Clinical engineering optimizes for uptime, clinical accuracy, and patient safety. IT security optimizes for vulnerability remediation, compliance posture, and threat mitigation.

Both are right. Neither has the full picture alone.

Effective IoMT vulnerability management requires formal collaboration: shared inventories, joint risk assessments, coordinated patch windows, and cross-training. Security analysts need to understand why a device cannot simply be taken offline. Biomed engineers need to understand why an unpatched device on a flat network is organizational risk.

Organizations that do this well establish a joint medical device security committee. Organizations that do not end up with security teams that cannot patch and biomed teams that do not know they should.

The Regulatory Crosswalk

IoMT vulnerability management maps to multiple frameworks simultaneously:

FDA premarket/postmarket guidance --- SBOM requirements under Section 524B, coordinated disclosure
HIPAA Security Rule --- risk analysis for devices handling electronic PHI
NIST CSF --- overarching risk management structure
IEC 62443 --- industrial automation security applied to medical and building management
AAMI TIR57 --- medical device security risk management principles

A single remediation decision may need to satisfy FDA postmarket requirements, demonstrate HIPAA risk analysis, align with NIST CSF subcategories, and reference IEC 62443 zone models. This crosswalk is an audit expectation, not optional.

The Contrarian Take: Patching Is Overrated in IoMT

Here is the position that infuriates traditional vulnerability management teams: for the majority of IoMT assets, patching should not be the primary remediation strategy. It should be the last resort.

The reasons are practical, not philosophical. Patches for medical devices arrive months late (if ever), require scheduled downtime coordinated with clinical operations, may need FDA re-clearance, and create regression risk on devices where regression means patient harm. Compensating controls --- segmentation, monitoring, access restriction --- can be deployed immediately, do not require manufacturer involvement, do not create clinical downtime, and do not carry regression risk.

The traditional vulnerability management metric "mean time to patch" is the wrong measure for IoMT. The right measure is "mean time to effective risk reduction" --- which might mean segmenting a device within 4 hours of disclosure rather than waiting 6 months for a manufacturer-validated patch that requires a 3-hour downtime window and an on-site field engineer.

Key Takeaways

IoMT vulnerability management is a distinct discipline, not a bolt-on to IT vulnerability management.

Clinical risk scoring must layer patient safety, care delivery impact, and PHI exposure on top of CVSS.

For most IoMT assets, compensating controls (segmentation, monitoring) are more practical than patching.

Asset inventory is step zero --- hospitals routinely undercount connected devices by 30-50%.

The IT-biomed collaboration model determines program success more than any technical control.

FDA Section 524B now requires manufacturers to deliver SBOMs and maintain coordinated vulnerability disclosure.

Frequently Asked Questions

Can we scan medical devices the same way we scan IT assets?

No. Active scanning can crash or reboot medical devices that were not designed to handle scan traffic. Passive network discovery --- monitoring traffic patterns without sending probes --- is the standard approach for IoMT asset identification. Some newer devices tolerate credentialed, low-impact scanning, but this must be validated with the manufacturer and tested in a non-clinical environment first.

What do we do when a manufacturer refuses to patch a known vulnerability?

Document the refusal, assess compensating controls (segmentation, monitoring, physical access restriction), and factor the manufacturer's security posture into future procurement decisions. If the device handles PHI, document the HIPAA risk analysis showing compensating controls reduce risk to acceptable levels. Use the vulnerability as contract leverage during renewal --- manufacturers that refuse to patch lose renewal business to competitors that do.

How does FDA Section 524B change the manufacturer relationship?

Section 524B (effective March 2023) requires manufacturers to submit cybersecurity plans as a condition of premarket clearance, including SBOM delivery, coordinated vulnerability disclosure processes, and plans for addressing vulnerabilities throughout the device lifecycle. This gives healthcare organizations leverage: devices cleared after March 2023 should come with SBOMs and defined patch timelines. For legacy devices pre-dating 524B, the relationship remains manufacturer-dependent.

Should IoMT vulnerabilities be tracked in the same system as IT vulnerabilities?

Yes, but with extended metadata. The vulnerability record needs fields for clinical risk classification, device criticality tier, manufacturer patch status, compensating control status, and clinical validation requirements. Many organizations use a dedicated IoMT security platform that feeds findings into the enterprise vulnerability management system with the additional clinical context attached.

What is the relationship between IoMT security and CISA KEV?

KEV entries affecting medical device vendors (Citrix, Fortinet, Microsoft for embedded Windows) create immediate urgency because IoMT remediation cycles are so long. When a vendor's product appears in KEV, the clock starts on a remediation timeline that may be structurally impossible to meet through patching alone. This is precisely why compensating controls must be deployable within hours --- KEV gives you 14 days (federal) or 48 hours (best practice), but medical device patching often takes months.

How Advisedly Helps

Advisedly helps healthcare organizations build vulnerability management programs that account for clinical risk, regulatory crosswalks, and the operational reality of medical device environments. The platform maps IoMT findings against FDA postmarket guidance, HIPAA Security Rule requirements, and NIST CSF simultaneously, with clinical risk scoring that layers patient safety dimensions on top of traditional CVSS severity. Compensating control tracking ensures that unpatchable devices are not just flagged --- they are documented with the controls that reduce effective risk, satisfying both security teams and compliance auditors. Whether standing up an IoMT program from scratch or integrating medical device coverage into an existing workflow, Advisedly consolidates what would otherwise require 80+ enterprise tools into a single platform purpose-built for complex regulatory environments.

Ready to build IoMT vulnerability management that accounts for clinical reality? Contact us at begin@advisedly.ai to start the conversation.