Medical Device and Healthcare OT Security (IoMT)

Medical device cybersecurity is the practice of protecting connected clinical and biomedical equipment, and the networks that carry their data, from compromise that could affect patient safety, care delivery or protected health information. The Internet of Medical Things (IoMT) covers infusion pumps, physiological monitors, imaging systems, lab analyzers, ventilators and the gateways that connect them to electronic health records.

These devices are operational technology in a clinical setting. They run for a decade or more, often on operating systems that can no longer be patched, and they were rarely designed to sit on a routed, internet-adjacent network. The security goal is not to treat a patient monitor like a laptop. It is to know what is connected, limit how far each device can reach, and reduce the paths an attacker or a misconfiguration could use to move between clinical systems and the rest of the hospital.

01Key takeaways

01
IoMT devices are clinical OT: long lifecycles, legacy operating systems, scarce patch windows, and a direct line to patient safety.
02
You cannot protect what you cannot see. A device inventory built from passive network monitoring is the prerequisite for every other control.
03
Segmentation into clinical VLANs, with tightly governed conduits to EHR and imaging archives, limits blast radius better than flat hospital networks.
04
Compliance maps across several frameworks at once: FDA premarket and postmarket cyber expectations, IEC 80001 risk management, IEC 62443, and the HIPAA Security Rule.
05
Many clinical data flows are publish-only, such as imaging to an archive or device telemetry to a monitoring platform, which makes them candidates for one-way transfer and reduced inbound exposure.

02What healthcare OT and IoMT actually are

Healthcare operational technology is the connected equipment that delivers or supports care: infusion and syringe pumps, patient and telemetry monitors, ventilators, dialysis machines, imaging modalities such as CT, MRI and ultrasound, lab analyzers, and the picture archiving and communication systems (PACS) that store images. The Internet of Medical Things (IoMT) is the networked subset of this estate, including the gateways and middleware that move data between devices and clinical applications.

These systems behave like industrial OT, not like office IT. They are validated as a configured unit, often under regulatory control, so a hospital cannot freely change the operating system, install endpoint agents, or reboot a device mid-procedure. Many speak clinical protocols such as DICOM for imaging and HL7 or FHIR for messaging, alongside proprietary device protocols that general IT tools do not understand.

Short version: an IoMT device is a long-lived, lightly patchable clinical instrument that happens to sit on a network. Treat it as OT with a patient attached, not as another endpoint.

03Why medical device security is a patient-safety problem

In most IT environments, the worst case of a breach is data loss. In a hospital, a compromised or unavailable device can affect care directly. A ransomware event that takes down imaging or the EHR forces clinicians to divert ambulances, cancel procedures and revert to paper. That is why medical device cybersecurity is framed first as a safety and availability issue, and only second as a data-protection issue.

The risk is amplified by the realities of the clinical fleet. The structural problems are consistent across hospitals of every size.

Long lifecycles: capital equipment is kept for ten to twenty years, far beyond the support life of its embedded operating system.
Unpatchable software: vendor validation and uptime requirements mean patches arrive slowly or never, leaving known vulnerabilities in service.
Weak visibility: biomedical and IT teams often disagree on who owns devices, so no single inventory is complete.
Flat networks: in many facilities clinical devices share VLANs and reachability with general workstations and guest traffic.
High consequence: downtime or tampering can delay treatment, corrupt a dose, or disrupt monitoring during a critical window.

04The threat landscape for clinical OT

The dominant threat to healthcare OT is opportunistic, not targeted. Ransomware crews compromise an internet-facing service or a phished credential, then move laterally across flat networks until they reach high-value and high-impact systems, including imaging archives and clinical applications. Devices are frequently collateral damage: an unpatched embedded Windows host on the same segment becomes both a victim and a foothold.

Specific device classes have repeatedly drawn safety communications and recalls, including infusion pump platforms with exposed management interfaces or hard-coded credentials, imaging and monitoring gear running end-of-life operating systems, and gateways with weak authentication. The techniques map cleanly to recognized OT attack behavior.

Initial access through exposed remote services, vendor remote-support tools, or phishing into the IT estate.
Lateral movement across flat clinical and IT segments toward devices and archives.
Exploitation of unpatched embedded operating systems and default or hard-coded credentials.
Disruption of view or control: tampering with monitoring, alarms, or device availability during care.
Exfiltration of protected health information staged through the same paths used for lateral movement.

05A reference architecture: segmenting clinical VLANs

