Medical Device Cybersecurity: 2026 Complete Guide

Medical device cybersecurity is the practice of protecting connected diagnostic, therapeutic, and monitoring equipment – infusion pumps, imaging systems, pacemakers, patient monitors – from digital compromise across their entire lifecycle, from design to decommissioning. It matters because these devices sit on hospital networks, hold patient data, and in many cases deliver care directly to a human body. A vulnerability here is not an abstract data-breach risk; it can affect a diagnosis or a dose. Since 2023, the U.S. Food and Drug Administration has held legal authority to reject devices that lack an adequate cybersecurity plan, which has moved the topic from optional to mandatory for manufacturers and, by extension, for the hospitals that buy from them.

This guide explains what that means in practice: what regulators now expect, how the risks actually work, and what a hospital, clinic, or device maker should do about it. It is written for decision-makers and professionals rather than for the security team alone, and it is general education, not a substitute for a qualified audit or legal advice tailored to your specific environment and jurisdiction.

Quick answer: what changed and what you need to do

The single most important shift is regulatory. Under authority granted by the Consolidated Appropriations Act of 2023, the FDA can now refuse to accept a premarket submission for a "cyber device" if the manufacturer has not provided a plan to monitor, identify, and address vulnerabilities, a process to keep the device reasonably secure, and a software bill of materials. In plain terms: if you make a networked medical device, security is now part of getting to market, not a feature you add later.

For a hospital or health system, the practical consequence is that you should be demanding evidence of that security posture from your vendors – asking for the software bill of materials, patching commitments, and vulnerability disclosure practices before you sign – and you should be treating medical devices as a distinct, high-consequence class of asset on your network rather than folding them into general IT.

If you take three actions from this article, make them these: inventory every connected medical device you own and know what software runs inside it; segment those devices so a compromise on the general network cannot reach a patient monitor; and put contractual security expectations into every new purchase.

What "medical device cybersecurity" actually covers

A modern medical device is a computer with a clinical purpose. It runs an operating system, often an old and unpatched one; it may connect over Wi-Fi, Bluetooth, or a wired hospital network; it stores or transmits patient data; and it frequently cannot be taken offline for updates because it is in continuous clinical use. That combination – networked, data-bearing, safety-critical, and hard to patch – is what makes the field its own discipline rather than a subset of ordinary endpoint security.

The scope runs across the device lifecycle. At the design stage it means building security in: threat modelling, secure coding, and a bill of materials that documents every software component so a future vulnerability can be traced. During deployment it means secure configuration, network segmentation, and access control. Through the operational years it means monitoring, patching where possible, and mitigating where patching is not. At end of life it means decommissioning devices without leaving patient data or credentials behind, and understanding that a device the manufacturer no longer supports is a device you now have to protect yourself.

The stakes span two categories that regulators treat differently but that overlap in practice. One is patient safety: a device that behaves incorrectly, or can be made to behave incorrectly, can harm someone. The other is data: connected devices are a route into hospital networks that hold protected health information, which carries its own legal weight under HIPAA in the United States and equivalent regimes elsewhere. A ransomware crew that reaches a hospital rarely targets the pacemaker; it targets the network the pacemaker sits on, and the device becomes collateral, a foothold, or an outage.

FDA cybersecurity: the rules that now shape the market

The FDA's role is worth understanding even if you never file a submission, because it determines what your vendors are obligated to deliver.

The premarket requirement

Under section 524B of the Federal Food, Drug, and Cosmetic Act, added in 2023, manufacturers of "cyber devices" must include cybersecurity information in their premarket submissions. A cyber device, broadly, is one that includes software, can connect to the internet, and could contain a vulnerability. The manufacturer must show a plan to monitor and address post-market vulnerabilities, a process for making the device and related systems reasonably secure, and a software bill of materials covering commercial, open-source, and off-the-shelf components.

