The connected devices on your clinical floor are the breach you can't see

Why IoMT is the blind spot in healthcare security

Most hospital security programs are built for laptops and servers, assets you can inventory, patch, and run an agent on. Connected medical devices break every one of those assumptions. You generally can't install endpoint software on an infusion pump. You can't patch a CT scanner on Patch Tuesday because the FDA-cleared configuration is controlled by the manufacturer and can't be changed at will. And many of these devices run operating systems that went end-of-life years ago and will never get another security update.

The result is a large, growing fleet of devices that your existing tools often don't see. They don't show up in your vulnerability scanner the way a server does, and an aggressive scan against a live patient monitor is a patient-safety event, not a routine finding. So some of the riskiest assets in the building are frequently the least visible ones.

The exposure is well documented. In its 2022 State of Healthcare IoT Device Security report, Cynerio found that roughly 53% of connected medical devices carried at least one known critical vulnerability. These devices often sit on the same flat networks as everything else, sometimes with default or shared credentials, and they touch or transmit ePHI constantly. That combination, unpatchable, unmonitored, and connected, is exactly why IoMT has become a primary path for attackers into healthcare environments.

• Can't run an agent, the device OS is locked down or proprietary, so endpoint security software often won't install
• Can't patch on a normal cycle, updates are vendor- and FDA-gated, and the cleared configuration can't be changed at will
• Can't safely scan, standard vulnerability scanning can crash or disrupt a device attached to a patient
• Often invisible, legacy and IoMT assets frequently don't appear in standard IT asset inventories or CMDBs
• Frequently exposed, unsupported operating systems, default credentials, and flat networks are common across the fleet

Discovery and risk-based inventory: you can't protect what you can't see

Every engagement starts with finding the devices. We build an accurate inventory of the connected clinical fleet using passive, safety-first techniques that never interrogate a device in a way that could affect its operation. Passive network observation and traffic analysis let us identify and fingerprint devices by how they actually communicate, so we can see an infusion pump or a modality workstation without ever touching it directly.

An inventory is only useful if it tells you where to act first. We enrich each device with the context that drives risk: make, model, operating system and support status, known vulnerabilities, network exposure, whether it uses default or shared credentials, and, critically, whether it stores or transmits ePHI and how it factors into patient care. A vulnerable device on an isolated bench is a very different problem from the same vulnerability on a monitor connected to a patient.

From there we produce a risk-based inventory, not a flat list. Devices are ranked by the realistic likelihood of compromise and the clinical and ePHI impact if it happens, so your team gets a prioritized picture of where the real exposure is, the same likelihood-and-impact reasoning a defensible HIPAA risk analysis demands, applied specifically to the device fleet.

• Passive, agentless discovery that identifies and fingerprints devices without disrupting them
• Make, model, OS, support status, and known-vulnerability mapping for each asset
• ePHI and clinical-context tagging, what the device touches and how it factors into care
• Risk ranking by likelihood and impact, so remediation effort goes where it matters most
• An inventory built to stay current as devices are added, retired, or moved

Segmentation: the primary control for devices you can't patch

When you can't fix the vulnerability on the device, you change what the device can reach. Network segmentation is one of the most effective controls for unpatchable and legacy medical equipment, because it shrinks the blast radius: a compromised pump or an end-of-life imaging workstation can no longer serve as a stepping stone to the EHR, the domain, or the rest of the device fleet.

The hard part in healthcare isn't the concept, it's doing it without breaking clinical workflows. Medical devices have legitimate, specific communication needs: a modality has to reach the PACS, a monitor has to reach its central station, devices have to talk to their management servers. We design segmentation around how the devices actually work, building policies from the real traffic observed during discovery rather than from guesswork, so the controls hold without interrupting care.

We help you move from a flat clinical network toward least-privilege segmentation, grouping devices by type, function, and risk, and allowing only the connections each group genuinely needs. The proposed HIPAA Security Rule update (the NPRM published in January 2025) would make network segmentation an explicit requirement, so getting it right now is both an immediate risk reduction and a head start on where the regulation is heading.

• Microsegmentation and VLAN strategy designed around real, observed device traffic, not assumptions
• Least-privilege policies that allow only the clinical connections each device group actually needs
• Isolation of legacy and end-of-life devices to contain the blast radius of a compromise
• Workflow validation with biomedical and clinical engineering so nothing in patient care breaks
• A path away from flat networks toward a defensible, segmented architecture

Continuous monitoring that understands clinical protocols

Generic network monitoring doesn't understand a hospital. It sees traffic, not clinical context, so it struggles to tell the difference between a modality sending a study to PACS and an attacker exfiltrating images, or between a normal HL7 result message and a manipulated one. Monitoring IoMT effectively means understanding the protocols these devices actually speak.

We implement and tune monitoring that is fluent in clinical protocols, DICOM for medical imaging, HL7 for clinical messaging, and the device-management traffic each fleet relies on. That clinical awareness is what turns raw network data into meaningful detection: unexpected outbound connections from a device that should only talk to one server, a monitor suddenly scanning the network, default credentials being used, or protocol behavior that doesn't match how the device is supposed to operate.

