Medical Device Cybersecurity: Risks, Rules & Defense

What Is Medical Device Cybersecurity — and Why Healthcare Practices Need a Plan Now

Hospitals, clinics, and specialty practices now operate networks of connected equipment — infusion pumps, imaging systems, patient monitors, ventilators, insulin pumps, and dozens of other devices that transmit sensitive data and control clinical functions. The FDA defines medical device cybersecurity as the ongoing process of monitoring, identifying, and addressing vulnerabilities in connected devices throughout their operational lifecycle. These devices — collectively called the Internet of Medical Things (IoMT) — now represent one of the fastest-growing attack surfaces in healthcare.

The scale of the problem is striking. The World Health Organization estimates there are more than 2 million distinct types of medical devices globally, and a growing share of them are networked. Unlike traditional IT assets, most were not designed with security as a primary engineering requirement. Many run proprietary firmware or legacy operating systems that cannot receive standard security patches. They sit on clinical networks for years — sometimes decades — long past the point when the manufacturer provides software updates.

Attackers understand this gap well. Medical records sell for $100–$1,000 each on dark web markets — far more than credit card data — which makes healthcare a financially attractive target regardless of organization size. The consequences extend well beyond a data breach: a ransomware infection that locks imaging equipment forces diagnostic delays, while a compromised infusion pump can affect medication delivery directly. That intersection of patient safety and cybersecurity makes this a board-level concern, not just an IT problem.

This guide covers the threat environment, the regulatory requirements from the FDA and HIPAA, and the practical steps your organization should take to build a defensible program. For a broader HIPAA foundation, see our HIPAA cybersecurity requirements guide.

The Threat Environment Facing Connected Medical Devices

Medical devices present a uniquely difficult security challenge because they sit at the intersection of operational technology (OT) and healthcare IT — two disciplines with different priorities, different patching cycles, and different risk tolerances. Security controls that work well for a managed workstation often cannot be applied to an infusion pump or an MRI controller without clinical validation and vendor approval.

Legacy Software and Unpatched Firmware

A significant share of networked medical devices still run Windows 7, Windows XP Embedded, or proprietary operating systems that no longer receive security updates. When a vulnerability is publicly disclosed, IT teams can patch workstations within days. Patching a networked ventilator or a radiation therapy system is a fundamentally different process — it may require FDA clearance review, vendor-coordinated deployment, and downtime scheduling that stretches the patching window months into the future.

The MITRE ATT&CK for ICS framework documents the tactics adversaries use against industrial control and embedded systems, many of which apply directly to medical devices. Techniques such as "Exploit Public-Facing Application" (T0819) and "Supply Chain Compromise" (T0862) have been observed in healthcare-targeted attacks. According to Forescout research, routers connecting medical devices to clinical networks account for roughly half of the most severe vulnerabilities found in IoMT environments — making network access controls a first-priority defensive measure.

Ransomware as the Dominant Threat Vector

Ransomware groups target healthcare because organizations under pressure to restore clinical operations are more willing to pay. The February 2024 Change Healthcare attack — which disabled payment processing across hundreds of U.S. hospitals and clinics for weeks — resulted in approximately $874 million in direct losses, according to public reporting from UnitedHealth Group. When a threat actor gains initial access through a phishing email or an unpatched perimeter device, they pivot laterally across the network toward medical devices and building systems: assets that are harder to restore quickly and create maximum operational pressure.

The Verizon 2025 Data Breach Investigations Report identifies healthcare as one of the most frequently targeted sectors, with system intrusion and basic web application attacks accounting for the majority of confirmed incidents. Our guide to ransomware attacks covers the full attack chain and mitigation strategies relevant to clinical environments.

Supply Chain and Third-Party Risk

Medical device manufacturers, remote monitoring vendors, and biomedical engineering firms all require network access to service equipment. Each of those connections extends your attack surface. Trusted software update mechanisms that deliver firmware improvements can also be turned into attack vectors — a pattern documented in supply chain incidents that have affected healthcare organizations. For a look at how nation-state actors exploit this vector against medical technology companies, see our analysis of the Iran-backed wiper attack targeting Stryker MedTech in 2026.

Which Medical Devices Are Most at Risk

Not all connected devices carry equal risk. Understanding which device categories present the greatest exposure helps security and biomedical teams prioritize limited resources effectively.

