When most healthcare IT teams build their HIPAA compliance program, they start where every IT shop starts: laptops, servers, email, the EHR. It's familiar ground — endpoints get hardened, MFA gets enforced, the audit trail gets centralized.
Meanwhile, three floors up in radiology, an MRI scanner is running an unpatched copy of Windows from 2014, talking to the network over an unencrypted DICOM port, with admin credentials hard-coded into a service account no one has rotated in seven years.
This isn't a hypothetical. It's the typical state of medical device security at U.S. hospitals in 2026 — and it is the gap that healthcare-focused threat actors have been quietly exploiting for the better part of a decade.
The standard endpoint security playbook — install an EDR agent, force patching cycles, enforce least-privilege — does not work on most clinical equipment. Three reasons:
1. FDA recertification risk. Hospitals can't simply patch a CT scanner the way they patch a workstation. The device runs FDA-cleared firmware, and most manufacturers void support guarantees if the customer modifies the OS or installs third-party software. Some imaging modalities are still running Windows 7 in production because the manufacturer has not released a validated update.
2. Uptime is non-negotiable. A radiology suite running 12 procedures a day cannot be taken offline for a 45-minute patch window. The same applies to infusion pumps, telemetry monitors, and surgical robotics — devices that are either actively keeping a patient alive or in the middle of a billable procedure.
3. Proprietary protocols. Medical devices speak DICOM, HL7, MQTT, and a long tail of vendor-specific protocols that most enterprise security tools either ignore or misinterpret. A standard NDR product will happily watch a ransomware operator pivot through a fleet of infusion pumps and classify the traffic as "unknown — allowed."
The combined effect: medical devices end up as a parallel, unmanaged network that the security team can't see, can't patch, and can't easily defend.
The first failure mode in IoMT security is the asset inventory. Most hospitals significantly undercount the number of connected medical devices on their network. The common gaps:
In our incident response engagements, we routinely find IoMT estates that are 30–60% larger than the customer's documented inventory. Each invisible device is, by definition, an invisible HIPAA risk.
Here is the part that gets missed in board-level HIPAA discussions: a medical device that processes, stores, or transmits patient data is a covered system under the HIPAA Security Rule, full stop. Specifically:
OCR enforcement has been trending in this direction for years. The proposed updates to the Security Rule explicitly call out network segmentation, asset inventory, and vulnerability management — all three of which fail at the medical-device boundary in most organizations.
The compliance translation: if your HIPAA risk assessment does not cover IoMT, it is not a HIPAA risk assessment.
The threat profile has shifted. Where 2020-era hospital ransomware was largely opportunistic — phish a user, drop a beacon, encrypt the file server — the campaigns we have responded to over the past 18 months show a more deliberate pattern:
Step three is where IoMT becomes the operator's safe harbor. We have seen threat actors maintain access for weeks after the corporate environment was believed to be clean, simply by hiding on devices the IR team had no visibility into.
If your incident response plan stops at the corporate AD boundary, the operator is still on your network.
The fix is not "buy a medical-device security product and run it like an EDR." That mental model has caused most of the failed deployments we have seen. A working program has four parts:
1. Passive discovery and classification. Continuous traffic analysis identifies every connected device, classifies it by clinical function, and maps it to the responsible service line. Active scanning is dangerous in this environment — a device that crashes mid-procedure is a patient-safety event.
2. Risk-based prioritization tied to clinical context. A CVE on an unsupported imaging device that processes 200 PHI records per day matters more than the same CVE on an isolated building-automation controller. The risk model has to incorporate clinical exposure, not just CVSS.
3. Network segmentation as the primary compensating control. Since you cannot patch most of these devices, you isolate them. Microsegmentation at the device-class level — imaging on one segment, infusion on another, telemetry on a third — limits lateral movement during an incident and is increasingly expected by regulators.
4. IoMT-aware incident response. When an incident occurs, responders have to be able to read DICOM and HL7 traffic, know which devices are clinically active, and coordinate with biomed engineering before isolating equipment. A standard DFIR firm will get this wrong, and getting it wrong has clinical consequences.
If you are a CISO or HIPAA Security Officer reading this and your IoMT program is still on the roadmap, the practical first move is a single 30-day project: an accurate, current asset inventory of every connected device in clinical space. Not a spreadsheet. A live, passively collected, continuously updated inventory.
Everything else — segmentation, risk scoring, patching strategy, IR readiness — depends on knowing what you have. We have yet to meet a healthcare organization where the inventory project did not surface at least one device that had been compromised for months.
Yes. Any device that creates, receives, maintains, or transmits ePHI is in scope for the HIPAA Security Rule. That includes imaging modalities, telemetry monitors, infusion pumps, and the workstations that aggregate data from them.
In most cases, no — the FDA clearance and the manufacturer's support agreement assume an unmodified configuration. The compensating controls are passive monitoring, network segmentation, and tight access control rather than agent-based endpoint security.
IoT covers all connected devices; IoMT (Internet of Medical Things) is the subset operating in clinical environments — devices that touch patient care, PHI, or both. IoMT security has to factor in FDA regulation, clinical uptime requirements, and patient-safety risk that general IoT programs do not.
At minimum annually, and any time there is a material change — a new clinical service line, an acquisition, a major device-fleet refresh, or a significant incident. The risk analysis is a living document, not an artifact.
It starts with passive traffic capture in clinical segments, joint triage with biomed engineering, and a containment plan that does not interrupt active patient care. Standard DFIR runbooks rarely accommodate the clinical constraints, which is why healthcare-specialized IR matters.
About Dark Analytics
Dark Analytics provides healthcare-focused cybersecurity services, including connected device security, HIPAA-driven risk assessment, healthcare penetration testing, and incident response. Our HCAP (Healthcare Cyber Assurance Program) platform gives covered entities and business associates a single command center for HIPAA controls, vendor risk, and threat intelligence.
To request an IoMT visibility assessment or engage on an active incident, contact info@darkanalytics.com
