A hospital network carries devices that keep people alive, run unsupported operating systems, cannot be patched without vendor approval, and were designed on the assumption that the network is friendly.
The usual security playbook — patch promptly, deploy endpoint protection, enforce configuration baselines — does not apply. Installing an agent may void support or regulatory clearance. Patching may be contractually prohibited. Rebooting for updates may be clinically unacceptable.
What remains is architecture: control what the device can reach, and watch what it does.
Start With an Inventory You Can Actually Use
Every medical device security programme stalls in the same place: nobody has a complete list. Devices are procured by clinical departments, installed by vendors, and connected by whoever was available that day. Biomedical engineering has an asset register built for maintenance scheduling, and IT has a network inventory, and neither is quite what security needs.
A usable inventory records, per device:
| Field | Why it matters |
|---|---|
| Make, model, software version | Determines applicable advisories |
| Network location (VLAN, IP, switch port) | Determines blast radius and containment options |
| AE title / hostname where applicable | Needed for imaging flow rules |
| Clinical owner | Who to call before touching it |
| Vendor and support status | Whether patches exist at all |
| Patch commitment | Contractual obligation, if any |
| Data handled | Whether it holds or transmits PHI |
| Remote access method | Usually the biggest single risk |
How to build it without a year-long project: start from passive network discovery to find what is actually talking, reconcile against the biomedical asset register and procurement records, then close the gaps by walking the departments. Passive discovery first matters — active scanning of medical devices can and does cause them to misbehave, and some will fault on an aggressive port scan. Test scanning policy carefully on a non-clinical unit before pointing it at anything in use.
Accept that the inventory will be imperfect and start using it anyway. An 80%-complete inventory acted on beats a perfect one still in progress.
Segmentation That Does Not Break Clinical Workflow
Segmentation is the primary control. It is also where well-intentioned projects cause clinical incidents, by blocking flows nobody documented.
Group by function and risk, not by department. A useful grouping:
- Imaging modalities — CT, MR, CR/DX, US, NM, mammography
- Physiological monitoring — bedside monitors, telemetry
- Therapeutic devices — infusion pumps, radiation therapy systems
- Lab instruments and analysers
- Point-of-care devices — glucose meters, blood gas analysers
Devices within a group tend to share communication patterns, which makes the rule set tractable.
Derive rules from observed traffic, not from assumption. The sequence that works:
- Place the segment in monitoring mode and observe real traffic for a full cycle — at least a week, ideally including a month-end and a weekend
- Document every flow observed, and identify the clinical purpose of each
- Write explicit allow rules for the flows that have a purpose
- Investigate flows that have no obvious purpose before blocking them — some will be legitimate and undocumented, some will be genuinely unexpected
- Move to enforcement with a rapid rollback path and a defined observation window
The flows that surprise people are usually undocumented integrations: a research export nobody remembered, a departmental database pulling data directly, a vendor's analytics phoning home.
Deny outbound internet access by default. Very few clinical devices have a genuine need to originate connections to the internet. Where one does — telemetry, remote monitoring, licence checks — allow the specific destination rather than the category. This single rule removes a large share of realistic attack paths at almost no clinical cost.
Plan for the failure mode. If the segmentation enforcement point fails, does clinical traffic stop? Design that answer deliberately rather than discovering it during an outage.
Vendor Remote Access
The most common uncontrolled path into a clinical network is a support connection.
The recurring patterns: a permanent site-to-site tunnel from the vendor's network; a remote access tool installed on the device console with an account the hospital does not manage; a modem or cellular link installed at commissioning and forgotten; shared credentials used by whichever engineer picks up the ticket.
What good looks like:
- All vendor access brokered through a hospital-controlled gateway. No direct inbound paths to devices.
- Access enabled on request and disabled afterwards, not standing.
- Named individual accounts, not a shared vendor login. If the vendor cannot support that, record it as an accepted risk with an owner.
- Session recording where the system supports it.
- A register of every access method, reconciled against contracts — including the ones commissioned years ago.
That last point produces the findings. Access methods installed during commissioning and never documented are common, and nobody discovers them until someone goes looking.
Monitoring When You Cannot Harden
If the device cannot be secured directly, the compensating control is visibility.
What to watch:
- Outbound connections to new destinations. A device whose traffic pattern is stable for months and suddenly is not warrants a look.
- Protocol anomalies. An imaging modality speaking anything other than DICOM, worklist, and its known management protocols is worth investigating.
- Authentication failures, where the device logs them at all.
- Traffic volume outside normal patterns, including at times the device is not clinically in use.
Baseline behaviour is the prerequisite. Most clinical devices have highly regular traffic patterns, which makes anomaly detection unusually effective compared with general enterprise endpoints — a benefit of their limited function.
Fixing It at Procurement
Every device purchased today is a decade of operational risk. Procurement is the point of maximum leverage, and it is exercised once per device generation.
Clauses worth insisting on:
- A software bill of materials (SBOM), so you can determine exposure when a component vulnerability is published without waiting on the vendor
- A defined patch commitment: how quickly critical vulnerabilities are addressed, and for how many years
- A vulnerability disclosure and notification process, with named contacts
- End-of-support dates stated up front, so replacement can be budgeted rather than forced
- No hardcoded or shared credentials; support for hospital-managed authentication where feasible
- Encryption in transit for any interface carrying PHI, or a documented reason why not
- Audit logging with the ability to export off-device
- Explicit permission to apply operating system security updates where the device runs a general-purpose OS
Bring these to the evaluation stage. After signature, the leverage is gone.
Related Reading
- PACS and DICOM Security: The Practitioner's Guide — imaging-specific hardening
- Hospital Network Design for Imaging Traffic — the segmentation architecture
- Building a Healthcare IT Risk Register That Leadership Uses — recording what you cannot fix yet
- The Healthcare IT Security Audit Checklist — assessing device controls
Need a device inventory reconciled from network discovery and asset exports? Send us the details — that reconciliation is exactly the kind of tool we build.