The FDA has published guidance on how it interprets these requirements – its document on cybersecurity in medical devices covering premarket submissions is the reference point, and you should read the current version directly rather than rely on summaries, because the agency updates it. You can find the FDA's own material on the FDA's medical device cybersecurity page, which is the authoritative source for current expectations, guidance documents, and safety communications.

The software bill of materials

The software bill of materials, or SBOM, deserves particular attention because it has become the connective tissue of the whole approach. An SBOM is an inventory of the software components inside a device – the libraries, frameworks, and off-the-shelf code it depends on. When a vulnerability is disclosed in a widely used component, an SBOM lets both the manufacturer and the hospital answer a question that used to take weeks: which of our devices contain the affected code? Without it, a hospital faces a new critical vulnerability with no way to know whether hundreds of its devices are affected or none of them are.

For buyers, the SBOM is now a reasonable thing to request as a condition of purchase. For manufacturers, it is no longer optional for covered devices. It is not a silver bullet – an SBOM tells you what is inside, not whether it is exploitable in your configuration – but it turns an unanswerable question into a manageable one.

Post-market responsibility

The FDA's expectations do not end at approval. Manufacturers are expected to run a coordinated vulnerability disclosure process, issue patches or mitigations, and communicate with customers when a serious flaw emerges. The agency, together with the Cybersecurity and Infrastructure Security Agency, publishes advisories about specific device vulnerabilities. CISA's advisories on medical and industrial devices are a practical early-warning channel worth monitoring if you operate a fleet of connected equipment.

How the attacks actually work, and how to defend

Understanding the threat at a defender's level, without a recipe for causing harm, is the point here.

Most real-world incidents affecting medical devices do not begin with an attacker deliberately targeting a specific insulin pump. They begin the way most breaches begin: a phishing email, a stolen credential, an exposed remote-access service, or an unpatched server. From there, an intruder moves laterally across a flat network. Medical devices become a problem in this scenario for three reasons. They are often unpatchable, so a known vulnerability stays open for years. They rarely run endpoint security software, so they are blind spots for the defence. And they cannot easily be isolated when trouble starts, because turning off a bank of patient monitors is not a decision an IT team can make alone.

The defensive priorities follow directly from that picture.

Know what you have. You cannot protect a device you have not inventoried. Many hospitals underestimate the number of connected devices on their network by a wide margin, because devices arrive through clinical departments rather than IT procurement. A current, accurate inventory – including what operating system and software each device runs – is the foundation everything else rests on.

Segment aggressively. The most effective single control is network segmentation: putting medical devices on their own isolated network zones so that a compromise elsewhere cannot reach them, and a compromise of one device cannot spread. This is the same logic that governs OT cybersecurity in industrial settings, and the parallel is exact. The device does not need to talk to the internet or to the finance department; the network should enforce that.

Patch what you can, mitigate what you cannot. Some devices can be updated; do it on the manufacturer's supported path. Many cannot be patched quickly, or at all, because an update requires re-validation or the vendor no longer supports the device. For those, the answer is compensating controls: tighter segmentation, monitoring for anomalous behaviour, and disabling unused services and ports.

Control access. Default and shared credentials remain a genuine problem in clinical equipment. Where the device permits it, change defaults, restrict administrative access, and use strong authentication for any remote maintenance connection. Remote vendor access, in particular, deserves scrutiny; it is convenient and it is a recurring source of exposure.

Monitor for the abnormal. Because these devices are predictable – a monitor talks to a small set of systems in a consistent pattern – deviation is a strong signal. Network monitoring tuned to medical device behaviour can catch a compromise that endpoint tools never would, precisely because you cannot install those tools on the device itself.

The vertical view: medical alongside automotive, energy, and OT

Medical device security is one instance of a broader problem: securing physical, safety-critical, long-lived connected systems that were not designed with modern threats in mind. Looking across verticals clarifies what is shared and what is specific.