The single most effective architectural move is to stop treating the hospital as one network. Clinical devices belong in their own segments, grouped by function and risk, with explicitly defined and minimal conduits to the systems they must talk to. An infusion pump needs to reach its server and the EHR; it almost never needs to reach a guest network, a billing server, or the internet.

This mirrors the zones-and-conduits model of IEC 62443 and the risk-management discipline of IEC 80001, which governs the application of risk management to IT networks incorporating medical devices. The intent is the same: define what each zone is allowed to do, document the data flows, and make every crossing a deliberate, monitored decision rather than an accident of a flat subnet.

Device zone: A VLAN or segment grouping devices of similar type and risk, such as infusion pumps or imaging modalities, isolated from general IT and guest traffic.
Conduit: A governed, minimal path between a device zone and a system it must reach, such as an EHR interface engine or a PACS, with policy, logging and inspection.
Clinical data sink: A destination such as an imaging archive (PACS or vendor-neutral archive) or a monitoring platform that receives device output, often in a publish-only pattern.
Management plane: The separate path used to administer devices and gateways, which must not quietly reintroduce broad reachability into a protected clinical zone.

06Practical controls in priority order

Hospitals rarely get a greenfield network, so sequencing matters. The controls below are ordered so that each one makes the next more effective, starting with the visibility that everything else depends on.

Build a live inventory using passive network monitoring that fingerprints devices without probing them, then reconcile it with the biomedical asset database.
Identify the real data flows for each device class, so segmentation rules reflect clinical need rather than guesswork.
Segment in stages: start by isolating the highest-risk and end-of-life devices, then expand to full clinical VLANs.
Harden what you can touch: remove default credentials, disable unused services and management interfaces, and restrict vendor remote access to brokered, logged, time-boxed sessions.
Compensate where you cannot patch: virtual patching at the segment boundary, allow-listing, and strict conduit rules protect devices that the vendor will not or cannot update.
Monitor continuously for anomalous flows, new devices, and conduit violations, and feed alerts to the SOC.

07Mapping the compliance landscape

Medical device security sits at the intersection of several frameworks, and a single control often satisfies more than one. Manufacturers carry premarket and postmarket obligations; healthcare delivery organizations carry network, risk-management and privacy obligations. Knowing which framework speaks to which actor prevents teams from talking past each other.

FDA premarket cybersecurity: Under the FD&C Act section 524B, manufacturers of cyber devices must design for security, provide a software bill of materials, and submit a plan to monitor and patch vulnerabilities.
FDA postmarket cybersecurity: Manufacturers are expected to manage vulnerabilities over a device's life, coordinate disclosure, and issue updates; hospitals consume this through advisories and patches.
IEC 80001: Risk management for IT networks that incorporate medical devices, assigning responsibility for safety, effectiveness and data security to the healthcare organization.
ISA/IEC 62443: The cross-sector OT standard for zones, conduits and security levels, increasingly used to structure clinical network segmentation.
HIPAA Security Rule: US requirements to protect electronic protected health information through administrative, physical and technical safeguards, including access control and transmission security.
NIST SP 800-82: Guidance for securing operational technology that informs segmentation, monitoring and defense-in-depth choices in clinical environments.

08Getting clinical data out without opening a way in

A large share of clinical data movement is one-directional by nature. Imaging modalities push studies to an archive. Patient monitors stream vitals to a central station and onward to analytics. Device logs and telemetry flow to a monitoring or maintenance platform. In each case the device or zone is the source, and the receiving system has no clinical reason to initiate traffic back into the device zone.

That asymmetry is a security opportunity. If a path only needs to publish data outward, the inbound route is pure attack surface. Removing it does not change the clinical workflow, but it removes a conduit that ransomware, remote-access tooling, or a misconfigured firewall rule could otherwise use to reach the device segment. The design question is which flows are genuinely publish-only, and which truly require a two-way exchange such as worklist queries or device configuration.

09Common pitfalls that undo the work

Most healthcare OT incidents trace back to a small set of avoidable conditions. They are worth listing plainly because they recur across organizations that otherwise have mature IT security programs.

Flat networks where clinical devices share reachability with workstations, guest Wi-Fi and internet-facing services.
Standing vendor remote access, often through always-on tools or shared credentials, that becomes a permanent inbound path.
End-of-life operating systems left online with no compensating segmentation or virtual patching.
Inventory drift, where new devices are added by clinical departments without biomedical or IT registration.
Unmonitored data flows, so an archive or gateway can be reached or abused without anyone seeing it.
Management or backup channels that quietly reconnect a zone the team believed was isolated.

