Hospital Cybersecurity in India: Securing Clinical Systems, Imaging and Medical Devices

Healthcare Security

A hospital runs on dozens of connected systems: the hospital information system, imaging, the laboratory, pharmacy, and hundreds of networked medical devices, all exchanging data through interfaces most people never see. When ransomware reaches them, the problem is not only data. Admissions, diagnostics and treatment slow down or stop. This guide sets out where hospital systems are weakest, what to fix first, and what Indian law now expects.

Why hospitals are hard to secure

The attack on AIIMS New Delhi in November 2022 showed what this looks like. According to the government's replies in Parliament, five servers hosting the hospital's e-Hospital application were affected and about 1.3 TB of data was encrypted, after the servers were compromised "due to improper network segmentation". Data was recovered from a backup server that had not been affected, and registration, appointments, admission and discharge were restored after two weeks. Outpatient, inpatient and laboratory services ran manually in the meantime.

Hospitals share problems that make ordinary IT security advice hard to apply:

• Nothing can stop. Systems run around the clock, so patching windows are short and reboots need clinical sign-off.
• Devices belong to vendors. Many medical devices run operating systems the hospital cannot patch or change without the manufacturer, and some are years past vendor support.
• Everything is connected to everything. Clinical systems exchange data constantly, often over older protocols designed for closed networks.
• Shared workstations and urgency. Clinical staff share terminals and work under time pressure, which pushes towards shared logins and long sessions.
• Many third parties. Device vendors, software suppliers, diagnostic partners and insurers all need some access.

Map the clinical estate first

Most hospitals do not have a complete list of what is on their network, particularly devices bought by clinical departments rather than IT. The inventory is the foundation for everything else, and it should record what each system does clinically, not only its IP address. A healthcare security assessment usually starts here.

Imaging: PACS and DICOM exposure

PACS stores and serves medical images using the DICOM standard. DICOM defines TLS profiles for secure transport, but on servers reachable from the internet they are almost never used. Researchers presenting at Black Hat Europe in December 2023 found more than 3,800 exposed DICOM servers in over 110 countries, and Trend Micro research published in 2026 found that of 3,627 exposed servers it examined, only 0.14% used TLS. An exposed DICOM service can hand patient names, dates of birth and images to anyone who asks.

• Never expose DICOM services to the internet. Remote reporting should go through a VPN or a gateway with authentication.
• Restrict which systems may talk to the PACS by configured application entity and address, and turn on TLS where the modality and PACS support it.
• Test the web viewers that radiologists and referring doctors use, which often have their own authentication and access control weaknesses.

Firewall rules for imaging should reflect which modality talks to which archive. DICOM traditionally uses TCP port 104 and the registered port 11112, and DICOM over TLS has its own registered port, 2762. A rule that allows DICOM from any internal address to the PACS is worth replacing with rules that name each modality and viewer.

Interfaces: HL7 and FHIR

Most clinical systems still exchange orders, results and admissions using HL7 version 2, usually carried over a simple framing protocol called MLLP that has no encryption or authentication of its own. HL7's guidance is that encryption happens below the application, for example through TLS or IPsec. Unless that has been added, HL7 messages cross the internal network in plain text, and any system that can reach an interface port may be able to read or send clinical messages.

That makes the interface engine one of the most important systems in the hospital. Anyone who controls it can read or alter clinical messages between systems. Treat it as a critical server: restricted admin access, limited network paths, encrypted connections where both ends support them, and monitoring for unexpected message sources.

HL7 version 2 over MLLP commonly runs on port 2575 by convention, though sites often use others. When testing, check from the administrative network whether interface engine listener ports can be reached at all and, in a test environment rather than production, whether the engine accepts messages from a source it has never seen before.

Newer integrations and patient apps use FHIR APIs, which are web APIs and fail in the same ways. The most common flaw is broken object-level authorisation: a patient or partner who changes an identifier in a request receives someone else's record. Our guide to testing API authorisation covers how to find it, and API penetration testing is the service that does.

Patient portals and telemedicine apps add flaws of their own, which a web application penetration test should cover:

• Lab reports and prescriptions downloadable through links that never expire or can be guessed.
• One-time passwords that can be tried without limit, or that appear in the response to the request that sends them.
• Appointment or record identifiers that let one patient view another patient's data.
• Doctors' and staff accounts on the same login page as patients, without stronger authentication.

Medical devices: secure what you cannot patch

Many devices cannot be patched by the hospital at all, and some will run the same software for their whole working life. The controls that work are mostly around the device rather than on it.

