IoMT (Internet of Medical Things): What It Is, Why It’s a Security Problem, and How to Fix It

Last updated: April 2026

The global IoMT market surpassed $99 billion in 2025 and is projected to exceed $124 billion in 2026, growing at roughly 25% year over year. That growth means more connected infusion pumps, patient monitors, imaging systems, and wearable biosensors sitting on hospital networks every quarter. Most of them cannot run endpoint security agents. Many run operating systems that stopped receiving updates years ago. And Health-ISAC reported a 55% surge in cyber incidents targeting healthcare in 2025, with ransomware as the leading threat. This guide covers what IoMT is, why these devices create security problems that conventional IT tools cannot solve, and what healthcare organizations are doing to close the gap.

On this page:

• What Is IoMT?
• Common Categories of IoMT Devices
• How IoMT Devices Differ from Standard IT Assets
• The IoMT Threat Landscape in 2025-2026
• Why Conventional IT Security Tools Fall Short
• IoMT vs. IoT: What’s the Difference?
• What Effective IoMT Security Requires
• The Regulatory Landscape
• Building an IoMT Security Program
• How Asimily Secures IoMT

What Is IoMT?

IoMT, or Internet of Medical Things, refers to the network of connected medical devices, clinical systems, and healthcare applications that communicate over hospital networks and the broader internet. Infusion pumps transmit dosing data to electronic health records. Patient monitors stream vitals to nursing stations and clinical dashboards. MRI and CT scanners send imaging data to PACS servers and, increasingly, to cloud-based AI analysis tools. Wearable biosensors collect heart rhythm, glucose, and blood pressure data from patients at home and relay it to care teams in real time.

That connectivity has changed how care gets delivered. Continuous vital-sign monitoring reduces the need for manual bedside checks. Imaging data flows directly into diagnostic workflows instead of waiting for a technician to carry a disc. Remote patient monitoring makes it possible to manage chronic conditions outside a facility, reducing readmissions and freeing bed capacity.

The expansion is accelerating. Industry projections estimate that smart hospitals will deploy over 7 million IoMT devices by 2026, more than double the count from 2021. With each new device that joins the network, the clinical benefits grow. So does the attack surface.

Common Categories of IoMT Devices

IoMT covers a wide range of clinical and operational technologies. Understanding the categories matters because each carries distinct security characteristics, communication patterns, and risk profiles.

In-hospital clinical devices include smart infusion pumps, patient monitors, ventilators, imaging systems (MRI, CT, X-ray), laboratory analyzers, medication dispensing systems, and surgical robotics platforms. These devices typically run proprietary firmware, communicate using protocols specific to healthcare (HL7, DICOM, FHIR), and often connect directly to EHR systems.

Wearable and implantable devices extend data collection to the patient. Continuous glucose monitors, insertable cardiac monitors, ambulatory blood pressure cuffs, and activity trackers feed data back to clinical systems. Many communicate over Bluetooth or cellular, adding wireless attack vectors that do not exist for wired bedside equipment.

Remote patient monitoring (RPM) systems collect vitals from patients in their homes and transmit them to care teams. RPM sits outside the hospital’s network perimeter, which means the devices operate in environments with no enterprise security controls.

Facility infrastructure rounds out the IoMT category. HVAC controls, nurse call systems, pneumatic tube systems, and badge access readers increasingly connect to hospital networks. These systems are often managed by facilities teams, not IT, and may not appear in the security team’s asset inventory at all.

A connected MRI scanner and a smart building thermostat present very different threat models, communication needs, and remediation options. Any viable IoMT security program has to account for that diversity rather than treating all connected devices as a single category.

Related: Common Healthcare IoT Devices and Security Risks

How IoMT Devices Differ from Standard IT Assets

A hospital laptop and a connected infusion pump both sit on the same network. The similarities end there, and understanding the differences explains why IoMT demands its own security approach.

Proprietary, locked-down operating systems. IoMT devices run embedded firmware that was designed for clinical function, not for a hostile network environment. Many ship with hardcoded credentials, lack encryption for data in transit, and cannot accept standard endpoint security agents. You cannot install CrowdStrike on an infusion pump.