10Where one-way transfer and exposure reduction fit

For the publish-only flows described earlier, a one-way control can enforce the asymmetry in hardware rather than relying on a firewall rule that can drift or be reverted. Forwarding imaging studies to a vendor-neutral archive, replicating device telemetry to a monitoring platform, or sending logs to a SOC are all candidates: data leaves the clinical zone, and no session can be initiated back through the same path.

This is one control among many, not a cure. It will not patch a device, build your inventory, or replace segmentation and monitoring, and it cannot carry a workflow that genuinely needs a two-way conversation such as DICOM worklist queries or remote device configuration. For teams weighing isolation models, an AIRGAPNET controlled connectivity pattern can be compared alongside clinical VLAN segmentation and diode-based transfer when deciding which conduits must be one-way, disconnected by default, or time-controlled.

Decision test for any clinical conduit: does the receiving system need to send anything back? If not, the inbound path is attack surface you can design out.

11A pragmatic roadmap and closing thought

Medical device security is a program, not a project. The realistic path is incremental, and each phase delivers value even if the next one stalls. Sequence it so visibility comes first, isolation follows, and reachability reduction lands once you understand the real flows.

Phase one: passive discovery and a reconciled, living device inventory.
Phase two: risk-rank device classes and isolate the most dangerous, including end-of-life systems.
Phase three: build clinical VLANs with documented, minimal conduits to EHR and imaging archives.
Phase four: convert publish-only flows to one-way or reduced-exposure paths and add continuous monitoring.
Phase five: formalize governance under IEC 80001, fold devices into incident response, and track vendor advisories.

The goal is not a perfectly patched fleet, which is impossible with twenty-year-old equipment. The goal is a network where every device is known, every clinical data flow is intentional, and the paths an attacker would need simply do not exist. In a setting where availability is a safety control, reducing reachability is one of the most durable protections a hospital can build.

FAQFrequently asked questions

What is medical device cybersecurity?

It is the practice of protecting connected clinical and biomedical equipment, such as infusion pumps, imaging systems and patient monitors, along with the networks carrying their data, from compromise that could harm patient safety, disrupt care or expose protected health information. Because these devices are long-lived and hard to patch, the emphasis is on visibility, segmentation and reducing how far each device can reach.

What is IoMT and how is it different from regular IT?

The Internet of Medical Things (IoMT) is the networked subset of clinical equipment and its gateways. It differs from IT because devices run for a decade or more on operating systems that often cannot be patched, are validated as a configured unit under regulatory control, and use clinical protocols such as DICOM and HL7. They behave like operational technology with a patient attached, not like office endpoints.

Why is network segmentation so important for medical devices?

Most healthcare incidents spread because clinical devices share a flat network with workstations, guest traffic and internet-facing services. Segmenting devices into clinical VLANs with minimal, governed conduits to the systems they must reach limits how far ransomware or a misconfiguration can travel, and protects devices that cannot be patched.

Which standards and regulations apply to medical device security?

Several apply at once. Manufacturers face FDA premarket expectations under section 524B and postmarket vulnerability management. Healthcare organizations apply IEC 80001 risk management for networks with medical devices, increasingly use ISA/IEC 62443 for segmentation, follow NIST SP 800-82 for OT, and must meet the HIPAA Security Rule for electronic protected health information.

Where does one-way data transfer fit in healthcare OT?

Many clinical flows are publish-only, such as imaging to an archive, telemetry to a monitoring platform, or logs to a SOC. For these, a one-way control can let data leave the clinical zone in hardware while removing the inbound route an attacker could use. It is one control among many and does not replace inventory, patching, segmentation or monitoring, and it cannot carry workflows that genuinely need two-way exchange.

SRCSources of record

FDA guidance Cybersecurity in Medical Devices U.S. Food and Drug Administration OT guidance SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security NIST CSRC Sector topic Healthcare and Public Health Sector CISA Threat model MITRE ATT&CK for ICS MITRE IACS standard ISA/IEC 62443 Series of Standards ISA Risk management IEC 80001-1: Application of risk management for IT-networks incorporating medical devices International Electrotechnical Commission Privacy rule HIPAA Security Rule U.S. Department of Health and Human Services

From clinical flows to controlled boundaries

Decide which clinical conduits should ever carry traffic back.

For imaging archives, device telemetry and log forwarding that only publish outward, compare clinical VLAN segmentation, data diodes and controlled connectivity before you leave an inbound path in place.

See AIRGAPNET