Because the devices can't defend themselves, the network has to do it for them. Continuous, protocol-aware monitoring gives you the early warning that an unpatchable device has been compromised or is behaving abnormally, detection that compensates for the prevention you can't put on the device itself, and that feeds directly into your incident response.

• Detection tuned to clinical protocols, DICOM, HL7, and device-management traffic
• Behavioral baselining so abnormal device activity stands out against its normal pattern
• Alerting on unexpected connections, lateral movement, default-credential use, and protocol anomalies
• Visibility that compensates for prevention you can't install on the device itself
• Findings that integrate with your existing SOC, SIEM, and incident-response workflow

Compensating controls, procurement, and SBOM

For the devices you genuinely can't patch, the frozen imaging configuration, the end-of-life pump still in service, the answer is layered compensating controls. Beyond segmentation and monitoring, that means hardening what you can: changing default and shared credentials where the device allows it, tightening access to management interfaces, disabling unused services and ports, and putting strict controls around the few connections each device truly needs. None of it makes the underlying vulnerability disappear, but together it makes the device far harder to reach and far harder to use as a pivot.

The most cost-effective time to secure a medical device is before you buy it. We help you build security into procurement, asking vendors the right questions about patching cadence, supported lifespan, authentication, network requirements, and breach responsibilities before a device enters the environment, so you stop inheriting risk you'll have to compensate for later.

A central part of that is the Software Bill of Materials (SBOM), the ingredient list of software components inside a device. Under Section 524B of the FD&C Act, manufacturers of new 'cyber devices' are required to provide an SBOM as part of FDA premarket cybersecurity requirements, so they are increasingly available. We help you request, collect, and actually use SBOMs: mapping device components against newly disclosed vulnerabilities so that when the next widespread flaw lands, you can answer 'which of our devices are affected?' in minutes instead of weeks.

• Device hardening, credential changes, interface lockdown, and disabling unused services where supported
• Layered controls that contain the risk of vulnerabilities you can't remediate at the source
• Security-aware procurement, vendor questions on patching, lifespan, authentication, and SBOMs before purchase
• SBOM collection and use, mapping device components to emerging vulnerabilities for rapid impact analysis
• Alignment with FDA premarket cybersecurity requirements (Section 524B) and HHS 405(d) HICP practices

Done without disrupting clinical care

This is the constraint that governs everything we do. A crashed monitor can mean a missed alarm; an aggressive scan against an infusion pump is a patient-safety event, not an IT inconvenience. We treat medical-device security as a patient-safety discipline first and a security project second.

That's why our discovery is passive and agentless, our segmentation is validated against real clinical workflows before it goes live, and any active testing of a device happens only with explicit rules of engagement, a real-time stop procedure, and coordination with your biomedical and clinical engineering teams. We work alongside the people who keep the devices running, not around them.

Healthcare is the only industry we serve. We understand that the goal isn't a locked-down network, it's a safer one that still lets clinicians do their jobs. Every control we recommend is weighed against its impact on care, and we'd rather phase in a defensible improvement than break a workflow chasing a perfect one.

• Passive, agentless discovery that never interrogates a device in a risky way
• Segmentation and controls validated against real clinical workflows before deployment
• Active testing only under written rules of engagement with a real-time stop procedure
• Close coordination with biomedical and clinical engineering throughout the engagement
• Patient safety treated as the hard constraint, not an afterthought

How it works

1. 01

   Discover and inventory the device fleet

   Using passive, agentless techniques, we identify and fingerprint connected medical devices, infusion pumps, imaging modalities and PACS workstations, monitors, lab analyzers, and build an asset inventory enriched with make, model, OS, support status, and ePHI context. Nothing we do in this phase touches a device in a way that could affect patient care.

2. 02

   Assess and risk-rank

   We map known vulnerabilities, default and shared credentials, network exposure, and clinical impact to each device, then rank the fleet by likelihood and impact. You get a prioritized risk picture, not a flat list, that shows where the real exposure lives and where remediation effort will pay off most.

3. 03

   Design segmentation and compensating controls

   We design network segmentation and least-privilege policies from the real traffic observed during discovery, plus device hardening and compensating controls for everything that can't be patched. Every control is validated against actual clinical workflows with your biomedical and engineering teams before anything changes.

4. 04

   Implement clinically aware monitoring

   We stand up and tune continuous monitoring that understands DICOM, HL7, and device-management traffic, baselining normal behavior so abnormal activity stands out. This gives you early warning when an unpatchable device is compromised or misbehaving, and feeds directly into your existing SOC and incident response.

5. 05

   Govern procurement and sustain the program

   We help you build security into device procurement, vendor questions, SBOM collection, and lifecycle planning, and keep the inventory and controls current as devices are added, retired, or moved. The result is a living program that holds up to OCR scrutiny and the proposed Security Rule update, not a one-time snapshot.

Frameworks & standards we align to

Every finding maps back to the standards your auditors, board, and cyber-insurer already speak.

Frequently asked questions