Medical Device Security

• Passive inventory
• Clinical segmentation
• HIPAA evidence
• Never-isolate in care

Hospitals run thousands of FDA-regulated connected devices on unsupported operating systems, on the same network as everything else. They cannot be scanned, cannot be patched on your schedule, and cannot be isolated during patient care.

The constraint set

• Patching frequently requires vendor revalidation, sometimes FDA involvement
• Active scanning has caused device malfunction in the field
• Device lifetimes run 10–20 years against a 3-year OS support window
• Availability is a patient safety property, not a convenience

What we deliver

1. Passive clinical inventoryEvery connected device identified by observing traffic — make, model, firmware, communication partners. For most organizations this is the first accurate inventory they have ever had.
2. Risk classificationBy what the device does and what it can reach, not by CVSS. An unpatched imaging workstation that reaches the domain is a different problem from an isolated pump.
3. Clinical segmentationDevices separated from corporate access and grouped by function, so a compromised workstation cannot traverse into clinical equipment.
4. Compensating controlsPer device class, documented with residual risk, for everything that cannot be remediated.
5. Safe containment rulesAutomation that will never isolate a device engaged in active patient care, verified against the care pathway before enforcement.

FDA expectations and manufacturer documentation

Medical device cyber security is regulated at two points in the lifecycle, and hospitals inherit obligations from both.

• Premarket — the manufacturer must design and document security before clearance. You cannot change this, but you can demand the evidence.
• FDA post-market medical device security — the manufacturer must monitor, disclose and remediate vulnerabilities across the supported life of the device. When they stop, that date is a risk event on your register and should be tracked as one.
• Manufacturer Disclosure Statement for Medical Device Security (MDS²) — the standard form describing a device's security characteristics. We collect these during inventory and reconcile them against what the device is observed doing on your network. The gap between the two is frequently the finding.
• Joint Security Plan for medical devices — the industry framework for shared manufacturer and provider responsibility. We use it to make the handoff explicit in procurement, so responsibility is assigned before an incident rather than argued about during one.

Practical consequence: security requirements belong in the purchase contract. Once the device is installed, your leverage is gone.

Evidence

Inventory, control documentation and logging produced in the form your HIPAA Security Rule risk analysis needs, generated as a build output rather than assembled the month before a review. See healthcare.

Device onboarding

Onboarding is the only point at which you have leverage over a device you will operate for fifteen years. Security requirements written into the purchase contract are achievable; the same requirements raised after installation are a change request the manufacturer will decline.

Risk classification by function, not CVSS

An unpatched imaging workstation that reaches the domain is a materially larger problem than an unpatched isolated pump with a worse CVE. Function and reachability decide, not score.

Where cyber security for medical devices differs from IT

Security in medical devices is constrained by regulation in a way ordinary IT is not. Cyber security of medical devices is a shared responsibility between manufacturer and provider, and the split is defined before the device is ever plugged in.

• Wired clinical equipment — imaging, lab analyzers, infusion systems on the wired network. Segmentation is the primary control.
• Cyber security in wireless medical devices — telemetry monitors, wireless pumps and wearables add an RF attack surface and frequently authenticate weakly. These need their own SSID, their own segment, and monitoring for association anomalies.
• Federal health estates — DHA medical device security requirements add Defense Health Agency controls on top of the FDA lifecycle expectations. Scope these early; they change the architecture.

Worked example — 400-bed hospital, 6,200 connected devices

1. Weeks 1–6, passive inventory6,200 devices discovered against an asset register listing 3,400. The gap was largely facilities equipment, wireless infusion pumps and 90 devices from a clinic acquired two years earlier.
2. Week 7, the findingFourteen imaging workstations running an OS that reached end-of-support three years earlier, with cached domain administrator credentials, on the same flat VLAN as general corporate. Any one of them was a full domain compromise.
3. Weeks 8–10, MDS² reconciliationDisclosure forms requested from every manufacturer. Received for 61% of device types. Of those received, 23% described security characteristics that did not match observed behavior — devices making outbound connections the form did not mention.
4. Weeks 11–20, segmentationClinical devices separated from corporate and grouped by function. Imaging to PACS only. Pumps to their server only. Facilities fully separated from clinical.
5. Week 21, credentialsCached domain admin credentials removed from clinical workstations and replaced with a scoped service account. This required vendor coordination for four device types and was the longest single task.
6. Weeks 22–26, compensating controlsFor 890 devices that cannot be patched: documented control, residual risk, named clinical owner, and an annual review date on each.
7. ContainmentEnabled for clinical support and facilities only. Life-sustaining and patient-connected classes registered never-isolate, verified against the care pathway with clinical engineering present.

What we will not do