• Ask at procurement. Ask manufacturers for a completed MDS2 form (the Manufacturer Disclosure Statement for Medical Device Security, ANSI/NEMA HN 1-2019), which sets out a device's security capabilities in a standard format, and make it part of the purchase decision.
• Ask for the manufacturer's security process. IEC 81001-5-1:2021 sets out security activities across the life cycle of health software. Asking whether a supplier follows it, and how they handle vulnerabilities after sale, tells you whether the device will be supported or simply left as it is.
• Isolate by device type. Put devices on segments that can reach only the systems they report to, and nothing on the internet unless the vendor's service genuinely requires it.
• Control vendor remote access. One managed, logged route with MFA, enabled when needed, instead of permanent remote tools installed by each vendor.
• Test carefully. Active scanning can disrupt some devices. Device testing should be planned with biomedical engineering, done on spare or out-of-service units where possible, and never on equipment attached to a patient.

Devices also sold in the United States have, since 29 March 2023, had to meet section 524B of the US Federal Food, Drug, and Cosmetic Act for new submissions, which includes a plan to monitor, identify and address vulnerabilities and a software bill of materials. Asking the manufacturer for that bill of materials is a reasonable procurement request wherever you are.

Identity and access in clinical settings

Clinical work puts real pressure on identity controls. Staff move between shared terminals all day, and a login that takes too long gets bypassed. The controls that work are designed around that.

• Fast, individual logins on shared workstations. Badge tap or fast user switching, so staff use their own accounts instead of a shared ward login that is never signed out.
• Break-glass access with review. Emergency access to any record when care requires it, with every use logged and reviewed afterwards.
• Monitoring record access. Alerts when staff open records with no clinical reason, such as a colleague's, a public figure's or a relative's.
• Joiners and leavers. Residents, interns, agency and visiting staff change often, so accounts should get an end date when they are created.
• MFA where it matters most. Remote access, email, administrator and vendor accounts, backed by security awareness training built on the phishing staff actually receive.

Segmentation: the control that limits an outbreak

In a flat hospital network, ransomware that arrives through an administrative email can reach the PACS, the laboratory analysers and the bedside monitors. Segmentation by clinical function is what turns a hospital-wide outage into a contained incident in one department.

A workable model separates administrative IT, clinical applications, imaging, laboratory, medical devices by type, building systems, and guest and patient Wi-Fi, with explicit allow-lists between them. Then test it from the inside: from an administrative workstation, try to reach each clinical zone. An internal network penetration test shows how far one compromised account really gets, and a network penetration test of the clinical network checks every zone boundary.

The zone model below is a starting point. Real hospitals need exceptions, and each one should be written down as a specific rule between named systems rather than a wide opening between zones.

Ransomware readiness for a hospital

Hospitals need everything any organisation needs to recover from ransomware, such as immutable backups, separate backup credentials and tested restores, plus two things specific to care.

• Downtime procedures. Paper forms for registration, orders, results and medication, printed and stored where staff can find them, and practised. A downtime procedure nobody has used will not work at 3 a.m.
• A restore order agreed with clinicians. Which systems come back first, decided in advance by the people who know what patient care depends on. A business impact analysis done with clinical leads produces exactly this, and a ransomware readiness assessment tests the whole plan.

The effect on patients is documented. The US Department of Health and Human Services has said that cyber incidents affecting hospitals "have led to extended care disruptions, patient diversions to other facilities, and delayed medical procedures, all putting patient safety at risk." A 2023 study in JAMA Network Open found that ambulance arrivals at nearby emergency departments rose by 35.2% while a neighbouring health system was under a ransomware attack.

The first hours of a hospital incident decide how long it lasts:

• Activate clinical incident command alongside IT, so decisions about care, diversion and downtime are made by the people responsible for patients.
• Contain: isolate affected segments, and disconnect from partners if the infection could spread to them, while keeping life-critical systems running.
• Switch affected services to downtime procedures.
• Preserve evidence before rebuilding, so the entry route can be found and closed.
• Report to CERT-In within 6 hours of noticing the incident, and assess personal data breach obligations.
• Restore in the agreed clinical order, from backups verified to be clean.

Third parties and vendor access

Hospitals share data and access with many outside parties: device and software vendors, diagnostic partners, insurers and third-party administrators, and cloud providers. Each is a route in, or a place patient data can leak.

• Keep a register of who has remote access, to what and how, and remove access that is not used.
• Give vendors one managed route with MFA and session logging, enabled when needed.
• Write security and breach notification requirements into contracts, including how quickly a supplier must tell you about an incident affecting your data.
• Share only the patient data a partner needs, through a defined interface rather than spreadsheets and email.

What Indian law expects

Our guides to CERT-In six-hour incident reporting and the DPDP Rules compliance roadmap cover both in detail, and a DPDP assessment checks how patient data is collected, protected, shared and retained against them.

Where to start: the first 90 days

Frequently Asked Questions

Click any question to expand the answer.

Related reading

For the full ransomware picture in India, see the ransomware defence playbook. For what a real data protection assessment covers, consent management is not DPDP compliance. For the attacks that start in a hospital's inbox, strengthening social engineering defences.

Sources