Medical Device Cybersecurity: What Providers Need to Know About IoT/IoMT Risk

Many years ago, a hospital’s network perimeter was made up of desktops, servers, and a handful of clinical workstations. Today, that perimeter runs through infusion pumps, imaging systems, wireless patient monitors, smart beds, and a growing list of connected devices that never existed in a traditional IT inventory. This is the Internet of Medical Things, or IoMT, and it has quietly become one of the largest unmanaged risk categories in healthcare. For providers, understanding this risk is no longer a technical footnote. It’s a leadership issue with direct consequences for patient safety, operational continuity, and the bottom line.

What makes this moment different from past IT security cycles is scale and speed. Connected devices are being deployed faster than most organizations can inventory them, let alone secure them. A single hospital floor might include monitors from one manufacturer, pumps from another, and a handful of remote diagnostic tools installed by a vendor’s field technician without IT ever being looped in. Each of those devices has its own software, its own update cycle, and its own way of talking to the network. Multiply that across a health system with dozens of facilities, and the result is an attack surface that’s difficult to even fully see, much less control. That visibility gap is where this conversation has to start.

Why medical device security is a different problem

Most IT leaders already run mature programs for laptops, servers, and cloud workloads. Medical devices don’t fit neatly into that playbook. Many were built to last a decade or more in the field, run on outdated or unsupported operating systems, and can’t simply be patched the way a laptop can. Taking a device offline for an update isn’t a routine maintenance window when that device is monitoring a patient’s heart rhythm or delivering medication in real time. Security teams end up managing risk on hardware they can’t fully control, on a timeline set by clinical operations rather than IT.

That mismatch is exactly what attackers count on. A connected infusion pump or imaging system doesn’t need to be the final target to be valuable. It’s often the easiest way in, a foothold that leads to the electronic health record, the billing system, or the broader network.

There’s also an organizational dimension that makes this harder than a typical IT initiative. Medical devices sit at the intersection of clinical engineering, procurement, IT, and the vendors who manufacture and service them. Each group tends to own a piece of the puzzle without anyone owning the whole picture. Clinical engineering may track a device’s maintenance schedule without visibility into its network behavior. IT may see the network traffic without knowing what the device actually does at the bedside. Procurement may sign a purchase order for new equipment without a security review ever entering the conversation. Closing that gap requires structure, not just better tools.

Where the risk actually lives

IoMT risk isn’t evenly spread across an organization. It tends to concentrate in a few predictable places:

• Aging, unpatched hardware. A meaningful portion of medical devices in active use are past end of life, meaning the manufacturer no longer issues security updates even for known flaws. These devices often can’t be retired quickly because replacing them means a capital outlay that competes with other clinical priorities.
• Flat, unsegmented networks. When clinical devices sit on the same network segment as administrative systems, a single compromised device can become a path to everything else. Segmentation sounds like a basic control, but retrofitting it into a live clinical environment without disrupting care takes careful planning.
• Shadow devices. Equipment purchased by a department, a clinic, or a vendor without IT’s visibility rarely makes it into a central asset inventory, which means it also rarely gets patched, monitored, or included in incident response planning. In many organizations, this “unknown inventory” problem is the single biggest blind spot, and it’s precisely the gap the pending HIPAA Security Rule update (more on that below) is designed to force organizations to close.
• Third-party and supply chain exposure. Device manufacturers, remote monitoring vendors, and maintenance contractors all have some form of access to clinical systems, and a weakness at any one of them can cascade into a provider’s environment. Remote access tools used for maintenance are a particularly common entry point, since they’re built for convenience first and security second.
• Default and weak credentials. Many devices ship with factory-set logins that are never changed, an old problem that remains one of the most common ways attackers gain initial access. Clinical staff are focused on patient care, not credential hygiene, and devices rarely prompt them to change defaults the way consumer software does.
• Limited monitoring at the device level. Traditional endpoint security tools weren’t built for medical devices, many of which can’t run standard security agents without risking regulatory recertification. That leaves security teams reliant on network-level visibility alone, which can miss device-specific anomalies.

None of these risks are exotic. They’re variations on problems IT has managed for years elsewhere in the enterprise. What’s different in healthcare is the stakes attached to getting them wrong, and the operational constraints that make the usual fixes harder to apply.

The business case, beyond compliance