Slow, infrequent patching. Manufacturers publish thousands of IoMT vulnerabilities every year. Even the most responsive vendors address only a small fraction of their known CVEs. Asimily’s research shows that manufacturers typically patch roughly 1 in 50 known vulnerabilities, leaving healthcare delivery organizations (HDOs) to manage the residual risk on their own. A 2022 FBI report found that 53% of connected medical devices had at least one known critical vulnerability left unpatched, and roughly 1 in 5 run on unsupported operating system platforms.

Long operational lifecycles. Capital equipment like CT scanners and ventilators can remain in clinical use for 10 to 20 years. The operating system a device shipped with in 2012 may have reached end-of-life support by 2017, but the device itself keeps running because replacing a $2 million scanner is a capital planning decision, not a security decision.

Zero tolerance for disruption. Running an active vulnerability scan on an infusion pump mid-infusion risks disrupting the treatment. Taking a ventilator offline to apply a firmware update requires clinical coordination and backup equipment. Security controls for IoMT have to work around the clinical workflow, not the other way around.

Siloed ownership. In most HDOs, responsibility for medical devices sits in a gray area between biomedical/health technology management (HTM) teams and IT/IS security. HTM teams understand device function and clinical workflow. IT teams understand network architecture and threat response. Neither team alone has the full picture, and the tools each team uses are typically siloed and incompatible.

Related: Mitigating IoT Vulnerabilities in Healthcare

The IoMT Threat Landscape in 2025-2026

Healthcare remains one of the most targeted sectors for cyberattacks, and connected medical devices factor directly into that exposure.

Ransomware continues to escalate. Over 1,170 disclosed ransomware attacks hit healthcare organizations in 2025, a 49% increase over the previous year. Average breach costs now range from $7.42 to $11.2 million per incident. 44% of these attacks disrupted patient care, reducing hospital admissions by 17-25% during the incident window. Third-party vendors were involved in more than 80% of successful data breaches.

IoMT devices are being exploited as network entry points. In 2025, researchers discovered that over 1 million IoT medical devices had been left exposed to the public internet, leaking MRI scans, X-rays, blood test results, and patient identifiers without any authentication barrier. This was not a single misconfiguration at one hospital. It was a systemic visibility failure across the sector: organizations did not know what was connected, where it was communicating, or what data it was transmitting.

AI-powered attacks are the top concern for 2026. Security leaders surveyed by Health-ISAC identified AI-enabled attacks as the leading cyber threat going into the new year, followed by zero-day exploits, ransomware, third-party breaches, and spear-phishing campaigns. Generative AI lowers the cost and complexity of crafting targeted attacks against healthcare infrastructure, from automated vulnerability discovery to social engineering of device operators.

Regulatory enforcement is intensifying. In the first five months of 2025 alone, HHS Office for Civil Rights announced 10 settlements with healthcare organizations over data breaches, with penalties reaching into the millions. OCR found a common theme in each case: the organization had failed to implement fundamental HIPAA Security Rule requirements, especially the requirement to conduct an enterprise-wide security risk analysis that includes connected devices.

Related: IoMT Anomaly Detection and Incident Response

Why Conventional IT Security Tools Fall Short

Healthcare security teams often try to extend their existing IT security stack to cover IoMT. Firewalls, endpoint detection and response (EDR) platforms, and vulnerability scanners were built for servers, workstations, and managed endpoints. They run into fundamental limitations with connected medical devices.

Most IoMT devices cannot run endpoint agents. Their embedded operating systems and limited compute resources make agent-based detection impossible. Vulnerability scanners produce massive CVE lists without clinical context, so a security team facing 10,000 flagged vulnerabilities across a hospital’s device fleet has no way to distinguish the 50 that represent actual exploitable risk from the 9,950 that are theoretical. And because HTM teams and IT security teams use different tools, data about the same device often lives in two systems that do not talk to each other.

The result is a gap between what the security team can see and what is actually on the network. Enterprise environments routinely discover 15-30% more connected devices than IT teams expected once they deploy proper discovery tools. That gap is where attackers find their entry points.