In automotive, connected and increasingly autonomous vehicles face the same tension between safety and connectivity. A car is a fleet of computers on a network, some of which control braking and steering, and the industry has developed its own regulatory framework (UN Regulation No. 155 and the ISO/SAE 21434 standard) to force security into the design process. The parallel with the FDA's premarket approach is close: build security in, document it, monitor after sale.

In energy and critical infrastructure, the concern is availability and physical consequence. The controls that run a grid or a water system share the medical device's core problem – old software, hard to patch, catastrophic if manipulated. Our guides to energy cybersecurity and critical infrastructure cybersecurity go deeper on that terrain, and the defensive playbook – inventory, segment, monitor, control access – is recognisably the same.

What is specific to medical devices is the direct human contact and the data. An energy control system does not hold protected health information; a patient monitor does. A vehicle is owned by one person; a hospital device is used across hundreds of patients under a duty of care and a body of health-privacy law. That combination raises both the regulatory stakes and the ethical ones.

The common thread across all of these is OT compliance – the recognition that operational technology, whatever its industry, cannot be secured with the tools and assumptions built for office IT. If you manage any of these environments, the discipline transfers. Architectural ideas like SASE can help control how remote users and sites reach sensitive networks, though they are a complement to device-level segmentation, not a replacement for it.

Where automated analysis fits, honestly

Automated analysis enters this field from two directions, and it is worth being clear-eyed about both. On the defensive side, anomaly detection is genuinely useful for exactly the reason described above: medical devices behave predictably, and statistical modelling is good at flagging deviation from an established baseline across thousands of devices no human could watch. That is a real, current application, not a promise.

On the risk side, automated decision-making is increasingly built into the devices themselves – diagnostic algorithms, imaging analysis, decision support. That introduces new questions: how the model was trained, whether its inputs can be manipulated, and how it behaves when fed unusual data. Regulators and researchers are still developing the frameworks for evaluating these systems. For a hospital buying such a device today, the practical stance is to treat the analytical component as one more thing to ask hard questions about, not as a mark of quality in itself. A model is only as trustworthy as its training, its monitoring, and its maker's willingness to be transparent about both.

A practical roadmap for hospitals and clinics

If you run or advise a healthcare organisation, here is a sequence that reflects how this work actually gets done, rather than an idealised checklist.

Start with visibility, because you cannot manage risk you cannot see. Build the device inventory first, and keep it current as new equipment arrives. Tie each device to its software details and its risk to patients if compromised.

Then reduce the attack surface with segmentation. This is where most of the real risk reduction happens, and it can be done incrementally, starting with the highest-consequence devices. Isolate them, restrict what they can communicate with, and remove any internet exposure they do not need.

Bring procurement into the picture. Every new device is a decision you get to make with full information if you ask the right questions before signing: Does the vendor provide an SBOM? What is their patching commitment and for how many years? How do they handle vulnerability disclosure? What remote access do they require, and how is it secured? A vendor that cannot answer these clearly is telling you something.

Establish a monitoring and response capability that includes medical devices explicitly. Your incident response plan should account for the fact that you may not be able to simply pull a device offline, and clinical leadership needs to be part of those decisions before an incident, not during one.

Finally, treat this as an ongoing programme, not a project. Devices live for a decade or more; vulnerabilities are disclosed continuously; and support eventually ends. Plan for the day a critical device becomes unsupported while still in clinical use, because it will happen.

None of this replaces a formal risk assessment of your specific environment. The value of the roadmap is in the sequence and the questions; the execution depends on your devices, your network, and your clinical priorities, and it benefits from qualified assessment.

Frequently asked questions

What is medical device cybersecurity?

It is the protection of connected medical equipment – from imaging systems to implantable devices – against digital threats across their whole lifecycle. It combines patient-safety concerns, since these devices deliver or inform care, with data-protection concerns, since they sit on networks holding health information. It is a distinct discipline because the devices are networked, hard to patch, and safety-critical all at once.

