Medical Device Cybersecurity: Risks, Rules & Defense

What Is Medical Device Cybersecurity?

Medical device cybersecurity is the ongoing process of monitoring, identifying, and addressing vulnerabilities in networked clinical equipment throughout its operational lifecycle. For hospitals, clinics, and specialty practices, that definition now covers a substantial share of the clinical environment: infusion pumps, imaging systems, patient monitors, ventilators, insulin pumps, and dozens of other connected devices that transmit patient data and, in many cases, control clinical functions directly.

These devices are collectively called the Internet of Medical Things (IoMT). The World Health Organization estimates there are more than 2 million distinct types of medical devices in use 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 remain on clinical networks for years, sometimes decades, long past the point when manufacturers provide software updates.

Attackers understand this gap well. Medical records sell for up to $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 data loss: 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 data security makes medical device cybersecurity a board-level concern, not just an IT department problem.

This guide covers the threat environment facing connected medical devices, the regulatory requirements from the FDA and HIPAA, and the practical steps your organization needs 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 a workstation 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: 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 disabled payment processing across hundreds of U.S. hospitals and clinics for weeks, resulting in approximately $874 million in direct losses according to 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 the mitigation strategies most 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 affecting healthcare organizations. For a detailed look at how nation-state actors have exploited this vector, see our analysis of the Iran-backed wiper attack targeting Stryker MedTech in 2026.

Which Medical Devices Carry the Highest Risk?

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

Imaging systems including 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, creating an attack surface if those update channels lack proper authentication. Unauthorized access to an infusion pump has direct patient safety implications. 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 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 including check-in kiosks, telehealth endpoints, and 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 is the foundation of any compliance effort.

FDA Section 524B 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; maintain a coordinated vulnerability disclosure policy that allows security researchers to report issues; monitor postmarket cybersecurity risks; and deploy patches or mitigations within a reasonably justified timeframe.

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. NIST SP 800-82 Rev. 3 provides specific guidance on securing operational technology environments, including medical devices classified as OT assets, with a risk management framework that maps directly to the controls 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 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.

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 should 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 after deployment.

Business Associate Agreements (BAAs) are required under HIPAA for any vendor with access to ePHI. 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, treat that as a procurement red flag, not a negotiating point.

Just-in-time access provisioning replaces 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. Vendor accounts with standing access are among the most common targets in supply chain intrusion campaigns.

For organizations evaluating zero trust architectures as an extension of these controls, our analysis of zero trust and secure data movement covers how that model applies to constrained devices that cannot run standard endpoint agents. Our guide to EDR, MDR, and XDR explains what to look for when evaluating monitoring providers for a healthcare environment.

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 exceeds 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 HIPAA compliance checklist for small practices provides a structured framework for maintaining this documentation across your entire environment.