It’s tempting to file medical device security under regulatory obligation and move on. That undersells what’s actually at stake. Research examining hospital ransomware attacks has repeatedly linked them to worse patient outcomes, including care delays and disruption to the imaging, lab, and records systems that clinicians depend on for time-sensitive decisions. The disruption doesn’t stay contained to the affected facility, either: when a hospital diverts ambulances or postpones procedures, nearby facilities absorb the overflow, so a single compromised network can strain an entire regional care corridor well beyond the walls where the breach occurred.

Then there’s the financial and reputational picture. Healthcare has long ranked among the costliest industries for data breaches, and breaches there also tend to take longer to detect and contain than in most other sectors, in part because of how much legacy and hard-to-patch hardware is involved. That cost doesn’t account for the harder-to-quantify damage to patient trust, referral relationships, and payer negotiations. Regulators have also raised the bar. The FDA’s current cybersecurity guidance asks device makers to submit a software bill of materials, build devices to be secure by design, maintain a coordinated vulnerability disclosure process, and manage security across a device’s full lifecycle rather than treating it as a one-time premarket checkbox. On the provider side, HHS has proposed a significant overhaul of the HIPAA Security Rule that would convert today’s flexible, “addressable” safeguards, like encryption, multi-factor authentication, network segmentation, and a current asset inventory, into explicit requirements. That rulemaking is still in progress and its timeline has already shifted, but the direction is clear, and regulators continue to actively enforce the existing rule in the meantime.

Framed this way, medical device security sits alongside supply chain resilience and clinical quality as a core operational risk, one that belongs on the same board agenda as financial performance and patient outcomes. It’s also a competitive issue. As patients and payers grow more attentive to how organizations protect sensitive data, a provider’s security posture is increasingly part of its reputation, not a background operational detail. Boards that treat this as purely an IT line item are underestimating how directly it touches the organization’s ability to deliver care and retain trust.

A practical framework for reducing IoMT risk

None of this requires reinventing security from scratch. It requires adapting well-understood principles to the realities of a clinical environment, and sequencing the work so that the highest-risk gaps close first.

What’s changing the picture going forward

Two trends are reshaping this risk landscape in ways worth watching closely. The first is the growing use of AI-enabled and remotely monitored devices, from algorithm-assisted diagnostic tools to at-home monitoring equipment that feeds data back into the health system. These devices extend the network perimeter well beyond hospital walls and into patients’ homes, which raises new questions about how data in transit is protected and how a device’s software updates are validated before they’re trusted.

The second is regulatory momentum, moving on two fronts at once. Manufacturers are increasingly expected to build security into the design process under current FDA guidance rather than bolt it on afterward, with concrete deliverables like software bills of materials and documented threat models attached to premarket submissions. Providers, meanwhile, are watching a proposed overhaul of the HIPAA Security Rule that would convert today’s flexible, “addressable” safeguards into specific, auditable requirements covering authentication, encryption, network segmentation, asset inventory, and ongoing security testing. That rule’s path to finalization has already shifted and may shift again, but providers that wait for a firm deadline before building these capabilities will be starting from behind. The conversation with manufacturers needs to start earlier, ideally during procurement, rather than after a device is already on the network.

Questions worth bringing to your next security review

1. Do we have a complete, current inventory of every connected device on our network, including ones brought in outside standard procurement?
2. Which of our clinical devices are end-of-life or running unsupported software, and what’s our plan for each?
3. Are clinical device networks segmented from administrative systems, and when was that segmentation last tested?
4. What security commitments, including SBOMs and vulnerability disclosure policies, do we require from device manufacturers and remote monitoring vendors before signing a contract?
5. Who is accountable, by name or by role, for medical device security across clinical engineering, IT, and procurement?
6. If a connected device were compromised tomorrow, how quickly could we detect it, and what’s our plan to keep patient care running while we respond?

---

IoMT devices aren’t going away, and they shouldn’t. They’re central to how modern care gets delivered. The organizations that manage this risk well aren’t the ones with the fewest connected devices; they’re the ones that have made visibility, segmentation, and vendor accountability part of how they operate, not a project that finishes and gets shelved. For providers, that shift in mindset, from a one-time compliance exercise to an ongoing operating discipline, is what turns medical device cybersecurity from a looming liability into a manageable, well-understood part of running a modern health system.