Imaging systems — MRI machines, CT scanners, ultrasound units, and X-ray systems — communicate via DICOM (Digital Imaging and Communications in Medicine) and connect to Picture Archiving and Communication Systems (PACS) and Radiology Information Systems (RIS). These devices frequently run legacy operating systems and hold large volumes of patient data. A compromise of a PACS server can expose thousands of patient imaging records simultaneously, and DICOM traffic traversing insufficiently segmented networks is readable without additional authentication.

Infusion pumps account for approximately 38% of the typical hospital's connected device footprint. Many support wireless communication for drug library updates, which creates an attack surface if those update channels lack proper authentication. Unauthorized access to an infusion pump has direct patient safety implications — researchers have demonstrated the technical feasibility of manipulating drug delivery parameters remotely, and the FDA has issued safety communications on specific pump models with identified vulnerabilities.

Insulin pumps and implantable devices with wireless connectivity present a different risk profile: they operate outside hospital network perimeters and depend almost entirely on manufacturer security controls. Security researchers have demonstrated that certain older wireless-enabled insulin pump models could be manipulated to alter drug delivery by an attacker within radio range. While real-world exploitation of implantable devices remains rare, the FDA has issued safety communications on specific device models as vulnerabilities have been discovered.

Laboratory information systems and analyzers communicate using HL7 (Health Level Seven) messaging standards for result transmission. These systems often bridge clinical and administrative networks, making them a useful pivot point for attackers who have established an initial foothold. Administrative medical devices — check-in kiosks, telehealth endpoints, badge readers — carry lower direct clinical risk but frequently receive less security attention, making them viable initial access points for lateral movement. Our healthcare data breach prevention guide covers how attackers move between device categories once initial access is established.

FDA and HIPAA Regulatory Requirements for Medical Device Security

Medical device cybersecurity operates under two overlapping regulatory frameworks: FDA guidance governing device manufacturers and HIPAA requirements governing covered entities and their business associates. Understanding which requirements apply to your organization — and where the frameworks intersect — is the foundation of any compliance effort.

FDA Cybersecurity Requirements

The FDA's authority over medical device cybersecurity expanded substantially with the passage of Section 524B of the Federal Food, Drug, and Cosmetic Act (FD&C Act), enacted as part of the Consolidated Appropriations Act of 2023. Under this law, manufacturers of internet-connected "cyber devices" must:

• Submit a Software Bill of Materials (SBOM) identifying all commercial, open-source, and off-the-shelf software components in premarket submissions
• Maintain a coordinated vulnerability disclosure policy that allows security researchers to report issues responsibly
• Monitor postmarket cybersecurity risks and deploy patches or mitigations within a reasonably justified timeframe
• Provide reasonable assurance that devices and related systems are secure throughout their designed useful life

For healthcare delivery organizations, the practical implication is that you should now contractually require manufacturers to provide SBOMs, disclose vulnerabilities promptly, and deliver patches on defined timelines. Purchasing decisions should include an evaluation of the manufacturer's Security Development Lifecycle (SDL) practices before contracts are signed.

For operational technology environments, NIST SP 800-82 Rev. 3 provides specific guidance on securing industrial control systems, including medical devices classified as OT assets. Its risk management framework maps directly to the controls your biomedical engineering and IT security teams need to implement together.

HIPAA Security Rule Applicability

The HIPAA Security Rule (45 CFR Part 164) requires covered entities to implement administrative, physical, and technical safeguards for electronic protected health information (ePHI). Medical devices that store, process, or transmit ePHI are fully in scope — which covers most networked clinical devices.

Key provisions include access control (§164.312(a)), audit controls (§164.312(b)), integrity controls (§164.312(c)), and transmission security (§164.312(e)). A thorough HIPAA security risk assessment must address your connected device inventory, not just workstations and servers. The HHS Office for Civil Rights (OCR) has cited inadequate device security controls in several high-profile enforcement actions, with penalties ranging from $65,000 to $4.3 million for covered entities that failed to implement proper safeguards for medical devices containing ePHI. Our guide on HIPAA compliance for dental offices illustrates how these obligations apply even in smaller clinical settings.

Network Segmentation: The Highest-Value Technical Control

Of all the technical controls available for medical device cybersecurity, network segmentation consistently delivers the greatest risk reduction per dollar invested. When medical devices share a flat network with workstations, a single compromised endpoint gives an attacker a direct path to every connected device in the facility — including those directly involved in patient care.

Effective segmentation places medical devices in dedicated network zones, separated from the corporate network, guest Wi-Fi, and clinical workstations. Firewalls between zones enforce allow-list policies: the infusion pump management server may communicate with infusion pumps; nothing else can initiate connections to those devices. Any traffic that deviates from that baseline triggers an alert.