IoMT vs. IoT: What’s the Difference?

IoMT is a subset of the broader Internet of Things. Both involve connected devices transmitting data over networks. The differences are in the operating context.

IoMT devices operate in clinical environments where availability directly affects patient safety. A compromised smart thermostat in an office building is an inconvenience. A compromised infusion pump or ventilator in a hospital can affect a patient’s treatment. That changes the risk calculus for every security decision, from how aggressively you scan to how quickly you can take a device offline.

IoMT also operates under regulatory frameworks that do not apply to general IoT. HIPAA imposes specific requirements on any device that processes or transmits electronic protected health information (ePHI). The FDA now requires premarket cybersecurity documentation for any connected medical device seeking market clearance. These obligations create compliance exposure on top of the operational security risk.

General IoT security principles like device discovery, segmentation, and firmware management all apply to IoMT. But the additional constraints of clinical workflow, patient safety, and healthcare regulation mean that IoMT security requires specialized tooling and domain expertise that generic IoT platforms do not provide.

Related: IoT Device Security: Addressing Risks to Medical IoT Devices

What Effective IoMT Security Requires

Securing IoMT at scale requires a purpose-built approach that accounts for device behavior, clinical context, and the operational constraints that make conventional security practices impractical in healthcare.

Complete Device Visibility

You cannot apply a security policy to a device you do not know is on your network. Effective IoMT security starts with automatic discovery and classification of every connected device, regardless of manufacturer, age, or network location. That means passive, non-disruptive identification that catalogs device type, model, operating system, firmware version, communication patterns, and network location without interfering with clinical operations.

Asimily’s platform delivers this through comprehensive asset intelligence that goes beyond basic device detection. The platform uses deep packet inspection to passively discover, classify, and profile every connected device, building behavioral baselines without sending traffic that could disrupt clinical equipment.

Risk-Based Vulnerability Prioritization

A large hospital network might have 50,000 connected devices carrying a combined total of hundreds of thousands of CVEs. Treating every CVE equally buries the security team in work that does not reduce actual risk.

CVSS scores alone are insufficient for IoMT. A critical CVSS rating on a device behind three layers of segmentation with no internet exposure and no known exploit in the wild is less urgent than a medium-severity vulnerability on an internet-facing device with a published proof-of-concept.

Asimily contextualizes vulnerabilities against exploitability, network exposure, device criticality, and clinical impact, using MITRE ATT&CK for actual attack path analysis rather than classification alone. This approach can reduce the list of devices requiring immediate action by an order of magnitude compared to raw vulnerability scanning.

Network Segmentation

Segmentation is the single most effective compensating control for devices that cannot be patched. By isolating IoMT devices into purpose-built network segments and restricting their communication to only the endpoints and protocols they require, organizations can contain lateral movement and limit the blast radius of a compromised device.

The operational challenge has always been building and validating policies at scale. Writing granular rules for thousands of heterogeneous devices, each with different communication requirements, stalls most segmentation projects before they deliver results. Asimily generates and validates segmentation policies automatically using observed device behavior and integrates with existing infrastructure (including Cisco ISE) so enforcement happens through equipment already in place.

Continuous Monitoring and Anomaly Detection

IoMT security is not a point-in-time assessment. Devices change behavior, new vulnerabilities emerge, and network conditions shift. Continuous passive monitoring, tracking communication patterns, data volumes, and protocol usage, provides the real-time anomaly detection that periodic scanning cannot.

When an infusion pump begins communicating with an unfamiliar external IP, or a patient monitor starts transferring data volumes outside its normal range, security teams need to know within minutes.

Pre-Procurement Risk Assessment

The most cost-effective point to address IoMT risk is before a device joins the network. Evaluating a connected medical device’s vulnerability history, manufacturer patching cadence, communication requirements, and known exploits before purchasing it prevents organizations from onboarding unmanageable risk.

Asimily’s ProSecure offering provides pre-purchase risk assessments that give procurement, biomed, and security teams the data they need to make informed acquisition decisions. The platform maintains a database of device security profiles, including MDS2 data, across thousands of device types.

