IoMT Security: Protecting the Internet of Medical Things
When it comes to IoMT security, it is critical to protect more than just your connected medical devices—otherwise, you are not seeing the whole picture.

Doc McConnell
Head of Policy and Compliance
TL;DR: IoMT security protects connected medical devices, the networks they run on, and the data they generate. But protecting only your medical devices leaves gaps. Real internet of medical things security covers every connected device on the network and goes deep into device firmware, not just network traffic. See what's actually inside a device and you see the risk it carries.
Connected medical devices have changed how care gets delivered. They've also changed how attackers get in. Most IoMT security programs stop at the medical devices themselves and at the network layer around them. That's not the whole picture, and the gap is where breaches happen.
This guide covers what IoMT security is, the threats that matter, why legacy devices are so exposed, how to run a risk assessment, and what FDA and HIPAA expect. Throughout, we make one point clear: you can't secure what you can't see, and you can't see everything from the network alone.
What is Internet of Medical Things (IoMT) security?
IoMT security is the practice of protecting connected medical devices, the networks they run on, and the data they generate from unauthorized access, disruption, and misuse.
The Internet of Medical Things, or IoMT, is the network of connected medical devices that collect, transmit, or act on patient data, often in real time. Think infusion pumps, patient monitors, imaging systems, implantable sensors, and wearables. IoMT is a healthcare-specific slice of IoT, and because it touches patient care directly, it carries stricter safety and compliance demands than ordinary IoT.
Here's where most definitions fall short. IoMT security is usually framed as a network problem: find the devices, segment them, watch the traffic. That work matters. But two devices with identical network behavior can carry wildly different risk depending on the software buried in their firmware. Strong internet of medical things security means seeing the device at both levels, on the network and inside the binary. For the foundation of this approach, see our overview of medical device security.
Why does protecting only your medical devices leave gaps?
Focusing IoMT security on connected medical devices alone leaves gaps, because attackers pivot through any weak device on the network, including cameras, printers, and building controls.
Imagine you have a platform that shows every IoMT device on your network. You can see the ones that look safe, and your team has walled off the ones that don't. Good. But what about the security cameras, connected building control systems, printers, and other IoT devices sharing that same network?
Without visibility into those devices, you can't be certain they won't be used to reach your patient data or your medical devices. An attacker who exploits a vulnerable camera may move laterally toward electronic health records, or worse. Because these devices interact with the physical world, a foothold on a hospital network can threaten physical harm, system shutdowns, and loss of life. Protecting critical devices means protecting all devices.
What are the primary cybersecurity threats to the Internet of Medical Things?
The primary IoMT threats are unauthorized access to legacy or unpatched devices, lateral movement across flat networks, data theft, ransomware, and tampering with device behavior or AI inputs.
IoMT devices are often deployed in high-stakes environments with little room for failure, which makes their security more complex than ordinary IT or general IoT. Most IoMT vulnerabilities trace back to a short list of weak spots: unencrypted wireless communication, outdated software, missing authentication, and flat networks that let a single compromised device reach everything else.
Two structural problems make it worse. The first is visibility. Many IoMT assets run without centralized oversight, so they never make it into an inventory. The second is architecture. Devices from many vendors sit on flat networks, mingling clinical and IT systems, so a compromised imaging system or infusion pump becomes a launchpad for a broader attack.
| IoMT threat | How it's used against you | What's at risk |
|---|---|---|
| Ransomware | Encrypts files or locks connected systems like infusion pumps until systems are restored or payment is made | Care delays, downtime, patient safety |
| Lateral movement | A compromised device on a flat network becomes a pivot point into clinical systems and records | Patient data, connected medical devices |
| Eavesdropping | Intercepts unencrypted Bluetooth or Wi-Fi traffic between devices and monitoring systems | Patient privacy, clinical data integrity |
| Botnet infection | Turns outdated-firmware devices into nodes for DDoS or further intrusion | Device availability, network health |
| Meddler-in-the-middle | Alters readings, manipulates commands, or harvests credentials in transit | Treatment decisions, credentials |
| Data poisoning | Feeds false data into AI diagnostic and monitoring models | Diagnostic accuracy, patient trust |
| Device hijacking | Takes remote control of a wearable, implant, or imaging system to extract data or pivot | Patient safety, data, network access |
For a deeper treatment of how to find and rank these issues across a fleet, see our guide to medical device vulnerability management.
How are vulnerabilities in medical devices exploited by hackers?
Hackers exploit IoMT vulnerabilities by targeting weak wireless links, unpatched software, and reused open-source components, then using one compromised device to move deeper into the network.
The attack usually isn't exotic. An attacker finds a device running a component with a known CVE, uses it to gain a foothold, and moves laterally because the network was flat and the device was trusted. The uncomfortable part is that the vulnerable component is often invisible to the hospital and sometimes to the manufacturer.
Here's a concrete example. Finite State analyzed a popular patient monitor used in healthcare facilities across North America. The device had only three vulnerabilities reported against it in the National Vulnerability Database. Through firmware analysis, we uncovered 1,164 known CVEs tied to the software components embedded in that firmware. [verify before publishing: confirm current figures against the original Finite State analysis and link the source post.]
That gap between what's reported and what's actually shipping is the point. A device can look clean at the network layer and still carry a thousand-plus exploitable components inside. This is why binary and firmware analysis is the first real step in IoMT security, not the last. You can't manage a vulnerability you never knew was there.
Why are legacy medical devices particularly vulnerable to cyber attacks?
Legacy medical devices are especially vulnerable because they run outdated software, often can't be patched, and may need manufacturer approval before any change, leaving known flaws exposed for years.
Medical devices have long service lives. A CT scanner or infusion pump can stay in clinical use for a decade or more, long after its underlying operating system stops receiving updates. Many implantables and constrained sensors can't be patched at all because of power limits, physical inaccessibility, or the risk of disrupting care.
That combination, long life plus limited patching, means a vulnerability disclosed today may sit exposed for years. The FDA and MITRE have flagged legacy device cyber risk as a sector-wide problem that needs coordinated management rather than one-off fixes. For manufacturers, the answer isn't patching faster. It's knowing exactly what's inside each device across its whole lifecycle so you can compensate, segment, or plan replacement with eyes open.
How do you perform a risk assessment for IoMT devices?
An IoMT risk assessment inventories every connected device, analyzes each device's firmware and software components, maps known vulnerabilities to real exploitability, and prioritizes fixes by clinical and network impact.
Network-only assessments tell you a device exists and how it behaves. They don't tell you what's inside it. A defensible IoMT risk assessment works at both layers. Here's a practical sequence.
| Step | What you do | Why it matters |
|---|---|---|
| 1. Inventory everything | Discover every connected device, medical and non-medical, on the network | You can't assess what you can't see; cameras and printers count |
| 2. Analyze firmware | Examine each device's firmware and generate a software bill of materials (SBOM) | Surfaces embedded components and CVEs invisible to network scans |
| 3. Map vulnerabilities | Match components against known CVEs and exploit intelligence | Turns a raw component list into a real risk picture |
| 4. Prioritize by exploitability | Rank findings by whether they're reachable and what they'd affect clinically | Focuses limited time on the risks that actually matter |
| 5. Remediate or compensate | Patch where you can; segment, monitor, or plan replacement where you can't | Legacy devices rarely allow a clean patch |
| 6. Repeat continuously | Re-assess as new CVEs land and software changes | Risk isn't a one-time snapshot; it shifts constantly |
Building an SBOM for each device is what makes steps 3 through 6 possible. It's the system of record for what actually shipped. See how SBOMs streamline medical device security for the mechanics.
What are the HIPAA and regulatory compliance requirements for IoMT devices?
IoMT compliance spans FDA premarket cybersecurity rules for manufacturers and HIPAA safeguards for the providers running the devices, with SBOMs, encryption, and vulnerability management now central to both.
Two regimes matter most in the United States, and they land on different parties. FDA Section 524B governs manufacturers bringing connected "cyber devices" to market. HIPAA governs the covered entities and business associates that operate those devices and hold patient data. A full IoMT program has to answer to both.
| Requirement | Who it applies to | What it expects | Source |
|---|---|---|---|
| FDA Section 524B | US medical device manufacturers | SBOM for all cyber devices, secure design, and a postmarket vulnerability management and patching plan | FDA |
| NTIA SBOM minimum elements | Anyone producing an SBOM | Component names, versions, suppliers, dependency data, and unique identifiers in a machine-readable format | NTIA |
| HIPAA Security Rule | Providers and business associates (ePHI) | Administrative, physical, and technical safeguards for electronic protected health information | HHS |
| NIST Cybersecurity Framework | All sectors, widely used in healthcare | A voluntary structure for assessing and managing cybersecurity risk | NIST |
Two developments are worth watching. On the manufacturer side, an SBOM is now a legal requirement for cyber devices under Section 524B(b)(3), not a nice-to-have. On the provider side, HHS has proposed the most significant HIPAA Security Rule update in over a decade, which would make safeguards like encryption of ePHI, multi-factor authentication, and network segmentation mandatory rather than optional. [verify before publishing: confirm final-rule status and effective date; as of this writing the update is proposed, not final.]
For manufacturers mapping their program to the FDA's expectations, start with our breakdown of FDA medical device regulations, then go deeper on what the FDA's final guidance says about SBOMs and how to put Section 524B into practice.
What are the current trends and future outlook for medical device cybersecurity?
Medical device cybersecurity is moving from network monitoring toward device-level transparency, with SBOMs, firmware analysis, and AI-input integrity becoming baseline expectations for manufacturers and providers alike.
The direction is clear. Regulators are shifting from "tell us what's in your device" to "show us you can manage what's in your device across its lifecycle." SBOMs are becoming the connective tissue between design, submission, and postmarket support. Firmware transparency is moving from advanced practice to baseline expectation.
AI raises the stakes again. As IoMT devices feed data into AI tools for triage, imaging, and treatment recommendations, protecting the integrity of that data becomes as important as securing the device itself. Poisoned inputs from an insecure sensor can quietly degrade a model that clinicians rely on. For our view on where this is heading, see what's next for medical device cybersecurity.
Seeing the whole picture
IoMT security is complex, and traditional network defenses alone no longer cover it. Two things decide whether you're actually protected: whether you can see every connected device, and whether you can see inside each one. Device visibility tells you what's on the network. Firmware analysis tells you what risk it carries. You need both.
Seeing only part of the picture leaves healthcare organizations, and the people they serve, more exposed than they realize. If you want to see how device-level transparency changes the way you manage IoMT risk, request a demo or read our resource on protecting medical devices from cyber exploitation.