A Practical Tiered Segmentation Model

Organizing devices by risk profile makes policy management tractable as your device inventory grows:

• Tier 1 — High-risk, high-impact: Devices directly involved in treatment delivery (infusion pumps, ventilators, anesthesia machines). Maximum isolation, deny-all-inbound by default, with access permitted only to the minimum required management systems.
• Tier 2 — Moderate-risk: Diagnostic and imaging devices (MRI, CT, ultrasound, X-ray). Communication restricted to the PACS, RIS, and vendor support channels over monitored sessions.
• Tier 3 — Lower-risk: Administrative medical devices (check-in kiosks, badge readers, telehealth endpoints). Restricted to necessary services, isolated from Tier 1 and Tier 2 device zones.

Segmentation must be validated through regular penetration testing and firewall rule audits. A rule set that was accurate at deployment becomes porous as devices are added and network changes accumulate. For organizations evaluating zero trust architectures as an extension of segmentation, our analysis of zero trust and secure data movement covers how that model applies to constrained devices that cannot run standard endpoint agents.

Managed Detection and Response (MDR) services play a key supporting role in monitoring segmented networks for anomalous device behavior — particularly for smaller organizations without a dedicated security operations team. Our guide to MDR services for small businesses explains what to look for when evaluating providers for a healthcare environment.

Managing Vendor and Third-Party Access to Medical Devices

Every vendor that connects to your medical device network — whether for remote diagnostics, software updates, or biomedical maintenance — extends your attack surface. Third-party access is one of the most frequent entry points in healthcare breaches, and medical device vendors are often granted broad, persistent access that receives inadequate oversight.

Pre-purchase security assessments: Evaluate manufacturers against the FDA's premarket cybersecurity guidance before procurement. Request SBOMs, vulnerability disclosure policies, historical CVE disclosure records, and patching commitments in writing as part of the purchasing process. A vendor unwilling to provide this documentation during sales discussions is unlikely to be a reliable security partner post-deployment.

Business Associate Agreements (BAAs): Any vendor with access to ePHI must sign a BAA under HIPAA. This includes vendors who receive device telemetry containing patient identifiers, even if their primary service is technical maintenance rather than data handling. If a vendor resists signing a BAA, that is a procurement red flag, not a negotiating point.

Just-in-time access provisioning: Replace persistent vendor VPN credentials with time-limited, session-specific access that requires approval, is scoped to only the devices being serviced, and generates a full audit log. Persistent credentials that are rarely used still represent active attack surface — and vendor accounts with standing access are among the most common targets in supply chain intrusion campaigns.

Active vendor session monitoring: Review logs from all remote vendor sessions. Anomalous activity during a vendor session — lateral movement, unexpected data transfers, or access to devices outside the approved scope — should trigger immediate investigation. The NIST incident response framework provides structured guidance on escalating and containing vendor-originated incidents within a defined response process.

Incident Response When a Medical Device Is Compromised

When a medical device is compromised — or suspected to be compromised — the response process differs from a standard IT incident in ways that matter clinically. Patient safety takes priority over speed of containment. Decisions about isolating or shutting down a device must involve clinical leadership, not just IT security.

The first decision point is containment without clinical disruption. Isolating a network segment hosting infusion pumps requires coordination with nursing staff and pharmacy to confirm patients are not immediately affected. Device-specific playbooks should define who has clinical authority to approve isolation, what the manual or alternate-device workaround is, and how long that workaround can be safely maintained before clinical risk escalates beyond acceptable limits.

HIPAA breach notification obligations require covered entities to notify affected individuals within 60 days of discovering a breach involving ePHI. If the device incident involves ePHI — which applies to most networked clinical devices — the notification clock starts at discovery, not at containment. Careful timeline documentation from the moment of initial detection is essential for both regulatory compliance and any subsequent OCR investigation. The 60-day window is firm; organizations that cannot demonstrate when discovery occurred face an unfavorable presumption in enforcement proceedings.

After an incident, conduct a root cause analysis that addresses how the device was initially accessed, how long it was compromised before detection, and which control gaps allowed the incident to reach that point. Feed those findings directly into your risk assessment and use them to drive prioritization in your security roadmap. This continuous improvement cycle is the operational core of a mature medical device cybersecurity program. Our NIST incident response framework guide provides a structured starting point for formalizing this process across your entire environment.