Key Takeaways
- The Internet of Medical Things is the fastest-growing hospital attack surface. Every connected pump, monitor, modality and sensor is a node that can be attacked.
- Patient safety, not just data, is at stake. A compromised device can affect dosing, monitoring or imaging, so the risk model goes beyond confidentiality.
- Many devices cannot be patched on an IT cadence. Vendor-locked operating systems and certification constraints mean compensating controls carry the load.
- Network segmentation is the highest-impact control. A dedicated, firewalled medical-device segment limits both the reachability and the blast radius of any compromise.
- IEC 80001 frames the shared responsibility between the device manufacturer and the healthcare provider for risk management of networked medical devices.
The Internet of Medical Things Attack Surface
The Internet of Medical Things (IoMT) describes the growing population of connected devices that participate in patient care: infusion and syringe pumps, multi-parameter patient monitors, imaging modalities (CT, MRI, ultrasound, X-ray), ventilators and anaesthesia machines, dialysis machines, laboratory analysers, point-of-care diagnostic devices, smart beds, wearable telemetry, and an emerging class of connected implants. Devices that were once standalone now sit on networks, stream data to clinical systems, receive configuration from central servers, and in some cases reach the cloud for analytics and vendor support.
Each connection is an attack surface. A device can be a target (an attacker manipulating its behaviour), a pivot (a foothold from which to reach the wider network), or a source of data exposure (patient data in transit or at rest on the device). The population scale matters: a mid-size hospital can have thousands of networked medical devices, far more than its conventional IT endpoint count, and the inventory is frequently incomplete because devices are procured by biomedical engineering rather than IT.
The defining property of IoMT risk is that patient safety, not only data confidentiality, is on the line. A compromised infusion pump touches dosing. A manipulated monitor touches the clinical picture a care team is acting on. A disrupted imaging modality touches diagnosis. This raises the stakes above the data-breach framing that applies to most IoT and demands a security model that treats availability and integrity of the device as first-order safety concerns.
Inventory, Discovery and the Visibility Gap
The first failure in most IoMT programmes is that nobody has a complete, accurate inventory of the connected devices. Medical devices are typically procured and maintained by biomedical or clinical engineering, while IT owns the network they sit on. The result is two partial registers that do not reconcile: IT sees network addresses without clinical context, biomedical sees device asset tags without network or firmware detail, and a meaningful fraction of connected devices appear in neither view.
A usable inventory captures, per device: manufacturer, model, the operating system and firmware version, the network location and segment, the communication protocols in use, the patch and support status, the clinical function and criticality, and the data classes the device handles. Passive network discovery tools designed for healthcare environments (which fingerprint medical devices without active probing that could disrupt them) help close the gap where manual inventory is incomplete. Active scanning has to be used with great care because some medical devices behave unpredictably when probed.
The inventory is not paperwork; it is the foundation everything else rests on. Segmentation decisions, patch prioritisation, vendor escalation, vulnerability tracking and incident response all depend on knowing what is connected. In our engagements, the first inventory pass typically reveals a device count materially higher than the hospital expected, with a long tail of older devices that nobody currently owns the security of.
Need a Sector-Specific Cyber Programme?
Codesecure Solutions delivers ISO/IEC 27001:2022 certified VAPT, compliance and managed security for government, healthcare, hospital and municipal customers across India, Singapore, UAE and Malaysia. Named consultants, fixed-price proposals, free retest within 90 days.
See Industry Services →Network Segmentation for Medical Devices
Network segmentation is the single highest-impact control for IoMT because it works regardless of whether a given device can be patched. The goal is a dedicated medical-device network segment, or a set of segments by device class and risk, separated from the general user network, the guest network and the administrative network by enforced firewall policy rather than by routing convention alone.
The enforced policy on the medical-device segment should be tight and explicit. Devices talk only to the specific clinical servers and services they need (a monitor to its central station, a modality to its PACS, a pump to its drug-library server), and nothing else. Internet egress is denied except to the documented vendor support endpoints a device genuinely requires. The general user network cannot initiate connections into the device segment. And east-west traffic within the device population is constrained so that a compromise of one device does not freely reach others.
Micro-segmentation by device class strengthens this further: patient monitoring separated from infusion, imaging separated from laboratory, life-critical devices separated from convenience devices. The finer the segmentation, the smaller the blast radius of any single compromise. Most hospitals begin with partial segmentation (a single device VLAN) and mature toward class-based micro-segmentation over time. Even the first coarse step delivers a large risk reduction relative to a flat clinical network.
Patching, Lifecycle and Compensating Controls
Most medical devices cannot be patched on an IT cadence, and frequently cannot be patched by the hospital at all. Devices run vendor-locked operating systems, some of which have reached end of support while the device remains clinically in service for years more. Regulatory certification can mean that any change requires vendor validation, so the hospital cannot simply apply an operating-system patch the way it would on a workstation. Patch availability lags, and even when a patch exists the change window competes with continuous clinical use.
Compensating controls therefore carry most of the defensive weight. Segmentation (already discussed) limits reachability. Network monitoring detects anomalous device behaviour that may indicate compromise. Application and protocol allowlisting at the segment boundary constrains what a device can communicate. Vendor security advisories are tracked so that known device vulnerabilities are matched to the hospital inventory and risk-assessed. And for the most critical unpatched devices, isolation tightens further until the vendor provides a fix.
Lifecycle governance closes the loop. Procurement should include security requirements (manufacturer disclosure of the software bill of materials, a vulnerability disclosure process, a defined patch-support commitment, and secure configuration guidance) so that new devices enter the estate with a known security posture. End-of-life devices need a documented decommissioning path and, while they remain in service past vendor support, a formal risk acceptance with tightened compensating controls. For unpatched critical vulnerabilities, the escalation path to the vendor and, where the vendor is unresponsive, the replacement decision both need to be defined in advance.
IEC 80001 and Shared Responsibility
IEC 80001 is the international standard for risk management of IT networks that incorporate medical devices. Its central idea is that connecting a medical device to a network creates risks that neither the device manufacturer nor the healthcare provider can manage alone, and it defines a shared-responsibility model in which the provider takes ownership of the network risk while the manufacturer provides the information the provider needs to manage it.
For the healthcare provider, IEC 80001 translates into a set of concrete obligations: appoint a responsible owner for medical-device network risk, maintain the device inventory and network topology, perform risk assessment before connecting new devices and when the network changes, and balance the three key properties the standard emphasises (safety, effectiveness, and data and system security). The manufacturer's contribution is the information the provider needs: the device's network requirements, its security characteristics, its software composition, and its known vulnerabilities and their remediation.
In practice, IEC 80001 gives the hospital a defensible governance frame for the conversations it must have with device vendors. When a vendor ships a device with an unsupported operating system or resists patch coordination, the standard provides the language and the structure to assign responsibility and document risk. Codesecure aligns its IoMT engagements to IEC 80001 and produces evidence that supports the provider's risk-management file and its obligations under the applicable data protection law.
Regulator Pressure or Public Audit?
Whether you need DPDP, PDPA, PDPL or HIPAA aligned evidence, our compliance and VAPT lead is available for a 30-minute free scoping call. Audit-ready, board-ready, no slideware.
Talk to a Specialist →Safe Testing, Monitoring and Incident Response
Testing IoMT requires more care than testing conventional IT, because aggressive probing can disrupt a device that is connected to a patient. The methodology is safety-first. Passive observation (traffic capture and analysis, configuration review, firmware analysis where a sample can be examined off the clinical floor) does most of the discovery without touching live devices. Active testing is reserved for representative devices in a lab or maintenance context, in coordination with the manufacturer, and never run against a device in active clinical use unless explicitly scoped and authorised in writing. Codesecure runs IoMT pentests on this basis and coordinates with the device vendor where the device design requires it.
Continuous monitoring closes the gap between point-in-time testing and ongoing operation. Behavioural monitoring of the medical-device segment establishes what normal device communication looks like and alerts on deviations: a device reaching an unexpected destination, a sudden change in traffic volume, a protocol a device has never used before. Because device behaviour is relatively predictable compared with general user traffic, anomaly detection on the device segment is unusually effective.
Incident response for IoMT carries the same patient-safety constraint as the rest of healthcare cyber. The default IT response of isolating or shutting down a suspect system may be unsafe if that system is a connected device supporting a patient. The IR plan must define, in advance, safe isolation procedures per device class, who in clinical leadership authorises taking a device offline, and how to preserve evidence without compromising the patient. Joint tabletop exercises between IT, biomedical engineering and clinical leadership surface the conflicts between IT instinct and clinical safety before a real incident forces the issue.
Frequently Asked Questions
What is the difference between IoMT security and general IoT security?
The decisive difference is patient safety. General IoT security focuses on confidentiality and on preventing devices being used as a pivot. IoMT adds device integrity and availability as first-order safety concerns, because a compromised or unavailable medical device can affect dosing, monitoring, diagnosis or treatment directly. The risk model and the testing methodology both have to account for that.
How do we secure medical devices we cannot patch?
Compensating controls. Place devices on a dedicated firewalled segment with no general user-network reachability and no internet egress except to documented vendor endpoints, monitor the segment for anomalous behaviour, track vendor advisories against your device inventory, and tighten isolation further for any device with an unpatched critical vulnerability. Escalate to the vendor and consider replacement where the vendor will not remediate. Codesecure helps design these controls per device class.
Why is the device inventory such a common weak point?
Because medical devices are usually procured and maintained by biomedical or clinical engineering while IT owns the network, leaving two partial registers that do not reconcile. A meaningful fraction of connected devices appear in neither view. A unified inventory (manufacturer, model, firmware, network segment, protocols, patch status, clinical criticality and data classes) is the foundation for segmentation, patch prioritisation and incident response, and building it is usually the first step in an engagement.
What is IEC 80001 and does it apply to us?
IEC 80001 is the international standard for risk management of IT networks that include medical devices. It defines a shared-responsibility model where the healthcare provider owns the network risk and the manufacturer supplies the information needed to manage it. It applies to any provider connecting medical devices to a network, which is now essentially every hospital. Codesecure aligns IoMT engagements to IEC 80001 and produces evidence for the provider's risk-management file.
Can you test connected medical devices without endangering patients?
Yes. Our methodology is safety-first: passive observation and configuration and firmware review do most of the discovery without touching live devices, and active testing is reserved for representative devices in a lab or maintenance context in coordination with the manufacturer. We never run active disruptive testing against a device in clinical use unless explicitly scoped and authorised in writing.
How does IoMT security relate to our data protection obligations?
Connected medical devices handle patient personal data, which is regulated under the applicable law (DPDP, PDPA, PDPL, or HIPAA for US-linked data). Securing the IoMT estate is part of meeting the security-safeguard obligations those laws impose, and a device-related breach triggers the same notification duties as any other personal-data breach. Codesecure maps IoMT controls to the relevant framework so the security work and the compliance evidence are produced together.
Secure Connected Devices Without Disrupting Care
Codesecure Solutions delivers IoMT security, medical-device segmentation, IEC 80001 aligned risk management and safe device VAPT across India, Singapore, UAE and Malaysia. ISO/IEC 27001:2022 certified delivery, named consultants, vendor-coordinated testing, fixed-price proposals.