Does the FDA require cybersecurity for medical devices?

Yes. Since 2023, the FDA has had legal authority to refuse a premarket submission for a connected medical device if the manufacturer does not include a plan to monitor and address vulnerabilities, a process to keep the device reasonably secure, and a software bill of materials. Check the FDA's current cybersecurity guidance for the precise, up-to-date requirements, as the agency revises them.

What is a software bill of materials (SBOM) and why does it matter?

An SBOM is an inventory of all the software components inside a device. It matters because when a new vulnerability is disclosed in a common component, the SBOM lets a manufacturer or hospital quickly determine which devices are affected. Without one, that question can be nearly impossible to answer across a large fleet.

Can medical devices get viruses or ransomware?

Yes, in effect. Many medical devices run standard operating systems that can be affected by the same malware as any computer. More commonly, ransomware reaches a hospital through ordinary routes and disrupts the network the devices depend on, taking devices offline even when they are not directly infected. Both scenarios are why segmentation matters so much.

Why are medical devices so hard to secure?

Three reasons combine. They often run old software that cannot be patched quickly, because updates require clinical re-validation. They rarely support endpoint security software, so they are blind spots. And they cannot easily be taken offline, because they are in continuous clinical use. Traditional IT security assumptions do not hold.

What is the single most effective control?

Network segmentation. Isolating medical devices into their own network zones limits both what can reach them and what a compromised device can reach. It is the control that delivers the most risk reduction per unit of effort, and it can be rolled out gradually, starting with the highest-consequence devices.

Are older, unsupported devices a serious risk?

Yes. When a manufacturer stops supporting a device, vulnerabilities in it stop getting patched, but the device may stay in clinical use for years. Those devices need extra compensating controls – tighter isolation and monitoring – and a plan for eventual replacement. Track which of your devices are approaching or past end of support.

What should a hospital ask a device vendor before buying?

Ask whether they provide an SBOM, what their patching commitment is and for how many years, how they handle vulnerability disclosure, and what remote access the device requires and how that access is secured. Clear answers signal a mature vendor; evasive answers are a warning.

How is medical device security different from general IT security?

General IT security assumes you can patch systems, install security software, and take devices offline when needed. Medical device security often cannot assume any of those. It sits closer to operational technology security, prioritising availability and safety, and it carries the added weight of patient care and health-privacy law.

Does HIPAA cover medical device cybersecurity?

HIPAA governs the protection of health information, so where a device stores or transmits protected health information, HIPAA obligations apply to how that data is safeguarded. It does not, on its own, cover the patient-safety dimension of device security, which is where FDA authority is central. The two regimes address different aspects of the same devices.

Who is responsible when a medical device is compromised?

Responsibility is shared and depends on the circumstances. Manufacturers carry post-market obligations to disclose and address vulnerabilities. Healthcare organisations are responsible for how they deploy, segment, monitor, and maintain devices on their networks. Liability in a specific incident is a legal question that depends on the facts, the contracts, and the jurisdiction, and it warrants qualified legal advice.

Where to start this week

If all of this feels large, narrow it to one concrete step: find out how many connected medical devices are actually on your network and what runs inside them. Almost every organisation that does this discovers more devices, and older software, than it expected. That inventory is what turns the rest of this guide from theory into a plan you can act on – it tells you what to segment first, which vendors to press for patches, and which devices to schedule for replacement.

From there, the medical device cybersecurity compliance tool on this page can help you structure a self-assessment against current expectations, and the critical infrastructure and OT cybersecurity guides extend the same defensive thinking into adjacent environments. Whatever you build, treat it as a living programme: the devices outlast the threats they were designed against, and the work is never quite finished.

This article is general education for defenders and decision-makers. It is not a security audit, legal advice, or incident response tailored to your environment. For obligations specific to your devices and jurisdiction, consult the FDA's current guidance and a qualified professional.