There are devices in every hospital that cannot be patched, cannot be scanned, and cannot be replaced. And they’re on the same network as your patient data.

I started working with hospital networks about 10 years ago. I thought I understood network security. Then I walked into the imaging department of a 400-bed hospital and saw a CT scanner running Windows XP connected directly to the hospital LAN. Not air-gapped. Not segmented. Sitting on the same flat network as the patient management system, the billing server, and the administrative workstations.

When I asked why, the radiology IT manager said: “The manufacturer says it can’t run anything newer than XP. And the scanner cost ₹3.5 crore. We can’t replace it for another 4 years.”

That’s the reality of healthcare cybersecurity: you’re securing a network where most of the devices were designed before modern security threats existed, and the consequences of a breach aren’t just data loss — they’re patient safety incidents.

The Three-Headed Problem: DICOM, HL7, and Unpatchable Devices

Hospital networks have three architectural realities that make them fundamentally different from enterprise networks:

DICOM (Digital Imaging and Communications in Medicine): The protocol that medical imaging devices (CT, MRI, X-ray, ultrasound) use to store, retrieve, and transmit images. DICOM was designed in the 1990s for interoperability, not security. It transmits in cleartext by default. Authentication is optional. Access controls are primitive. A DICOM viewer on a compromised workstation can browse every image on the PACS server without any authorisation check.

HL7 (Health Level 7): The protocol that laboratory systems, pharmacy systems, patient management systems, and EMRs use to exchange data. Lab results, medication orders, patient demographics, admission/discharge/transfer notifications — all flowing over HL7. Like DICOM, HL7 was designed for reliability, not security. No encryption. No authentication. No integrity checking. An attacker on the hospital LAN can inject fake lab results, modify medication orders, or intercept patient data — all via HL7.

Unpatchable devices: Medical devices have a lifecycle of 7-15 years. They run operating systems that are often 10-20 years old. They require FDA/CDSCO certification for any software change — which means even a security patch requires months of validation and recertification. Many devices run Windows 7 Embedded, Windows XP Embedded, or proprietary real-time OSes that have been end-of-life for years. They cannot receive security updates. And they’re connected to the network because they need to send images, lab results, and patient data to other systems.

What I’ve Learned From Securing Hospital Networks

1. You Cannot Secure What You Cannot Inventory

The first thing I do in any hospital engagement is a passive network discovery — not active scanning, because active scanning can crash medical devices. We use passive monitoring (NetFlow/sFlow, port mirroring, or SPAN ports) to identify every device on the network without sending a single packet to a medical device.

The results are always surprising. In a recent 600-bed hospital, passive discovery found 47 devices that weren’t in any asset inventory — including an infusion pump server that had been running unnoticed for 3 years.

2. Network Segmentation Is Non-Negotiable

Medical devices should never be on the same network as administrative workstations. End of story. I design hospital networks with the following minimum segmentation:

  • VLAN 10 — Medical Imaging (DICOM): CT, MRI, X-ray, ultrasound, PACS server, DICOM viewers. Only DICOM traffic permitted. No internet access for imaging devices.
  • VLAN 20 — Lab Systems (HL7): Laboratory analysers, LIS server, HL7 interface engine. Only HL7 traffic permitted. No general internet access.
  • VLAN 30 — Patient Management: HMS/EMR servers, patient registration, billing. Limited to authorised clinical and admin staff.
  • VLAN 40 — Building/IoT: HVAC, access control, CCTV, building management. Isolated from all clinical VLANs.
  • VLAN 50 — Guest/BYOD: Patient and visitor Wi-Fi. Internet only. No access to any clinical VLAN.
  • VLAN 60 — Administrative: Staff desktops, printers, file servers. Strictly controlled access to clinical VLANs via application-specific proxies, not routed connectivity.

Between each VLAN, FortiGate firewall policies enforce the minimum required access. An imaging workstation can talk to the PACS server (DICOM port 11112 only). It cannot talk to the lab system. It cannot talk to the patient database. It cannot browse the internet.

3. Replace Authentication With Microsegmentation (Where You Can’t Patch)

You can’t patch an MRI scanner running Windows XP. But you can ensure that the only thing it can talk to is the PACS server — by MAC address, by switch port, by application port. An attacker who compromises the hospital admin network can’t reach the imaging VLAN because there is no route. Even if they physically plug into a port in the imaging department, 802.1X authentication drops them into a quarantine VLAN until the NAC system verifies their identity and device compliance.

4. Monitor for Anomalous Medical Device Behaviour

Medical devices have very predictable traffic patterns. A CT scanner sends DICOM images to the PACS server. An infusion pump sends status updates to the pump management server. An HL7 interface engine forwards lab results to the EMR. If any of these devices suddenly starts communicating with an unfamiliar IP, sending data at an unusual time, or attempting to reach the internet — that’s an incident.

A SIEM with baselining capabilities (or PrahiX Ora’s anomaly detection) catches these deviations. In one deployment, we detected a PACS server that had been compromised — it was exfiltrating DICOM images (patient names, scan dates, diagnostic details) to an external IP every night at 2 AM. The hospital’s existing monitoring hadn’t caught it because “the PACS server is supposed to send images.” Yes — but not to a server in Eastern Europe.

The Regulatory Angle: DPDP Act and Healthcare

Healthcare data is “sensitive personal data” under the DPDP Act. The thresholds for breach notification and penalties are higher for healthcare than for general personal data. If a hospital network is compromised and patient data is exfiltrated — including medical images, diagnostic reports, and treatment histories — the Data Protection Board can levy penalties of up to ₹250 crore.

Given that most hospital networks have significant security gaps (unpatched devices, cleartext medical protocols, flat network topologies), the regulatory risk is substantial. The good news: the DPDP Act’s “reasonable security safeguards” requirement aligns perfectly with the segmentation and monitoring practices I’ve described. A hospital that has implemented proper VLAN segmentation, 802.1X, and SIEM-based monitoring can demonstrate that it took reasonable steps to protect patient data — even if a breach occurs.

What I’d Tell Every Hospital Administrator

Hospital cybersecurity isn’t an IT problem. It’s a patient safety problem. An attacker who modifies a lab result in the HL7 stream could cause a patient to receive the wrong medication. An attacker who encrypts the PACS server could delay a cancer diagnosis by days. An attacker who takes down the hospital management system could prevent admissions during a mass casualty event.

The threat model for healthcare is different from any other sector. The devices are older, the protocols are less secure, the consequences are more severe, and the budgets are tighter. But I’ve seen 600-bed hospitals transform their security posture with a phased approach: segment first, monitor second, automate third. No multimillion-rupee projects. Just good architecture, consistently applied.

And the CT scanner running Windows XP? It’s still there. But it’s on its own VLAN, firewalled to only talk to the PACS server, monitored by our SIEM for any deviation from its baseline behaviour. It can’t reach the internet, the patient database, or anything else on the hospital network. The manufacturer still won’t patch it. But it’s no longer the hospital’s biggest security risk — because the architecture around it changed.

Sanjay Seth has designed network security architectures for Indian hospitals since 2015. He’s the CEO of P J Networks and a specialist in healthcare IoT security.