Medical device cybersecurity has moved from a niche concern to one of the most practical problems in hospital IT. Patient monitors, infusion pumps, imaging workstations, lab analysers and nurse call systems are all networked now. Many run old operating systems that cannot be patched without the manufacturer, and some ship with flaws the hospital cannot see.
In January 2025, the US FDA and CISA warned hospitals about a patient monitor, the Contec CMS8000, whose firmware sent patient data to a hard-coded external IP address and could allow files on the device to be overwritten. The FDA's advice for affected devices was blunt: disconnect them from the network. That is the problem in one sentence: you cannot always fix a device, so you must control what it can reach.
This guide covers what changed in regulation, what hospitals should demand from device vendors, and how to secure the Internet of Medical Things (IoMT) you already have. For ransomware resilience across the wider hospital, see our hospital ransomware protection guide.
Why medical devices are the soft spot
Three structural reasons:
- Long lifetimes. A CT scanner or infusion pump may stay in service for many years, long after its embedded operating system stops receiving security updates.
- Patching is controlled by the manufacturer. Hospitals usually cannot install updates themselves without affecting the device's regulatory status or warranty.
- Clinical priority. Nobody takes a ventilator offline for a patch during a busy week.
The data supports the concern. An Armis analysis reported by TechTarget found that about 1 in 5 connected medical devices run on unsupported operating systems, that 39% of nurse call systems and 27% of infusion pumps had critical unpatched vulnerabilities, and that 32% of medication dispensing systems ran on unsupported versions of Windows (TechTarget).
The Contec CMS8000 case
The CMS8000 case, also sold under another brand name, is worth understanding because it shows the limits of trust in vendors. On 30 January 2025, CISA and the FDA published linked warnings (The Record):
- The firmware made remote access requests to a hard-coded IP address, bypassing the device's network settings, which could let an attacker upload and overwrite files.
- When a patient was connected, the monitor transmitted patient data in plain text to a hard-coded public IP address.
- The FDA recommended unplugging affected devices from the network where remote monitoring was not needed.
Security researchers at Claroty later argued the behaviour was more likely an insecure design than a deliberate backdoor. For a hospital, the distinction matters little: a monitor sending patient data to an unknown external address is unacceptable either way, and the only control the hospital had was the network.
What changed in regulation
US: FDA Section 524B and SBOMs
Since 2023, Section 524B of the US Federal Food, Drug, and Cosmetic Act requires manufacturers of "cyber devices", devices with software that can connect to the internet, to include cybersecurity information in premarket submissions. That includes a plan to monitor and address vulnerabilities, processes to provide updates and patches, and a software bill of materials (SBOM).
The FDA finalised updated guidance, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, on 27 June 2025, adding a section on its 524B expectations and clarifying SBOM content. It was superseded by a further version on 3 February 2026, aligned with the FDA's new Quality Management System Regulation.
For hospitals, the practical result is that new devices cleared in the US should come with an SBOM and a defined vulnerability and patch process. You can ask for both.
India: CDSCO's software guidance
CDSCO's October 2025 draft guidance on medical device software includes post-market obligations to report cybersecurity vulnerabilities, alongside lifecycle quality management. It is a starting point rather than a detailed cybersecurity regime, but it signals that Indian regulators expect manufacturers to own device security after sale.
Standards: IEC 81001-5-1 and MDS2
Two documents are useful in procurement everywhere:
- IEC 81001-5-1 sets security activities across the lifecycle of health software, including development, maintenance and vulnerability handling. Health-ISAC has encouraged hospitals to use it in medical device procurement (Health-ISAC).
- The MDS2 form (Manufacturer Disclosure Statement for Medical Device Security) is a standard questionnaire in which manufacturers describe a device's security features, such as authentication, encryption, logging and patching. The newer IEC/TS 81001-2-2:2025 guidance includes material on MDS2 and a sample SBOM.
What to demand in procurement
| Ask | Why |
|---|---|
| Completed MDS2 form | Standard view of security features |
| SBOM in a machine-readable format | Lets you check new vulnerabilities against your fleet |
| Supported OS and end-of-support date | Tells you how long the device will receive security updates |
| Patch process and timelines | Who patches, how quickly, and whether it affects certification |
| Evidence of IEC 81001-5-1 or equivalent practices | Shows a secure development lifecycle |
| Required network ports and destinations | Lets you build tight firewall rules |
| Remote support method | Remote access should use your controlled, MFA-protected path |
| Vulnerability disclosure contact | Who you call when an advisory lands |
Put these into contracts, not only RFP questionnaires. A vendor commitment to provide patches for a defined period is worth far more than a brochure claim.
Securing the devices you already have
Most hospitals have years of installed devices bought without any of the above. The approach is containment:
- Build an inventory. List every networked device: type, manufacturer, model, software version, location, IP and MAC address, owner. Passive network monitoring tools can help discover devices you did not know were connected.
- Classify by risk. Consider clinical impact (life-sustaining or not), data handled, and whether the OS is supported.
- Segment. Put medical devices on dedicated network segments, separated by type where practical. Imaging modalities talk to PACS; monitors talk to their central station; neither needs the internet.
- Allow-list communications. Use firewall rules so each device can only reach the specific systems it needs. Block outbound internet access by default. The Contec case is exactly what this prevents.
- Control remote vendor access. Route all vendor support through a single, MFA-protected, logged access path that is enabled only when needed.
- Monitor. Watch device segments for unusual traffic, such as a monitor talking to an external IP.
- Plan replacement. For devices on unsupported OS with high clinical impact, budget for replacement and make cybersecurity a criterion.
Where the hospital system fits
Devices rarely stand alone. Monitors feed vitals into the nursing record, analysers send results to the laboratory information system, and modalities send images to PACS. Every one of those integrations is a network path that must be explicitly allowed and secured.
When we build integration for hospitals, through our healthcare integration layer, we route device data through an integration engine on a controlled segment rather than letting devices talk directly to the core HMS database. That gives one place to validate messages, log traffic and enforce rules, and it means a compromised device cannot reach the main database. Our DevOps in healthcare work extends that discipline to infrastructure.
A 6-month IoMT security plan
| Month | Focus | Output |
|---|---|---|
| 1 | Discovery and inventory | Device register with owners |
| 2 | Risk classification | Top 20 high-risk device groups identified |
| 3 | Segmentation design | Network zones and allowed flows agreed with biomedical engineering |
| 4 | Implement for imaging and lab | Segments live, outbound internet blocked |
| 5 | Vendor remote access and monitoring | Single MFA path, alerting on device segments |
| 6 | Procurement policy and replacement plan | Security clauses in contracts, replacement budget for worst devices |
Biomedical engineering and IT must do this together. Biomedical teams know the devices and clinical constraints; IT knows the network. Hospitals that leave IoMT security to one of them alone usually stall.
Common mistakes
- Scanning devices aggressively. Active vulnerability scanners can crash fragile medical devices. Use passive discovery on clinical segments, and coordinate any active testing with biomedical engineering and the manufacturer.
- Segmenting on paper only. Drawing VLANs is not segmentation if firewall rules between them allow everything. Verify with traffic data that blocked flows are really blocked.
- Leaving vendor remote access always on. Permanent VPN accounts or remote desktop tools installed by vendors are among the most common ways into device networks. Enable access per session and log it.
- Forgetting the workstations. Many "devices" are ordinary Windows PCs running vendor software: PACS viewers, analyser controllers, ECG management stations. They need the same attention as the device itself.
- Ignoring advisories. Manufacturer and regulator advisories, like the Contec warning, only help if someone reads them and checks the inventory. Assign that job explicitly.
- Buying first, asking later. Once a device is installed and in clinical use, your leverage over the vendor drops sharply. Security requirements belong in the purchase decision.
Indian hospitals face an extra wrinkle: many devices arrive through distributors rather than directly from manufacturers, so security documentation and patch commitments can get lost along the way. Ask the distributor to obtain MDS2 forms, SBOMs and patch policies from the manufacturer before the purchase order, and name the manufacturer's security contact in the contract. The same goes for refurbished equipment, which is common in smaller hospitals and often arrives with old firmware and no update path at all.
The cheapest moment to secure a medical device is before you buy it. The second cheapest is before you connect it.
Conclusion
Medical device cybersecurity is now a core hospital risk. Too many devices run unsupported software, some ship with dangerous behaviour like the Contec monitors, and regulators are pushing manufacturers to take responsibility through FDA 524B, SBOMs, CDSCO's post-market expectations and standards such as IEC 81001-5-1.
Hospitals cannot patch their way out. They can inventory, segment, allow-list, control vendor access, monitor and buy better. Start with imaging and lab, write security into procurement, and make biomedical engineering and IT one team. If you want help securing device integrations around your hospital system, contact us.
Frequently asked questions
What is IoMT security?
IoMT security is the protection of networked medical devices, such as patient monitors, infusion pumps, imaging equipment and lab analysers, from cyber threats. It combines device inventory, network segmentation, controlled vendor access, monitoring and secure procurement.
What was the Contec CMS8000 issue?
In January 2025, the FDA and CISA warned that Contec CMS8000 patient monitors made remote access requests to a hard-coded IP address and transmitted patient data in plain text to a hard-coded public IP address. The FDA advised disconnecting affected devices from networks where possible.
What is a medical device SBOM?
A software bill of materials lists the software components in a device, including third-party and open-source components. Under FDA Section 524B, manufacturers of cyber devices must provide one in premarket submissions, which helps hospitals check devices against newly disclosed vulnerabilities.
What is the MDS2 form?
The Manufacturer Disclosure Statement for Medical Device Security is a standard form in which manufacturers describe a device's security capabilities, such as authentication, encryption, logging and patching. It is useful in procurement but should be verified against the deployed device.
How do you secure medical devices that cannot be patched?
Place them on segmented networks, allow only the specific connections they need, block outbound internet access, route vendor remote access through a controlled MFA path, monitor their traffic and plan replacement for the highest-risk devices.
What is IEC 81001-5-1?
IEC 81001-5-1 is an international standard that defines security activities across the lifecycle of health software, including secure development, maintenance and vulnerability handling. Hospitals can ask vendors for evidence of conformance during procurement.
