Open a hospital network diagram and you will find equipment nobody can immediately identify. An image processing workstation in radiology, an analyser in physiology, a patient monitor on a ward, a recording unit attached to an endoscopy system. These were procured as medical devices, but what they are is networked computers — and many of them are still running the operating system they shipped with.
IT staff usually discover this because of a trigger. A vulnerability advisory circulates, and a check reveals several affected units on site. Or a request to update is met with "we cannot change the configuration; it is tied to the regulatory approval."
This is not negligence. Medical devices carry constraints, regulatory and technical, that ordinary IT equipment does not. Which is precisely why the standard answer — apply the patch — often does not apply, and a different form of defence has to be designed.
This article is for hospital IT leads, clinical engineers, and administrative directors organising the management of network-connected medical devices. It works in two layers: what can be done now, given that the devices themselves cannot be changed, and what to specify at the next replacement.
Disclaimer: This article is general information. Regulatory treatment of medical devices is governed by Japan's Pharmaceuticals and Medical Devices Act and by MHLW and PMDA publications. Always confirm update feasibility and maintenance terms for a specific device with its manufacturer.
Why the Operating Systems Stay Old
1. The device outlives the OS. Imaging and laboratory equipment is routinely used for a decade or more, while OS support periods are shorter. Support ending partway through a device's service life is close to unavoidable by design.
2. Configuration changes are regulated. Medical devices reach the market through approval under the Act, and the software configuration is part of what was approved. A hospital updating the OS on its own initiative may fall outside the manufacturer's warranted configuration. That is what lies behind "please do not apply patches yourself." On software as a medical device, see What Is SaMD?.
3. Validation is expensive. Even when the manufacturer applies a patch, it must verify that device behaviour is unaffected. For equipment bearing on diagnosis, that is not trivial, so updates are not always delivered quickly.
4. It cannot be taken down. Updates mean reboots, and monitoring equipment running around the clock — or a scanner with a full booking sheet — has few windows.
5. Ownership is split. Medical devices belong to clinical engineering or to a department; the network belongs to IT. A networked medical device straddles both and can appear on neither register.
Regulators have been tightening cybersecurity expectations on manufacturers in recent years (confirm independently: check MHLW and PMDA publications for the specific provisions and timing). That mainly affects devices approved from now on, and does not change the state of what is already installed.
Start With an Inventory
| Item | What to establish |
|---|---|
| Name, model, location | Scattered across departments; reconcile with the clinical engineering register |
| Network connectivity | Wired, wireless, or standalone. Devices originally offline get connected later |
| OS and version | Support status; usually needs the manufacturer to confirm |
| Communication partners | What it talks to; internal only, or out to the manufacturer as well |
| Remote maintenance | Whether the manufacturer connects remotely, and how (Securing Remote Maintenance) |
| Whether agents can be installed | Antivirus or EDR feasibility (Antivirus and EDR) |
| Removable media use | Whether data moves in and out on USB (Managing Removable Media) |
| Maintenance contract | In force or not, renewal date, whether vulnerability information is provided |
| Replacement plan | Next refresh date and budget status |
IT cannot build this alone. It is joint work with clinical engineers, radiographers, and laboratory technologists — and the contact routes built between departments while compiling it are valuable in their own right. Knowing immediately who to call about a given device speeds up incident response (A Hospital Incident Response Plan).
Start with networked devices that handle patient data. Attempting a complete census at once never finishes.
Defend From Outside the Device
If the device cannot change, defend around it. Segmentation is the core.
The logic is simple. An old OS is dangerous because (a) it can be reached, and (b) a compromise can spread. Narrowing what can reach it shrinks both at once.
| Measure | What it does | Priority |
|---|---|---|
| Dedicated segment | Place medical devices on a network separate from clinical and administrative systems | High; the largest effect |
| Allow-listed communication | Permit only required destinations | High |
| Isolation from the internet | Ensure devices do not talk directly to the internet | High |
| Restricting device-to-device traffic | Prevent free communication even within a segment | Medium |
| External monitoring | Watch device traffic for unusual behaviour | Medium; installs nothing on the device |
| Physical access control | Room access control, blocking unused ports | Medium |
| Limiting maintenance access | Move manufacturer remote support from always-on to per-request | High |
Separation is not binary. Cutting a device off entirely breaks image transfer and results integration, so in practice you permit only the necessary flows — which is why the inventory needs to capture communication partners. See Network Segmentation and Asset Management.
Sequence the work:
- Devices talking directly to the internet — first; ask whether that can simply be stopped
- Unsupported OS handling patient data — move to a dedicated segment
- Devices with always-on maintenance connections — make those per-request
- Devices exchanging data on removable media — address alongside media controls
Confirm clinical impact before changing anything. Results failing to reach the EMR because traffic was restricted is the worst outcome. Pair every change with an impact assessment and a rollback procedure.
Receiving Vulnerability Information
The overlooked part of device security is the route by which information arrives.
| What you need | Detail |
|---|---|
| Configuration information | The OS and software components in the device; there is a growing push to request a software bill of materials (SBOM) |
| A notification route | Whether the manufacturer has a mechanism to inform the hospital |
| A recipient inside the hospital | Who receives it, and where judgement escalates |
| Decision criteria | Act now, act at the next service visit, or accept with compensating measures |
Whether a notification route exists depends on the maintenance contract, and it is usually not something that was checked when signing. Re-read the current contract, or write it in explicitly at renewal. See Questions to Ask Your Vendors.
General advisories are available from IPA and NISC, but only the hospital can map them onto its own equipment — which is where the inventory pays off again.
Decide the response criteria in advance. Because "patch immediately" is often unavailable for medical devices, the realistic options are:
- Temporarily disconnecting the device from the network
- Narrowing permitted communication further
- Temporarily changing how the device is used (suspending removable media, for example)
- Increasing monitoring and waiting for the next service visit
- Bringing the replacement forward
Whichever you choose, someone who can judge clinical impact must be involved. There are few devices IT can unilaterally decide to disconnect. Build this decision framework into your incident response plan.
Specify It at the Next Refresh
You cannot change the constraints on installed equipment, but you can set the conditions for what you buy next. Over the medium term this is what moves the needle.
| Requirement area | What to write |
|---|---|
| Support period | Support duration for the OS and software, relative to expected service life |
| Update provision | How security updates are delivered, how often, at whose cost, and expected downtime |
| Configuration disclosure | Whether a software bill of materials can be provided |
| Vulnerability notification | Whether notification occurs, through what channel, and how quickly |
| Network requirements | Required destinations and protocols; whether internet access is needed |
| Authentication | Administrative authentication, whether default passwords can be changed, individual identification |
| Logging | Whether operational and connection records are available, how obtained, retention |
| Maintenance access | The remote support method; whether a non-always-on arrangement is possible |
| Removable media | Whether USB use is required and whether it can be restricted |
| Disposal | Data erasure method and handling of storage media |
Sometimes no product meets all of it. Stating the requirements anyway makes the gaps explicit and gives you a basis for compensating measures. See Putting Security Into Procurement Requirements and Demarcating Responsibility.
The electronic clinical information coordination structure addition introduced in 2026 requires compliance with the guidelines and a dedicated medical information system safety management officer. How IT assets — including medical devices — are inventoried and managed bears directly on designing that role. See The 2026 Fee Revision.
Manufacturers and suppliers are increasingly asked to evidence their own security posture; on that, see What Is an ISMS (ISO/IEC 27001)?.
Conclusion
- Old operating systems persist for structural reasons: lifecycle mismatch, regulation, validation cost, uptime constraints, and split ownership
- Begin with an inventory — joint work between IT, clinical engineering, radiology, and laboratory
- Given that the devices cannot change, defend from outside with segmentation and allow-listed traffic; permit only the flows that are needed
- Prioritise internet-facing devices, then unsupported systems handling patient data, then always-on maintenance paths
- Secure a vulnerability notification route in the maintenance contract, and decide the response criteria before you need them
- Installed equipment cannot be changed, but the next procurement can be specified: support period, update provision, configuration disclosure, notification, logging, and maintenance access
Medical device security cannot be completed by IT or by clinical engineering alone. If you need help organising it — including who owns what — get in touch. We can start with building the inventory and setting priorities.
References and Sources
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Guidelines for the Safe Management of Medical Information Systems, Version 6.0 (PDF) | MHLW
- Pharmaceuticals and Medical Devices Agency (PMDA)
- Information-technology Promotion Agency (IPA)
- National center of Incident readiness and Strategy for Cybersecurity (NISC)
- On the FY2026 Medical Fee Revision | MHLW
Note: regulatory requirements for medical devices change with amendments. Confirm update feasibility and maintenance terms with the manufacturer, and regulatory interpretation with MHLW and PMDA publications.