Securing Medical Devices in Japanese Hospitals: An IoMT Field Guide

A hospital device estate combines everything that makes OT security hard, then adds patient safety on top. An infusion pump or a bedside monitor runs closed, certified firmware that cannot host an agent and cannot be modified without breaching its medical certification. An MRI or CT scanner cannot be taken offline for an active scan without cancelling patient appointments. Many devices run embedded operating systems years past end of support. And where a factory PLC failure halts production, a compromised or failed medical device puts patients at direct risk, which raises the stakes well above an operational outage.

Medical devices speak their own protocols, and a generic network scanner does not read them. Imaging systems use DICOM, clinical messaging runs on HL7, lab instruments use ASTM, and newer systems expose FHIR over HTTPS. Without those protocols a scanner sees only an unidentified host on port 104 or 2575, with no model or firmware attached. Device intelligence that decodes DICOM, HL7, ASTM, and FHIR can name the device down to model and firmware, which is the identity a vulnerability match depends on.

Because no agent can be installed and no scan can be risked, the workable path is the catalog-based approach: identify each device from its vendor, model, and firmware, taken from the hospital's existing inventory or read passively off the network, then look up its exact vulnerabilities, lifecycle status, and remediation. Nothing runs on the pump or the scanner, and no probe is sent to a device in clinical use. For medical equipment the vendor-direct data matters: in one comparison DeviceTotal produced firmware-exact vulnerability mapping for a GE LOGIQ E10 ultrasound that the manufacturer's own public data did not provide.

Much of a hospital estate cannot be patched at all: an estimated 46 percent of devices run firmware past vendor support. Disconnecting them is rarely an option and replacing them is a multi-year capital programme. The realistic control is to know precisely which devices are affected, which vulnerabilities are actively exploited, and what compensating controls exist, from network segmentation to access restriction and monitoring, for the cases where a patch never will. Lifecycle tracking flags end-of-life devices before support lapses, so replacement can be planned ahead rather than discovered during an incident.

In Japan medical device security sits under the PMD Act, and hospital procurement increasingly expects a defensible device risk position, alongside international frameworks such as IEC 62443 and FDA 21 CFR Part 11 for exporters. Audit-ready evidence of what devices exist, what they are exposed to, and how that risk is being managed is becoming a procurement requirement in its own right. For a foreign medical-device or security vendor, Japanese-language deployment and support, and on-premise options for patient-data residency, are the practical entry conditions.

IoMT security protects the Internet of Medical Things, the connected medical devices in a hospital such as infusion pumps, patient monitors, imaging scanners, and lab analysers. Most cannot run a security agent and cannot be taken offline for scanning, so they need agentless approaches that identify and assess each device without touching it.

Active scanning can disrupt a device in clinical use, and an MRI or CT scanner cannot be taken offline without cancelling appointments. Patching is often impossible because the firmware is certified and closed, or the device is past vendor support. An estimated 46 percent of devices cannot be patched at all.

By decoding the protocols medical devices actually use, DICOM for imaging, HL7 for clinical messaging, ASTM for lab instruments, and FHIR over HTTPS, a device can be named down to vendor, model, and firmware. That identity is looked up against a vendor-direct vulnerability database, with nothing installed on the device.

Japan's PMD Act governs medical devices, and hospital procurement increasingly expects a defensible device risk position. Exporters also encounter IEC 62443 and FDA 21 CFR Part 11. Audit-ready evidence of what devices exist and how their risk is managed is becoming a procurement requirement.

You manage the risk instead of removing it. Know exactly which devices are affected and which vulnerabilities are actively exploited, then apply compensating controls such as network segmentation, access restriction, and monitoring. Lifecycle tracking flags end-of-life devices so replacement can be planned before support lapses.