In February 2026, a cyberattack on the University of Mississippi Medical Center didn’t just encrypt files or disrupt billing systems. It closed clinics across the state. Chemotherapy appointments were delayed. Cancer patients — people whose treatment schedules are measured in weeks, not months — were told to wait.
That incident is not an outlier. It is a data point in a trend that has been building for years and has now reached a scale that demands serious attention from every healthcare organization that operates connected medical equipment.
New data published this month paints a stark picture: 22% of healthcare organizations have experienced cyberattacks that directly impacted medical devices. Of those incidents, three-quarters disrupted patient care. In 24% of cases, the disruption was severe enough to require transferring patients to other facilities.
And the exposure is growing. Over 7 million Internet of Medical Things (IoMT) devices are projected to be deployed in smart hospitals globally by the end of 2026 — more than double the 2021 figure. Every one of those devices is a networked endpoint. Every one runs firmware. Many were designed in an era when network connectivity was an afterthought, and security was not a design requirement at all.
The Internet of Medical Things: What’s Actually Connected
When clinicians and hospital administrators talk about “connected medical devices,” the category is broader than most people realize.
Bedside monitoring equipment — cardiac monitors, pulse oximeters, vital signs monitors — increasingly connect to electronic health record (EHR) systems via hospital networks to enable automatic data documentation. These devices run embedded operating systems, many of which are legacy versions of Windows CE, Windows XP, or proprietary real-time operating systems that cannot be patched with modern security updates.
Infusion pumps — the devices that deliver IV medications at precisely controlled rates — have been a persistent source of security concern for a decade. Networked infusion pumps allow pharmacy and nursing staff to push drug libraries and dosing protocols remotely, but the same connectivity that enables this workflow creates attack surface.
Imaging equipment — MRI scanners, CT scanners, X-ray systems, and ultrasound machines — are sophisticated computing systems that have moved from standalone operation to full network integration. Many run Windows operating systems and require network connectivity for PACS (picture archiving and communication systems) integration.
Building systems within clinical facilities — HVAC systems that maintain operating room pressurization and sterility, pharmaceutical refrigeration systems, nurse call systems, and clinical communications platforms all increasingly have network connectivity and, in many cases, IoT-enabled remote monitoring.
Wearable and remote monitoring devices — consumer-grade smartwatches and purpose-built remote patient monitoring devices that transmit physiological data to clinical teams.
The aggregate result is a hospital network that looks nothing like a corporate IT environment. It contains hundreds or thousands of device types, from dozens of manufacturers, running diverse operating systems and firmware versions, with varying degrees of patchability, managed by a mixture of clinical engineering, IT, and vendor teams who often operate in silos.
Why Medical Devices Are Such Hard Security Problems
The security challenge in healthcare IoMT is not primarily a matter of awareness or budget — though both are real constraints. It’s a matter of structural tensions that have no easy resolution.
Clinical availability versus security patching. A cardiac monitor in a cardiac care unit cannot simply be taken offline for a firmware update the way a corporate laptop can. Scheduling downtime for medical equipment requires clinical coordination, may require vendor involvement, and in some cases simply isn’t possible without disrupting patient care. The result is that many medical devices run firmware versions that are years behind current security patches.
Regulatory approval and configuration lock. Medical devices are subject to FDA clearance or approval, which is tied to specific hardware and software configurations. Unauthorized modifications — including some firmware updates — can void regulatory clearance and create liability issues. This creates a situation where the path of least legal risk is to not patch, even when patches are available.
Legacy equipment lifecycles. Medical equipment is expensive and has long operational lifespans. It is not unusual for hospital networks to include imaging equipment or monitoring devices that are ten or fifteen years old — designed before cybersecurity was a clinical engineering consideration.
Vendor access requirements. Many medical devices require periodic vendor access for maintenance, calibration, and software updates. This access is often provided through persistent remote access connections that were established at installation and rarely reviewed. Each such connection is a potential attack vector.
Insufficient asset visibility. Many healthcare organizations cannot accurately inventory what medical devices are connected to their networks. Without visibility into what’s connected, you cannot assess risk, prioritize patching, or detect anomalous behavior.
The Ransomware Groups Targeting Healthcare IoMT
Ransomware operators have recognized that healthcare’s combination of operational urgency, complex device environments, and high patient impact creates exceptional leverage for extortion. The result has been a sustained escalation in healthcare targeting.
293 ransomware attacks were recorded against hospitals and direct care providers in 2025 — a 30% increase from the prior year. In 2026, the pace has continued.
Several ransomware groups have developed specific playbooks for healthcare:
BlackCat/ALPHV (prior to its disruption) developed healthcare-specific extortion tactics that included threatening to release patient data and contacting regulatory bodies — amplifying pressure beyond just the operational disruption.
LockBit (despite law enforcement action against its infrastructure) continues to have affiliate operations targeting healthcare, with affiliates using remaining tooling against hospital systems.
RansomHub, which emerged as a successor platform for affiliates displaced by LockBit and BlackCat disruptions, has explicitly included healthcare targets and has been observed in incidents affecting clinical operations.
Rhysida has been linked to several high-profile healthcare attacks, including the Lurie Children’s Hospital incident, and has demonstrated willingness to release sensitive patient data including pediatric health records.
89% of healthcare organizations have the top 1% of riskiest IoMT devices — those with known exploitable vulnerabilities (KEVs) linked to active ransomware campaigns and insecure internet connections — on their networks. This statistic, from Claroty’s healthcare security research, means that virtually every hospital has at least some devices that ransomware operators know how to exploit.
The University of Mississippi Medical Center Incident
The February 2026 attack on UMMC illustrates the real-world consequences when healthcare IoMT security fails.
UMMC is the only Level I trauma center in Mississippi — the highest designation for trauma care capability. An attack that disrupts its operations doesn’t just affect the hospital. It affects every serious trauma patient in the state who would otherwise be transported there.
The specific mechanism of the attack has not been publicly disclosed, but the pattern is consistent with ransomware intrusions that begin in administrative IT systems and pivot to clinical networks through insufficiently segmented infrastructure. The impact included:
- Clinic closures across the state as UMMC-affiliated outpatient facilities lost access to clinical systems
- Delayed chemotherapy appointments for oncology patients on time-sensitive treatment protocols
- Slowdowns at treatment centers dependent on shared clinical systems
The UMMC incident is not unique. It is one of hundreds of similar incidents affecting healthcare organizations in the past two years. What makes it worth examining is the specificity of patient impact — not just disrupted billing or delayed administrative functions, but delayed cancer treatment.
New Regulatory Standards: The FDD IoMT Framework
In direct response to the escalating threat to medical devices, the Foundation for Defense of Democracies published new standards for IoMT security on April 6, 2026.
The FDD framework focuses on several areas:
Pre-market security requirements. Medical device manufacturers should embed security controls during device design — not as an afterthought. This includes secure boot, cryptographic firmware signing, network authentication, and the ability to receive security updates throughout the device lifecycle.
Software Bill of Materials (SBOM) for medical devices. The FDA has been pushing for SBOMs — comprehensive lists of all software components in a device, enabling healthcare organizations to assess their exposure to specific vulnerabilities when new CVEs are disclosed. The FDD framework reinforces and extends this requirement.
Post-market security support commitments. Manufacturers should commit to providing security updates for a defined support period aligned with the device’s expected clinical lifecycle — not just the regulatory approval period.
Healthcare organization security requirements. The framework establishes baseline expectations for how healthcare organizations should manage IoMT security: asset inventory, network segmentation, patch management processes, and incident response planning.
The FDD standards are not yet law. But they reflect the direction of FDA regulatory intent, and healthcare organizations and device manufacturers who build their security programs around these expectations will be better positioned when regulatory requirements catch up.
What Healthcare Security Leaders Should Do
Immediate priorities:
Build a complete IoMT asset inventory. You cannot protect what you cannot see. Dedicated healthcare IoT security platforms (Medigate, Claroty Healthcare, Armis Medical) can passively discover and classify medical devices on your network without interfering with clinical operations. Start here.
Segment clinical networks from administrative IT. The most common ransomware intrusion path into clinical systems is through administrative IT networks — email, workstations, and corporate applications — that are insufficiently separated from clinical device networks. Network segmentation with proper firewall controls is the highest-leverage structural improvement most healthcare organizations can make.
Identify your highest-risk devices. Using CISA’s Known Exploited Vulnerabilities catalog and healthcare-specific threat intelligence, identify which devices in your inventory have known, actively exploited vulnerabilities. These require immediate attention — whether that means patching, network isolation, or compensating controls.
Implement vendor access management. Audit all persistent remote access connections maintained by medical device vendors. Implement time-limited, authenticated, logged access rather than always-on connections. Vendors should access specific devices — not broad network segments.
Develop a medical device incident response plan. A general IT incident response plan is insufficient for healthcare. You need specific procedures for what happens when a medical device is compromised — who makes the clinical decision to disconnect it, what the clinical workaround is, how you notify patients affected by care delays, and how you coordinate with the FBI and HHS when required.
Train clinical staff on IoMT security hygiene. Nurses, physicians, and clinical engineers who interact with connected devices daily are part of the security posture. Training should cover recognizing unusual device behavior, proper network connection of personal devices, and reporting procedures for suspected incidents.
The Patient Safety Dimension
Healthcare cybersecurity is unique among all the sectors where IoT security matters because the ultimate consequence of failure is not financial or operational — it is harm to patients.
Delayed chemotherapy, disrupted cardiac monitoring, tampered infusion pump dosing — these are not abstract risks. They are documented incident categories with documented patient impacts. The connection between a ransomware group encrypting hospital systems and a cancer patient missing a treatment appointment is real, direct, and increasingly common.
This is why healthcare IoMT security deserves more than the “IT department problem” treatment it often receives. It belongs in the boardroom conversation at healthcare organizations — alongside clinical quality metrics and financial performance — because it directly affects both.
The 7 million connected medical devices being deployed in smart hospitals are not primarily an IT asset. They are clinical tools. And their security is a clinical responsibility.
Data in this article draws on Claroty healthcare security research, Armis IoMT threat intelligence, the Foundation for Defense of Democracies IoMT standards publication (April 6, 2026), and reporting on the University of Mississippi Medical Center incident. Patient privacy has been maintained; no individually identifiable patient information is included.