The Regulatory Landscape

Federal regulators have moved medical device cybersecurity from guidance to mandate over the past three years.

FDA Premarket Cybersecurity Requirements

The FDA’s updated cybersecurity guidance, finalized in June 2025 and revised in March 2026, treats cybersecurity documentation as a prerequisite for market authorization. Any device with software and network connectivity, classified as a “cyber device” under Section 524B of the FD&C Act, must include a Software Bill of Materials (SBOM) in machine-readable format, demonstrate lifecycle vulnerability management, and provide evidence of a Secure Product Development Framework. The FDA can refuse premarket submissions that fall short. The Quality Management System Regulation (QMSR), which took effect in February 2026, now requires cybersecurity risk management to integrate directly with the manufacturer’s quality system under ISO 13485.

For HDOs, this means that newer devices entering the market should arrive with better security documentation. But it also means that legacy devices already in service, many of which cannot meet Section 524B requirements, require compensating controls on the hospital side.

HIPAA Security Rule

The updated HIPAA Security Rule raises the bar for how healthcare organizations protect ePHI across all connected systems, including IoMT devices. OCR enforcement has accelerated: 10 settlements in the first five months of 2025, with a consistent finding that organizations had not conducted adequate enterprise-wide security risk analyses. IoMT devices that process or transmit ePHI fall squarely within HIPAA scope, and regulators are no longer treating connected device security as an area that can be deferred.

For hospital CISOs and IT directors, IoMT security is now a compliance obligation with direct financial and operational consequences.

Related: How to Choose the Right IoMT Security Vendor

Building an IoMT Security Program

Organizations starting or maturing their IoMT security program should prioritize these areas:

1. Establish a complete, continuously updated device inventory. Know what is on your network before you try to protect it. Passive discovery is the only viable approach at scale for medical devices that cannot tolerate active scanning.
2. Break down the HTM/IT silo. IoMT security requires clinical context and network expertise working in concert. Shared visibility platforms that surface device intelligence to both teams accelerate decision-making and eliminate coverage gaps.
3. Prioritize vulnerability remediation by exploitable risk, not CVSS score alone. A CVSS 9.8 on a device behind three layers of segmentation with no internet exposure is less urgent than a CVSS 7.2 on a device that communicates with external endpoints and processes PHI. Use contextual risk scoring that accounts for network exposure, known exploits, and compensating controls.
4. Implement network segmentation for high-risk device categories first. Start with the device classes that carry the highest clinical and data risk, such as infusion pumps, patient monitors, and imaging systems, and expand from there.
5. Integrate pre-procurement security evaluation into purchasing. Make cybersecurity posture a procurement criterion alongside clinical functionality and cost. MDS2 forms and tools like Asimily’s ProSecure provide structured security data for pre-purchase evaluation.
6. Monitor device behavior continuously. Baseline what normal looks like for each device type and alert on deviations. Behavioral monitoring catches threats that signature-based tools miss.
7. Prepare for incident response. Have a documented, tested playbook that accounts for the operational constraints of medical devices. Quarantining a compromised device mid-procedure is a different decision than isolating a compromised laptop. The playbook needs to address who has authority to take a device offline and what clinical backup procedures apply.

How Asimily Secures IoMT

Asimily was built for the specific problem of securing connected devices in environments where clinical operations cannot be disrupted. The platform provides healthcare organizations with complete IoMT device visibility, risk-based vulnerability prioritization, automated segmentation policy generation, continuous behavioral monitoring, and pre-procurement security assessment.

Where generic IT security tools see an IP address, Asimily sees a GE Carescape B650 patient monitor running firmware version 3.2 on an unsegmented VLAN, communicating with three clinical systems and one external endpoint it has never contacted before. That depth of device intelligence turns IoMT security from an overwhelming inventory problem into a manageable, prioritized program.

Talk to an Asimily IoMT Security Expert →

---

Asimily is the next-generation cyber asset and exposure management platform for IT, IoT, OT, and IoMT environments. Learn more about our approach →