Medical Devices and Clinical Technology: FDA Cybersecurity Rules, Legacy Devices and Segmentation

Rule versions described: FD&C Act section 524B (21 U.S.C. 360n-2), added by section 3305 of the Consolidated Appropriations Act, 2023 (Pub. L. 117-328, signed December 29, 2022, effective March 29, 2023); 21 U.S.C. 331(q)(3); FDA's refuse-to-accept notice, 88 FR 19148 (March 30, 2023); FDA premarket cybersecurity guidance of February 3, 2026 (docket FDA-2021-D-1158); FDA postmarket cybersecurity guidance of December 27, 2016; the Quality Management System Regulation, 89 FR 7496 (February 2, 2024, effective February 2, 2026); the HIPAA Security Rule, 45 CFR Part 164 Subpart C as amended through the 2013 Omnibus Rule (current eCFR text read October 28, 2026); and the Security Rule proposal at 90 FR 898 (January 6, 2025), which is still a proposal. These rules and guidance documents change. Check the regulator's current text before relying on any detail here.

Why connected devices are different

Most of this module treats health care security as an information problem: keep protected health information (PHI) away from people who should not have it, keep it available to the people who need it, and keep it accurate. Medical devices add a fourth question that office IT rarely faces: can this weakness hurt a patient's body? An infusion pump that delivers the wrong dose, an insulin pump that stops delivering insulin, a monitor that shows normal vital signs while a patient is crashing, or an imaging system that goes dark during a stroke workup are all safety events. That changes who has to be involved, how fast anyone can move, and what "fixing it" means.

FDA has said for more than a decade that medical device cybersecurity is a shared job. Its device cybersecurity page tells health care delivery organizations to evaluate their network security and protect hospital systems, and says manufacturers and hospitals both need mitigations in place to address patient safety risks and keep devices performing as intended.⁸ Five features explain why the job is shared and why it is hard.

Patient safety comes first, even before security

In ordinary IT, the safest response to a dangerous flaw is often to pull the system offline. For a device attached to a patient, pulling it offline can be the dangerous choice. That is why FDA and device makers frame cybersecurity risk in terms of patient harm. FDA's 2016 postmarket guidance ties its whole approach to the device's "safety and essential performance," meaning the functions that must keep working for the device to do its job.⁹ When Abbott shipped a security firmware update for implanted pacemakers in 2017, the doctor letter told physicians to weigh pacemaker dependence, device age and patient preference, and to update pacing-dependent patients only where temporary pacing and generator replacement were readily available.¹⁰ That is what security looks like when the computer is inside someone's chest.

Long service lives

A laptop is replaced every three to five years. A CT scanner, MRI, infusion pump fleet, central monitoring station or lab analyzer may stay in service for a decade or more, because it is expensive, because it was validated as a system, and because it works. The software inside is usually frozen at the version the maker validated. The International Medical Device Regulators Forum (IMDRF), the group of national device regulators that includes FDA, defines a "legacy" device as one that "cannot be reasonably protected against current cybersecurity threats," and stresses that age alone does not decide it: a fairly new device can be legacy if its components are no longer supported.¹¹ Operating system support ends on its own clock. Microsoft ended support for most editions of Windows 10 on October 14, 2025, with paid Extended Security Updates as the only bridge for many organizations,¹² while its Internet of Things (IoT) long-term editions, the kind often built into equipment, keep a 10-year lifecycle.¹³ A device built on an ordinary desktop edition can outlive its operating system by years.

Regulatory change control

A device maker cannot change device software the way a software company pushes an app update. Changes go through the maker's quality system: design controls, verification, validation, risk analysis and documentation. Some changes need a new FDA premarket submission. FDA's current guidance explains that a modification that may affect cybersecurity (for example, changed authentication or encryption, new connectivity, or a changed update mechanism) calls for full cybersecurity documentation in a new submission, while changes unlikely to affect cybersecurity need much less.¹⁴ The 2016 postmarket guidance, by contrast, treats most security-only patches as routine updates that FDA does not need to be told about in advance.¹⁵ Even so, a patch must be tested by the maker against the device's clinical functions before it ships. This is the root of a common hospital complaint: "Microsoft released the patch months ago, why can't we install it on the scanner?" The honest answer is that the scanner's maker has to validate it first, and hospitals that install unvalidated software can create the very safety problem they are trying to prevent.

Vendor-managed patching and vendor remote access

Many devices can only be patched by the maker or its authorized service staff. Many makers also service equipment remotely, through a remote-access connection into the hospital network. That is good for uptime and dangerous if the connection is always open, shared among many technicians, or protected by a single password. HICP, the HHS voluntary practices guide, tells larger organizations to tie device authentication to enterprise identity systems, give vendors unique credentials, and require multifactor authentication for remote access.¹⁶ The Contec CMS8000 case later in this lesson shows the other side of the same coin: some devices quietly reach out to the internet on their own.¹⁷

Shared responsibility among the maker, the hospital and clinical engineering

Three groups share the work, and each one can see something the others cannot.

• The maker (manufacturer, sometimes called the MDM) designs the device, documents its security in the FDA submission, monitors for new vulnerabilities, writes and validates patches, publishes security notices and decides when it will stop supporting the product.
• The health care delivery organization (HDO: the hospital, clinic, imaging center or home health agency) buys the device, puts it on a network, decides who can use it, watches the network, runs the HIPAA risk analysis and decides whether to keep using a device after support ends.
• Clinical engineering (biomedical engineering, "biomed") sits between the two. Biomedical equipment technicians and clinical engineers maintain the device, track preventive maintenance and recalls, coordinate service with the maker, and usually own the equipment inventory. In many hospitals they report to facilities or operations, not to IT, which is one reason device security falls through cracks.

The Health Sector Coordinating Council (HSCC), the private-sector partner group for HHS, built its Medical Technology and Health IT Joint Security Plan around this split. Version 2.0, released in March 2024, is a lifecycle reference guide that sets expectations for makers (build security in, communicate vulnerabilities) and for providers (handle vulnerability disclosures, apply patches, plan for end-of-support products).¹⁸ The IMDRF legacy device paper puts it plainly: cybersecurity is shared, and once a maker reaches end of support, responsibility shifts primarily to the health care provider.¹¹

Devices also hold ePHI

Many devices store or transmit patient names, record numbers, images, readings and dates. An ultrasound cart, a dialysis machine, a digital radiography system or a bedside monitor that keeps trend data is a container of ePHI, and the HIPAA Security Rule does not exempt it because it is a medical device. The Security Rule's device and media controls standard, 45 CFR 164.310(d)(1), requires policies for the receipt and removal of hardware and electronic media that contain ePHI, including disposal and media reuse.¹⁹ A scanner traded in to a vendor with a full hard drive is a reportable problem waiting to happen. The HIPAA section below returns to this.

FDA's legal authority over device cybersecurity

Before 2023: safety authority and guidance

FDA regulated device cybersecurity long before Congress wrote the word into the statute. Its authority came from the general requirement that devices be reasonably safe and effective, from the quality system rules that govern design and manufacturing, and from postmarket rules on recalls, corrections and reports. FDA used guidance to explain how it applied those rules to software security. Its June 13, 2013 safety communication, "Cybersecurity for Medical Devices and Hospital Networks," was an early public warning to both makers and hospitals.⁸ Its first final premarket guidance, issued October 2, 2014, asked makers to include a cybersecurity hazard analysis, a matrix tracing risks to controls, and a plan for providing updates and patches across the device's life.²⁰ The postmarket guidance followed at the end of 2016.²¹

Guidance does not bind the public, though, and FDA could not refuse a submission simply because it lacked an SBOM or a vulnerability plan. Congress changed that in the omnibus spending law at the end of 2022.

Section 524B, "Ensuring Cybersecurity of Devices"

Section 3305 of the Consolidated Appropriations Act, 2023 (Public Law 117-328, division FF, title III) added a new section 524B to the Federal Food, Drug, and Cosmetic Act (FD&C Act). It is codified at 21 U.S.C. 360n-2. The President signed the law on December 29, 2022, and the section took effect 90 days later, on March 29, 2023.¹⁸

Section 524B(a) says that a person who submits a premarket application or submission for a "cyber device" must include the information FDA requires to show the device meets the cybersecurity requirements in subsection (b). FDA's current guidance lists the submission types covered: 510(k) premarket notifications, premarket approval applications (PMA), product development protocols, De Novo requests and humanitarian device exemptions.¹⁴

What counts as a "cyber device"

Section 524B(c) defines a cyber device as a device that (1) includes software validated, installed or authorized by the sponsor as a device or in a device; (2) has the ability to connect to the internet; and (3) contains any technological characteristics validated, installed or authorized by the sponsor that could be vulnerable to cybersecurity threats.¹ All three parts must be met.

The second part matters most in practice, and FDA reads it broadly. Its guidance says the "ability to connect to the internet" covers connections that are intentional or unintentional, by any means, and gives examples: network, server and cloud connections; radio links such as Wi-Fi, cellular and Bluetooth; magnetic inductive communication; and hardware connectors such as USB, Ethernet and serial ports.¹⁴ Under that reading, a device does not have to be designed as an "internet device" to be covered. If it has a USB port or an Ethernet jack and software inside, a sponsor should assume FDA will treat it as a cyber device. Section 524B(d) lets FDA exempt devices or categories of devices by publishing a list in the Federal Register.¹ FDA's FAQ invites makers that are unsure whether a product is a cyber device to contact the agency.²²

The four statutory requirements

Section 524B(b) requires the sponsor of a cyber device to do four things.¹

1. A postmarket vulnerability plan. Submit a plan to monitor, identify and address, as appropriate, postmarket cybersecurity vulnerabilities and exploits, "including coordinated vulnerability disclosure and related procedures." Coordinated vulnerability disclosure (CVD) means the maker has a way for outside researchers and customers to report flaws, and a process to confirm, fix and announce them in an orderly way.
2. Processes that give reasonable assurance of cybersecurity. Design, develop and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure, and make available postmarket updates and patches to the device and related systems. The statute sets two speeds: updates for known unacceptable vulnerabilities on a reasonably justified regular cycle, and, as soon as possible out of cycle, updates for critical vulnerabilities that could cause uncontrolled risks.
3. A software bill of materials. Provide FDA an SBOM, "including commercial, open-source, and off-the-shelf software components."
4. Anything else FDA sets by regulation. Comply with other requirements the Secretary may set by regulation to demonstrate reasonable assurance that the device and related systems are cybersecure. As of October 28, 2026, this lesson found no FDA regulation issued under this clause.

Two more pieces give the section teeth. First, Congress made it a prohibited act to fail to comply with any requirement under 524B(b)(2), the "processes and patches" duty. That provision is 21 U.S.C. 331(q)(3).²³ Prohibited acts are what FDA enforces through warning letters, seizures, injunctions and, in serious cases, prosecution. Second, FDA's guidance treats cybersecurity as part of its basic safety and effectiveness decision: in a 510(k), FDA considers changes in the environment of use and new vulnerabilities, and a device whose cybersecurity risks are not adequately addressed may be found not substantially equivalent to its predicate.¹⁴

The refuse-to-accept policy

When 524B took effect, FDA gave industry a short runway. Its guidance "Cybersecurity in Medical Devices: Refuse to Accept Policy for Cyber Devices and Related Systems Under Section 524B of the FD&C Act," announced in the Federal Register on March 30, 2023 (88 FR 19148), said FDA generally would not refuse to accept a submission solely because 524B information was missing before October 1, 2023, and would work with sponsors interactively in review. Beginning October 1, 2023, FDA said it may issue refuse-to-accept (RTA) decisions for cyber device submissions that lack the required information.² An RTA decision stops the clock: the submission is not reviewed at all until the sponsor fixes it. FDA's FAQ adds that from October 1, 2023, 510(k) submissions generally had to be sent electronically through FDA's eSTAR template, and an incomplete cybersecurity section can put a submission on technical screening hold.²²

What 524B does not do

Readers often assume 524B fixed the installed base. It did not. FDA's FAQ says the requirements do not apply to submissions made before March 29, 2023, and that a previously authorized device is covered only when a change to it requires a new premarket submission.²² The statute's construction clause says nothing in it limits FDA's existing authority over device safety and effectiveness, including the cybersecurity of devices cleared or approved before December 29, 2022,¹ so FDA can still act on older devices through recalls, safety communications and its postmarket rules. But there is no statutory clock forcing a maker to patch, support or replace a 2015 infusion pump that is still on a hospital floor. That gap is the subject of the legacy device section and one of the hard questions.

Section 524B also does not regulate hospitals. It governs device sponsors. A hospital's own security duties come from HIPAA, from state law, from contracts and from accreditation, not from 524B.

FDA's premarket cybersecurity guidance

The statute is short. The detail lives in FDA's premarket guidance, which tells makers what FDA expects to see in a submission and how FDA reviewers will read it. Guidance is not binding law, but a sponsor that ignores it should expect questions, holds or an RTA decision. Hospitals should read it for a different reason: it describes the security documentation a maker should already have, which is exactly what a buyer should ask for.

The versions, in order

The title change in 2026 is not cosmetic. On February 2, 2024, FDA published a final rule (89 FR 7496) that renamed its device quality rule the Quality Management System Regulation and incorporated the international standard ISO 13485:2016 by reference, effective February 2, 2026.⁴ The February 2026 guidance explains that the QMSR replaces most of the old 21 CFR Part 820 text and that ISO 13485's requirements, taken as a whole, are substantially similar to the old rule.¹⁴ For cybersecurity, the point is that security work is now expected to live inside the same quality management system that governs every other design and production decision, with the same records and the same inspection exposure. ISO 13485 is a paid standard; this lesson describes it rather than quoting it.

The secure product development framework

FDA encourages makers to use a secure product development framework (SPDF): a set of processes that build security into every stage of design, development, release, support and retirement. FDA says an SPDF can help a maker satisfy the QMSR, and that other approaches may also satisfy it.¹⁴ The guidance organizes the SPDF into three parts.

• Security risk management. Threat modeling across the whole system (the device plus the networks, servers, apps and update services it connects to), with an assumption that networks are hostile. A cybersecurity risk assessment that focuses on exploitability rather than the statistical probability used in ordinary safety risk analysis, documents risk before and after mitigation, and shows how security risks feed into the safety risk file.¹⁴
• Security architecture. Documentation of how the system is built and where data and commands flow. FDA asks, at minimum, for a global system view, a multi-patient harm view (how one attack could hurt many patients at once), an updateability and patchability view, and security use case views.¹⁴
• Cybersecurity testing. Evidence such as penetration testing, fuzz testing, software composition analysis and static and dynamic code analysis. Penetration test reports should document the testers' independence, scope, duration, methods and findings.¹⁴

Labeling and transparency: what the buyer should receive

The guidance section most useful to hospitals is its list of labeling recommendations, because labeling is what the customer actually gets. FDA recommends that makers give users, among other things:¹⁴

• the security controls recommended for the intended environment (for example anti-malware, firewalls and password rules), with diagrams detailed enough to implement them;
• a list of network ports and other interfaces that send or receive data, with each port's function, direction and approved endpoints;
• instructions for secure network deployment and servicing, and for responding to vulnerabilities or incidents;
• a machine-readable SBOM kept continuously available, and a description of how users get authorized software updates and learn they were released;
• how the device detects and logs security events, how it is backed up and restored, and what its secure default configuration is;
• known or anticipated end-of-support and end-of-life information, including a pre-set process for handling risk if a device stays in use after support ends; and
• how to decommission the device securely by sanitizing data and software.

If a hospital is buying a new connected device and the maker cannot produce these items, that is a finding worth writing down.

Cybersecurity management plans

FDA asks sponsors to submit a cybersecurity management plan that explains how they will identify and communicate vulnerabilities after the device is sold. The plan should name responsible personnel, monitoring sources and frequency, how the maker tracks vulnerabilities in CISA's Known Exploited Vulnerabilities (KEV) catalog, periodic security testing, timelines to develop and release patches, update processes and delivery capability, a coordinated vulnerability disclosure process, and how fixes are communicated to customers.¹⁴ For a cyber device, this plan is how the maker meets 524B(b)(1).

The 2016 postmarket guidance

"Postmarket Management of Cybersecurity in Medical Devices," dated December 27, 2016 on FDA's guidance table and announced in the Federal Register on December 28, 2016, is still FDA's main statement on what makers should do after a device is on the market.²¹⁸ It applies to all devices, not just 524B cyber devices, which is why it matters so much for the installed base.

Controlled versus uncontrolled risk

The guidance asks the maker to assess each vulnerability by two things: how exploitable it is (FDA's webinar materials point to the Common Vulnerability Scoring System, CVSS, as one tool) and how severe the patient harm would be if it were exploited.⁹ The result sorts the vulnerability into one of two bins.

• Controlled risk means the residual risk to the device's safety and essential performance is acceptable. FDA's materials call it "acceptable residual risk."⁹
• Uncontrolled risk means the residual risk of patient harm is unacceptable, given existing controls.⁹

Reporting under 21 CFR Part 806

FDA's rule at 21 CFR Part 806 normally requires makers to report certain corrections and removals (the regulatory term for many recalls) to FDA. The 2016 guidance tells makers how FDA will apply that rule to cybersecurity fixes.

The design is deliberate. FDA wanted to reward makers that move fast, tell customers and share information through ISAOs, and to remove the fear that every security patch would be treated as a public recall. Hospitals feel the effect: most security patches for devices arrive as routine service bulletins, not as recall notices, which means they are easy to miss unless someone is watching the maker's security page.

What a maker's postmarket program should include

FDA's 2017 webinar on the guidance summarized the elements of a postmarket cybersecurity program: a proactive risk management program applying the NIST Framework for Improving Critical Infrastructure Cybersecurity; processes for taking in and handling vulnerability reports; a coordinated disclosure policy; mitigations deployed early, before exploitation; and collaborative information sharing about vulnerabilities and threats.⁹ Less than six years later, 524B turned the first and third of those into statutory duties for new cyber devices.

ISAOs and information sharing

An ISAO is a group that shares threat and vulnerability information among members. In health care the largest is Health-ISAC (the Health Information Sharing and Analysis Center), a membership nonprofit with offices in the Americas, Europe and Asia-Pacific that runs alerts, reports, summits and working groups.²⁵ FDA has signed memoranda of understanding with information sharing organizations and, in October 2018, announced a partnership with the Department of Homeland Security to coordinate responses to device cybersecurity threats.⁸ Hospitals do not have to join an ISAO to get public advisories, but membership often brings earlier warnings and peer help.

Software bills of materials, explained

What an SBOM is

A software bill of materials is an ingredient list for software. Modern devices are built from many parts their makers did not write: an operating system, a database engine, a web server, an encryption library, open-source components and code from suppliers. When a flaw is found in one of those parts (the 2021 Log4j logging library flaw is the example everyone remembers; FDA issued a notice about it on December 17, 2021⁸), the first question every hospital asks is "which of our devices contain it?" Without an SBOM, the honest answer is often "we do not know until each maker tells us."

The NTIA minimum elements

On July 12, 2021, under Executive Order 14028, the Commerce Department's National Telecommunications and Information Administration (NTIA) published The Minimum Elements for a Software Bill of Materials. It set seven baseline data fields for each component: supplier name, component name, version, other unique identifiers, dependency relationship, author of the SBOM data, and timestamp. It grouped the minimum elements into three categories (data fields, automation support, and practices and processes) and named three machine-readable formats: SPDX, CycloneDX and SWID tags.²⁶

What FDA adds for devices

FDA's guidance asks for a machine-readable SBOM that includes the NTIA baseline attributes and, for each component, two things NTIA did not require: the component's support level and its end-of-support date. It also asks for known vulnerabilities in those components, including any listed in CISA's KEV catalog, with the maker's assessment of their impact.¹⁴ That last point matters. A raw SBOM lists ingredients; the maker's assessment tells you whether a famous flaw in one ingredient can actually be reached in this device as configured.

How a hospital uses an SBOM

• At purchase: ask for it, along with the end-of-support dates, so you can see how close the device is to running unsupported software on the day it arrives.
• When a big vulnerability is announced: search your SBOM collection to find which devices may be affected, then check each maker's security notice for its own assessment. HICP's large-organization practices tell hospitals to work with makers to categorize risks, using SBOMs and lookups in the National Vulnerability Database.²⁷
• In the HIPAA risk analysis: treat unsupported components as a documented risk with a documented treatment, such as segmentation or replacement.

What an SBOM cannot do

An SBOM is not a security rating. It does not say whether the device is well configured, whether the vulnerable code path is reachable, or whether the maker will patch. It can be wrong or stale, and SBOM data from different makers is often formatted differently; FDA's own page lists MITRE white papers from October 2024 and April 2026 on the problem of normalizing SBOM data.⁸ Treat an SBOM as an index for asking better questions, not an answer.

The device lifecycle and who does what

Every connected device passes through the same stages, and the division of work shifts at each one. The IMDRF legacy device paper (IMDRF/CYBER WG/N70, published April 2023) names the stages after the device reaches market: support, when the device and its major components are supported and receive full cybersecurity support including patches; limited support, after the maker declares end of life (EOL) or a component loses support but risks are still mitigated where possible; and end of support (EOS), when the maker stops all service support and the device cannot be reasonably protected.¹¹ Under IMDRF's definitions, EOL is the point when the maker stops selling the product and notifies users; EOS is the point when it stops all service support.¹¹

Real cases, stated from the primary sources

The cases below are told only at the level a hospital, patient or reporter needs. None of them included a confirmed report of patient harm from an attack at the time the regulators wrote about them, and each was resolved by makers, regulators and clinicians working together.

Abbott (St. Jude Medical) pacemakers, 2017

On August 29, 2017, FDA announced that it had approved a firmware update for certain implantable pacemakers made by Abbott (formerly St. Jude Medical), and described the update as a recall meant to reduce the risk of patient harm from cybersecurity vulnerabilities. About 465,000 affected devices were implanted in the United States. FDA said there were no known reports of patients harmed by these vulnerabilities, that the update had to be given in person by a health care provider, and that neither FDA nor Abbott recommended removing the devices.²⁸⁸

The matching federal advisory, ICSMA-17-241-01, listed the affected families (Accent and Anthem; Accent MRI and Accent ST; Assurity and Allure; Assurity MRI) made before August 28, 2017, and three weaknesses: improper authentication of radio-frequency (RF) commands (CVE-2017-12712, CVSS v3 7.5), no limit on RF "wake-up" commands that could drain the battery (CVE-2017-12714, 5.3), and, in Accent and Anthem only, unencrypted patient data (CVE-2017-12716, 3.1). An attacker would have needed to be physically close and highly skilled, and no exploit code was public.²⁹

The update itself carried risk, and the documents said so. Abbott's August 28, 2017 letter to physicians said the update takes about three minutes, during which the pacemaker runs in a backup mode (VVI pacing at 67 beats per minute) with essential functions available. It reported the rates seen in earlier firmware updates of the same kind: reloading of the previous firmware after an incomplete update, 0.161 percent; loss of programmed settings, 0.023 percent; and complete loss of device function, 0.003 percent.¹⁰ The letter asked physicians to discuss benefits and risks with each patient at the next scheduled visit, record settings first, and do the update for pacing-dependent patients where temporary pacing and generator replacement were available.¹⁰²⁹

Why it matters: this is the clearest public example of a security fix treated as a clinical decision. It also came after an earlier step. On January 9, 2017, FDA issued a communication about St. Jude Medical implantable cardiac devices and the Merlin@home bedside transmitter.⁸

Medtronic MiniMed insulin pumps, 2019

On June 27, 2019, FDA warned patients and providers that certain Medtronic MiniMed insulin pumps had vulnerabilities that could let someone nearby connect wirelessly and change pump settings. FDA said Medtronic could not adequately fix the problem with software updates or patches, so Medtronic was offering replacement pumps with better built-in cybersecurity. Medtronic had identified about 4,000 U.S. patients who might be using the affected pumps. FDA said it was not aware of any confirmed reports of patient harm.³⁰³¹ The CISA advisory, ICSMA-19-178-01 (CVE-2019-10964, improper access control, CVSS v3 7.1), listed eleven models, including the MiniMed 508 and MiniMed Paradigm 511, 512/712, 515/715, 522/722 and later models up to certain software versions.³²

Why it matters: this is the textbook "cannot be patched" case. The only real fix was replacement, and the interim advice was ordinary patient-level hygiene: keep the pump and connected devices physically secure, keep the serial number private, respond to alerts, cancel any bolus you did not intend, and disconnect the CareLink USB device from the computer when not downloading data.³²

GE patient monitoring network, 2020

On January 23, 2020, FDA and CISA warned about six vulnerabilities (CVE-2020-6961 through CVE-2020-6966, most scored CVSS v3 10.0) in GE Healthcare's CARESCAPE and ApexPro telemetry servers, CARESCAPE Central Station, Clinical Information Center versions 4.X and 5.X, and CARESCAPE B450, B650 and B850 monitors.³³⁸ The mitigations are a lesson in hospital-side defense. GE told customers to confirm that the monitoring "mission critical" and "information exchange" networks were configured and isolated according to its network guides; if outside connectivity was needed, to use a router or firewall that allows only the necessary clinical data flows; to block inbound traffic from outside those networks, including remote access and file-sharing ports; to restrict physical access to central stations and servers; and to change default passwords. CISA added its standard advice: put medical system networks behind firewalls, separate them from business networks, and perform impact analysis and risk assessment before deploying changes.³³

Contec CMS8000 patient monitors, 2025

On January 30, 2025, CISA published ICS medical advisory ICSMA-25-030-01 and FDA issued a safety communication, "Cybersecurity Vulnerabilities with Certain Patient Monitors from Contec and Epsimed."¹⁷³⁴ The Contec CMS8000 is a patient monitor that displays vital signs such as temperature, heart rate and blood pressure, used in health care and home settings; the Epsimed MN-120 is the same monitor relabeled.³⁴ The advisory, updated February 25, 2025, described four vulnerabilities:¹⁷

• CVE-2024-12248, an out-of-bounds write (CVSS v3.1 9.8);
• CVE-2025-0626, hidden functionality that connects to a hard-coded, routable IP address, which FDA described as a "backdoor" (7.5);
• CVE-2025-0683, privacy leakage that sends plaintext patient data to a hard-coded public IP address (5.9); and
• CVE-2025-1204, hidden functionality in an update file, added in Update A (7.5).

FDA said that once connected to the internet, the monitor gathers patient data, including personally identifiable information and PHI, and sends it outside the care environment. FDA was not aware of incidents, injuries or deaths at the time, and CISA knew of no public exploitation.³⁴¹⁷ The first advice was blunt: use only local monitoring, unplug the Ethernet cable and disable wireless, and if a device relies on remote monitoring, unplug it and use an alternative. CISA also advised, where removal was not possible, blocking a specific address range at the network edge.¹⁷³⁴ FDA updated its communication on July 2, 2025, after Contec released a patch that removes networking so the devices can only be used for local monitoring; FDA said patients, caregivers and providers should not install it themselves because it requires specialized expertise, and that facility IT and security staff could request it from Contec.³⁴

Why it matters for HIPAA: a device that silently sends PHI to an outside address is a privacy and security incident even if nothing clinical goes wrong. A covered entity that ran these monitors on a network with internet access had to ask whether PHI was disclosed and whether the breach notification rules applied, which is the subject of lesson 5. It also shows why inventory has to record the maker behind the label: the advisory warned that resellers may sell the device under other names.¹⁷

Illumina and the False Claims Act, 2025

Device cybersecurity can also become a fraud case. On July 31, 2025, the Justice Department announced that Illumina, Inc. agreed to pay $9.8 million to resolve allegations that it sold genomic sequencing systems with software that had cybersecurity vulnerabilities to federal agencies between February 2016 and September 2023. The United States alleged that Illumina lacked an adequate product security program and quality systems to address the vulnerabilities and falsely represented that its software met ISO and NIST standards. The settlement states that the claims are allegations only, with no determination of liability. The whistleblower, a former Illumina director, received $1.9 million.³⁵ FDA had earlier issued a June 2, 2022 letter to providers about Illumina sequencing instruments.⁸

Why it matters: makers that sell to federal agencies, the VA or the military face False Claims Act exposure, not only FDA exposure, if they misstate their security. Buyers' written security representations in contracts are not just paperwork.

Other advisories worth knowing

FDA's cybersecurity page lists its device safety communications and alerts back to 2013, including Hospira LifeCare PCA3 and PCA5 infusion systems (May 13, 2015), Medtronic implantable cardiac device programmers (October 11, 2018) and cardiac devices, programmers and home monitors (March 21, 2019), the "URGENT/11" flaws in third-party network software (October 1, 2019), SweynTooth Bluetooth Low Energy flaws (March 3, 2020), BlackBerry QNX (August 17, 2021), Fresenius Kabi Agilia Connect infusion systems (December 22, 2021), PTC Axeda remote-service software (March 8, 2022) and the Medtronic MiniMed 600 series insulin pump system (September 20, 2022).⁸ Several of those involve components many makers share, such as an operating system or a network stack, which is the strongest practical argument for SBOMs. CISA publishes its full ICS medical advisory series (the "ICSMA" numbers) on its website, and anyone can subscribe.³⁶

Legacy and end-of-support devices

What "legacy" means

"Legacy" is not a synonym for "old." IMDRF's definition, a device that cannot be reasonably protected against current cybersecurity threats, can fit a five-year-old device whose operating system just lost support and not fit a twenty-year-old stand-alone device with no data ports.¹¹ The HSCC's free guide Health Industry Cybersecurity: Managing Legacy Technology Security (HIC-MaLTS, March 2023) organizes legacy risk work into four pillars: governance, communications, cyber risk management and "future proofing," meaning designing today's devices so they do not become tomorrow's unprotectable ones.³⁷²⁵

Windows-based modalities and embedded operating systems

Imaging consoles (CT, MRI, X-ray, ultrasound), lab analyzers, nurse call servers, picture archiving workstations and many monitoring central stations run on general-purpose operating systems, often a version of Windows. That brings Windows' strengths (familiar tools, broad driver support) and its weakness for this purpose: the operating system's support calendar is set by Microsoft, not by the device maker or the hospital. Microsoft ended support for most Windows 10 editions on October 14, 2025; after that date, a device on one of those editions gets no security updates unless enrolled in paid Extended Security Updates and only if the device maker validates and delivers them.¹² Makers who chose long-term servicing or IoT editions bought more time; Microsoft said in 2021 that Windows 10 IoT Enterprise LTSC would keep a 10-year lifecycle.¹³ The practical point for a hospital: the operating system and its end-of-support date belong in the device inventory, next to the maker's own end-of-support date for the device.

Compensating controls

When a device cannot be patched, the work moves to the things around it. The IMDRF paper lists the kinds of compensating controls providers use: physical access restrictions, controls on removable media, network isolation, monitoring, removing remote access that is not needed, and anti-malware where the maker supports it. It also cautions against relying solely on firewalls or segmentation.¹¹ In plain terms, the questions are:

• Does this device need to talk to anything? If it only needs to send images to one archive server, can the network allow exactly that and nothing else?
• Does it need internet access at all? Most do not. Some need a narrow path to the maker's service server, which can be routed through a controlled gateway.
• Who can touch it? Can the USB ports be locked or disabled by the maker? Is the console in a room where visitors cannot sit down at it?
• Would anyone notice if it started behaving strangely? Is its traffic watched?
• What is the clinical workaround if it has to come off the network? Who decides that, and how fast?

Deciding when to replace

IMDRF asks providers to weigh decommissioning, upgrading or continued use past EOS by comparing maintenance costs with replacement costs and the risk to patients, and to ask the maker exactly when responsibility for an unsupported device transfers.¹¹ For small and rural hospitals, the cost side is real: a capital budget may not stretch to replace an imaging system on the operating system's schedule. That is why the decision belongs to leadership with clinical engineering, security and the clinical service at the table, and why end-of-support dates should be negotiated before purchase, not discovered after.

Hospital-side practice

Start with the device inventory

You cannot protect devices you cannot list. HICP's practice on network connected medical devices begins with asset management, and its small-practice volume pairs inventory with procurement and decommissioning.¹⁶³⁸ A useful device inventory goes beyond the biomed maintenance list. For each connected device, it records:

• maker, model and the brand name on the label (they can differ, as the Contec and Epsimed case showed);
• software and firmware versions, the operating system and its support end date;
• the maker's end-of-life and end-of-support dates;
• network details: wired or wireless, the network segment it sits on, its addresses, and what it needs to talk to;
• whether it stores or transmits ePHI;
• whether the maker has remote access, and how;
• where the SBOM, MDS2 form and security notices for it are kept; and
• the clinical owner who must be consulted before any change.

The IMDRF paper recommends a real-time inventory that tracks each device's life cycle stage, expected end-of-support date, SBOM, patch status and network environment.¹¹ Many hospitals use passive network monitoring tools built for medical devices to find devices the paper inventory missed; passive tools listen rather than probe, which is why clinical engineering teams often prefer them.

Network segmentation and VLANs for clinical devices

Segmentation means dividing a network into zones and controlling what can cross between them. A virtual local area network (VLAN) is one common way to create a zone on shared switches; firewalls or access control lists between VLANs decide which traffic may pass. For clinical devices, the goal is that a compromised laptop on the guest Wi-Fi or a phished workstation in billing cannot reach an infusion pump server or a monitoring network, and that a compromised device cannot reach the rest of the hospital. HICP's medium-organization device practice calls for segmenting medical devices onto restricted networks and limiting traffic and management access.²⁷ The HHS Cybersecurity Performance Goals list network segmentation as an "enhanced" goal,⁷ and the pending Security Rule proposal would make network segmentation a HIPAA requirement.⁵ For the general mechanics of small-business networks, Wi-Fi and remote work, see Small Business Data Security, lesson 6.

Three cautions come with segmentation. First, devices often depend on traffic nobody documented, such as time synchronization or a central alarm path; cutting it can silence alarms. That is why makers' port lists and network guides (which FDA's guidance now asks makers to provide) matter so much.¹⁴ Second, active vulnerability scanners can disrupt fragile devices; HICP's device practice warns about limiting scanners that could disrupt devices, and its large-organization practice says to scan devices only under strict controls.²⁷ Third, segmentation is not a reason to stop patching. The IMDRF paper warns against relying solely on firewalls or segmentation.¹¹

MDS2 forms

The Manufacturer Disclosure Statement for Medical Device Security (MDS2) is a standard questionnaire in which a maker describes a device's security features: how it handles ePHI, authentication, audit logging, encryption, malware protection, remote service, network ports, third-party components, and more. The current version is ANSI/NEMA HN 1-2019, published by the National Electrical Manufacturers Association with instructions for completing it.³⁹ Hospitals use MDS2 forms during purchasing and risk analysis because the answers are in a consistent order, so one device can be compared with another. HICP's large-organization device practice names the MDS2 and the SBOM as tools for evaluating security before acquisition.²⁷

Read an MDS2 form the way you read any self-report: carefully. It describes what the maker says the device does, as configured by the maker, at the time it was written. Ask for the version that matches the model and software version you are buying, ask what changes after updates, and treat blanks and "see notes" answers as questions to pursue.

Procurement language

The cheapest moment to get security is before the contract is signed. HICP's procurement and security evaluation practice tells larger organizations to set cybersecurity requirements for device purchases, evaluate security before acquisition, negotiate security terms in contracts and plan for end of life and end of support.²⁷ The IMDRF paper lists what to request before buying: end-of-life and end-of-support dates, the maker's upgrade strategy, required ports and services, firewall rules, backup and restore procedures, how the maker will notify you of vulnerabilities, and SBOMs.¹¹ The HHS Cybersecurity Performance Goals include "vendor/supplier cybersecurity requirements" as an essential goal.⁷ Contract topics that come up in practice include:

• a stated support period, with end-of-support notice well in advance;
• delivery of an SBOM and an updated MDS2 with each major release;
• how fast the maker will assess and communicate newly announced vulnerabilities, and how validated patches will be delivered and at whose cost;
• whether the hospital may install operating system patches or anti-malware the maker has validated, and how the maker communicates that validation;
• remote access terms: unique named accounts, multifactor authentication, logging, and access only when the hospital opens it;
• incident cooperation: who calls whom, and how fast, when either side sees a problem;
• data sanitization at return, trade-in or disposal; and
• if the maker or its cloud service will create, receive, maintain or transmit PHI for the hospital, a HIPAA business associate agreement. That last question is covered in lesson 6.

This lesson does not offer contract language. Your compliance officer, purchasing team and qualified privacy and security professionals should draft it against the specific device and vendor.

Vulnerability management with makers

A hospital's device vulnerability process usually runs like this:

1. Watch the sources. Subscribe to FDA's device safety communications, CISA's ICS medical advisories and each maker's product security page. Health-ISAC members also get shared alerts.⁸³⁶²⁵
2. Match to inventory. Use the inventory and SBOMs to find which devices are affected, including relabeled ones.
3. Get the maker's assessment. Ask whether the flaw is reachable in your configuration, what the maker recommends meanwhile, and when a validated fix is expected.
4. Decide with clinicians. Weigh the clinical impact of each option, including doing nothing for now, adding a network restriction, or taking the device out of service.
5. Apply validated fixes on a schedule with clinical engineering and the maker, test afterward, and update the inventory.
6. Document. Record the decision in the HIPAA risk analysis and risk management plan.
7. Report problems. FDA says health care providers can report device cybersecurity problems through MedWatch Form 3500, and patients through Form 3500B; device user facilities also have mandatory reporting duties for certain adverse events.⁸

HICP's medium-organization volume adds a step for the hard case: contact FDA when a high-risk device vulnerability cannot be mitigated with the maker's support.²⁷ For the general patching mechanics that apply to ordinary IT and websites, see SMB Privacy and Security Management, lesson 15.

Using CISA's Known Exploited Vulnerabilities catalog

CISA's KEV catalog lists vulnerabilities that have been exploited in the wild. A flaw is added only if it has a CVE identifier, there is reliable evidence of active exploitation (proof-of-concept code and research alone do not count), and there is a clear remediation such as a vendor update. Federal civilian agencies must fix KEV entries on set deadlines under Binding Operational Directive 22-01; everyone else is not bound, but CISA strongly recommends that organizations prioritize KEV entries and build them into vulnerability management plans.⁴⁰ For hospitals, KEV is a triage tool: a KEV-listed flaw in a component on your network jumps the queue. FDA now expects device makers to track KEV in their own management plans and SBOM assessments, so asking a maker "does any component in this device appear in KEV, and what is your assessment?" is a fair and specific question.¹⁴

Vendor remote access

Remote service is how many makers keep imaging and lab systems running. It is also a door into the network. Good practice, drawn from HICP, the HHS Cybersecurity Performance Goals and the GE advisory mitigations above, is that vendor access comes through one controlled gateway, uses unique accounts with multifactor authentication, is logged, is opened only when needed, and reaches only the specific devices it serves.²⁷⁷³³ Shared vendor passwords and always-on connections are the pattern to retire.

Incident response for devices

A hospital's incident response plan should cover devices explicitly: who decides to isolate a device or a device network, what the clinical workaround is (manual vital signs, paper orders, diverting imaging), how the maker is contacted after hours, and how evidence is kept. FDA funded a MITRE "Medical Device Cybersecurity Regional Incident Preparedness and Response Playbook," updated November 15, 2022, with a quick start companion guide, and in 2023 posted a video of tips for health care facilities on incident preparedness and response.⁸ Ransomware that never touches a device can still stop devices from working, because they depend on servers and networks that went down. The real hospital ransomware cases in lesson 8 show how long recovery can take.

HHS 405(d) HICP and the Cybersecurity Performance Goals

HICP's medical device practice

Section 405(d) of the Cybersecurity Act of 2015 directed HHS to work with industry on voluntary cybersecurity practices for health care. The result is Health Industry Cybersecurity Practices: Managing Threats and Protecting Patients (HICP), first published in December 2018, with a 2023 edition. HICP names five threats, one of which is "attacks against network connected medical devices that may affect patient safety," and ten practices, the ninth of which is network connected medical devices.⁶ The 2023 Technical Volume 2, for medium and large organizations, lists device sub-practices covering asset management, endpoint protections, identity and access management, network management, vulnerability management and contacting FDA for medium organizations, and security operations and incident response plus procurement and security evaluations for large ones.¹⁶ Technical Volume 1, for small practices without dedicated security staff, includes a basic medical device security sub-practice (9.S.A) alongside inventory, procurement, decommissioning and network segmentation.³⁸ All of it is free.

The HPH Cybersecurity Performance Goals

In January 2024, HHS released voluntary Cybersecurity Performance Goals (CPGs) for the health care and public health sector: ten "essential" goals and ten "enhanced" goals.⁷ Several map directly onto device security:

Why this voluntary work counts under HIPAA

A 2021 amendment to the HITECH Act (Pub. L. 116-321, codified at 42 U.S.C. 17941) says HHS "shall consider" whether a covered entity or business associate had recognized security practices in place for the previous 12 months when deciding fines, audit outcomes and mitigation. Recognized security practices include the NIST Cybersecurity Framework and approaches developed under section 405(d), such as HICP.⁴¹ Documented HICP device practices are therefore not only good engineering; they are evidence OCR must consider.

HIPAA's role

Devices that hold ePHI are inside the Security Rule

The HIPAA Security Rule (45 CFR Part 164, Subpart C, current eCFR text read October 28, 2026) applies to ePHI wherever a covered entity or business associate creates, receives, maintains or transmits it.⁴² There is no device exemption. If a monitor, pump server, imaging archive or analyzer holds ePHI, it belongs in the risk analysis required by 45 CFR 164.308(a)(1)(ii)(A), and its risks must be managed under 164.308(a)(1)(ii)(B).⁴³⁴⁴ The technical safeguards standards at 45 CFR 164.312 (access control, audit controls, integrity, person or entity authentication, transmission security) apply to it, even if some must be met by compensating controls because the device itself cannot do them; the rule's flexibility lets an entity consider its size, technical infrastructure, costs and risks, but an "addressable" specification still has to be assessed and documented, not ignored.⁴⁵⁴² The device and media controls standard at 164.310(d)(1) covers disposal and reuse of device hard drives.¹⁹

What the pending Security Rule proposal would add

The proposal published January 6, 2025 (90 FR 898) would, among other things, require a written technology asset inventory and a network map showing the movement of ePHI, updated at least every 12 months and after relevant changes; network segmentation; vulnerability scanning at least every six months and penetration testing at least every 12 months; multifactor authentication and encryption with limited exceptions; and disabling unused ports and removing extraneous software.⁵ For device-heavy organizations, the inventory, network map and segmentation provisions would turn today's good practice into requirements. As of October 28, 2026, the proposal is not final; HHS's regulatory agenda lists it as a long-term action with final action projected for July 2027.⁴⁶ The current Security Rule remains the enforceable rule. Lesson 3 covers the proposal in full, including its exceptions and the debate over cost.

Are device makers business associates?

Sometimes. Selling a device does not by itself make a maker a business associate. A maker or its cloud service becomes one when it creates, receives, maintains or transmits PHI on the covered entity's behalf, for example by hosting remote monitoring data or a cloud imaging archive for the hospital. OCR's cloud computing guidance says a cloud service provider that stores ePHI is a business associate even if it stores only encrypted data and lacks the key.⁴⁷ Whether a particular service relationship requires a business associate agreement is a fact question; lesson 6 walks through it.

Where this lesson links instead of repeating

• The HIPAA overview and health data outside HIPAA: Privacy and Data Security Laws, lesson 3.
• The Security Rule safeguards and the proposed update: lesson 3 of this module.
• Doing the risk analysis OCR expects: lesson 4.
• Business associate agreements with cloud and AI vendors, including device makers' cloud services: lesson 6.
• Patching ordinary systems and websites: SMB Privacy and Security Management, lesson 15.
• Network design, Wi-Fi and remote work basics: Small Business Data Security, lesson 6.
• A small clinic's version of all this, from inventory to written policy: lesson 9.

Common mistakes

OCR's public enforcement record rarely names a medical device, but the failures it cites are the same ones that leave devices exposed. The device-specific mistakes below come from the FDA and CISA cases above.

Leaving devices out of the risk analysis

The most common finding in OCR's settlements is a missing or inadequate risk analysis. In its September 17, 2026 settlement with Ambry Genetics ($700,000, after a January 2020 phishing attack affecting 225,370 people), OCR cited an inadequate risk analysis, failure to terminate access and failure to assign unique user IDs.⁴⁸ OCR's ransomware settlements from 2024 to 2026 repeat the risk analysis finding again and again.⁴⁹ A risk analysis that covers the EHR and the email system but skips the imaging archive, the pump server and the monitoring network is incomplete under 45 CFR 164.308(a)(1)(ii)(A), which requires an accurate and thorough assessment of risks to all ePHI the entity holds.⁴³

Shared and default passwords on devices and vendor accounts

"No unique user IDs" in the Ambry case is a general finding,⁴⁸ but devices are where shared logins persist longest: one console password taped to the cart, one vendor account used by every field engineer. The GE advisory told customers to change default passwords;³³ the HHS CPGs list unique credentials and separate privileged accounts as essential goals.⁷

A flat network

Putting monitors, pumps, imaging and office PCs on the same network lets one compromised laptop reach everything. Every major device advisory in this lesson pointed to network isolation as the first mitigation.³³¹⁷

Trusting the label

The Contec monitor was also sold as the Epsimed MN-120, and the advisory warned that resellers may relabel it.¹⁷³⁴ An inventory keyed only to the name on the front can miss an advisory entirely.

Patching or scanning on your own

Installing an operating system patch the maker has not validated, or pointing an aggressive scanner at a monitoring network, can break a device. HICP warns about scanners that can disrupt devices, and CISA's advisories tell organizations to perform impact analysis before deploying defensive measures.²⁷³²

Buying without an end-of-support date

FDA now recommends that makers disclose end-of-support information in labeling, and IMDRF tells providers to ask for it before purchase.¹⁴¹¹ A hospital that signs without it learns the date when the patches stop.

Returning devices with data on them

Traded-in or returned devices with intact drives are an ePHI disposal failure under 45 CFR 164.310(d)(1) and its disposal and media re-use specifications.¹⁹ FDA's guidance asks makers to explain secure decommissioning; hospitals should use it.¹⁴

Questions people ask

Can our IT team install Windows updates on a medical device?

Only if the maker has validated those updates for that device and says so, and only through the process the maker specifies. Otherwise, an unvalidated change can affect the device's clinical function and may void the maker's support. Ask the maker for its patch validation list and schedule, and put that duty in the contract. The 2016 postmarket guidance means makers usually do not need FDA permission to ship a security patch,¹⁵ so a maker that says "FDA won't let us patch" is generally not describing FDA's position for routine security updates.

Does section 524B apply to the devices we already own?

Generally no. It applies to premarket submissions made on or after March 29, 2023, and to older devices only when a change requires a new submission.²² FDA keeps its general safety authority over older devices, which is how it handled the Abbott and Medtronic cases.¹

We think a device was compromised. Who do we tell?

Follow your incident response plan: isolate according to the clinical plan, call the maker, and preserve evidence. FDA says providers can report device problems through MedWatch, and user facilities have mandatory reporting duties for certain device-related deaths and serious injuries.⁸ If ePHI may have been acquired or disclosed, the HIPAA breach analysis starts (see lesson 5). Law enforcement and CISA can be contacted for cyber incidents.

Is a maker required to give us an MDS2 form or an SBOM?

No federal law requires a maker to give a customer an MDS2. Section 524B requires the SBOM to be provided to FDA for cyber devices, and FDA's guidance recommends that makers make a machine-readable SBOM available to users in labeling.¹¹⁴ In practice, many makers provide both on request, and buyers can require them by contract.

We are a small clinic with a few connected devices. Does any of this apply to us?

Yes, scaled down. If a device holds ePHI, it belongs in your HIPAA risk analysis. HICP Technical Volume 1 has a small-practice medical device sub-practice, and its inventory, procurement, decommissioning and segmentation sub-practices are written for organizations without security staff.³⁸ Lesson 9 walks through it.

What about devices patients use at home?

The same FDA rules apply to the maker. FDA's patient advice in the Medtronic and Contec cases focused on practical steps: talk with your provider, keep the device physically secure, follow the maker's instructions, and report problems.³²³⁴ FDA also published best practices for communicating cybersecurity vulnerabilities to patients on October 1, 2021.⁸

Hard questions

Should makers be required to support devices for a minimum number of years?

For: Hospitals buy devices expecting a decade of use, and the operating system inside may lose support in half that time. A legal minimum support period, or at least a binding disclosure at sale, would put the cost on the party that chose the components and can plan for it. Against: Makers say they cannot control third-party component lifecycles, that a fixed period would raise prices and slow innovation, and that some old devices are low risk. What the evidence shows: Section 524B requires patch processes but sets no support period, and FDA's guidance recommends only that end-of-support information be disclosed in labeling.¹¹⁴ IMDRF and the HSCC treat the end of support as a shared planning problem, with responsibility shifting to providers once support ends.¹¹³⁷ The Medtronic pump case shows the endgame when a device cannot be fixed: replacement, which the maker offered in that case.³⁰

Should HIPAA mandate segmentation, MFA and encryption?

For: The proposal's backers point to the steady rise of hacking and ransomware breaches, which OCR calls the most frequent type of large breach,⁴⁹ and argue that a flexible "reasonable and appropriate" rule has not produced consistent security. Against: The National Rural Health Association's March 7, 2025 comment letter called mandated investments such as MFA, encryption and penetration testing cost-prohibitive for small and rural facilities with narrow margins, noted that rural providers are more likely to rely on older technology, and asked for at least three years to comply.⁵⁰ HHS's own first-year cost estimate is widely reported as about $9.3 billion. Some legacy devices cannot support encryption or MFA at all, which is one reason the proposal includes limited exceptions. What the evidence shows: As of October 28, 2026, the proposal is not final and its projected final action date is July 2027.⁴⁶ Segmentation of device networks is already recommended by HICP, the CPGs and every major device advisory in this lesson.¹⁶⁷³³ The cost estimate is reported in secondary sources, not confirmed for this lesson from HHS's own press release.

Should hospitals have the right to patch or repair devices themselves?

For: Hospitals and independent service organizations argue that waiting on makers leaves known flaws open for months, and that trained clinical engineers can apply well-tested operating system updates safely. Against: Makers and many clinicians argue that unvalidated changes can break clinical function and that the maker is the one accountable to FDA for the device's safety and effectiveness. What the evidence shows: FDA's framework places validation with the maker, through design controls and the quality system, and the Abbott update showed that even a maker-validated security fix carries small measured risks.¹⁰¹⁴ FDA's 2021 discussion paper on cybersecurity in device servicing shows the agency has studied the servicing question, but this lesson found no rule giving hospitals a right to modify device software.⁸

Who should pay to replace unsupported devices?

For hospitals bearing it: They own the equipment and decide when to retire it. For makers or public money bearing more: Rural and safety-net hospitals cannot replace imaging systems on an operating system's schedule, and the patients at risk are the same either way. What the evidence shows: No federal program dedicated to replacing unsupported medical devices was found for this lesson. The HHS Cybersecurity Performance Goals are voluntary and come with no replacement money of their own.⁷ Funding decisions remain with hospitals, payers and legislatures.

Where to go next

• FDA medical device cybersecurity page: FDA's hub for device cybersecurity guidance, safety communications back to 2013, playbooks and videos. Free. Use it to check whether a device you own has an FDA communication and to subscribe to CDRH email updates.
• CISA ICS medical advisories: The federal list of medical device vulnerability advisories with affected models and mitigations. Free; subscribe by email. Match each advisory to your device inventory, including relabeled products.
• CISA Known Exploited Vulnerabilities catalog: Free, downloadable list of vulnerabilities exploited in the wild. Use it to prioritize remediation and to ask device makers whether any SBOM component appears on it.
• HHS 405(d) HICP, 2023 edition (main document and technical volumes): Free voluntary practices from HHS and industry. Practice 9 covers network connected medical devices; Technical Volume 1 is for small practices and Technical Volume 2 for medium and large organizations.
• HPH Cybersecurity Performance Goals: Free checklist of 10 essential and 10 enhanced goals, including asset inventory, network segmentation and vendor cybersecurity requirements. Useful for boards and small organizations to measure progress.
• HSCC, Managing Legacy Technology Security (HIC-MaLTS): Free industry guide (March 2023) for makers and providers on legacy technology risk, organized around governance, communications, cyber risk management and future proofing.
• HSCC Medical Technology and Health IT Joint Security Plan 2.0: Free lifecycle reference guide (March 2024) describing what makers and providers each do to keep devices secure. Good background for procurement teams.
• IMDRF legacy device principles (N70): Free international regulators' paper with a practical list of what providers should ask before purchase and how to handle end of support.

Still being checked (6 items)

These points could not be fully confirmed against a primary source when this lesson was written and fact checked in October 2026. The text above states each one as uncertain.

• HICP Technical Volume 2 (2023 edition): sub-practice codes for Practice 9 differ between the document's table of contents and its document guide; this lesson describes the topics without relying on exact codes. Detailed Practice 9 recommendations (scanner cautions, MDS2 and SBOM in procurement, contacting FDA) are taken from a secondary summary (Compliancy Group) because the PDF text past Practice 3 could not be extracted.
• HHS's NPRM cost estimate (about $9.3 billion in the first year) is widely reported but was not confirmed from HHS's own press release.
• The HSCC HIC-MaLTS release date is given as March 2, 2023 (HSCC page) and March 8, 2023 (Health-ISAC page); the lesson says March 2023.
• CISA's ICS medical advisories index page could not be fetched on October 28, 2026; individual advisories were read.
• Whether the free MDS2 form download is available without purchase of ANSI/NEMA HN 1-2019 was not confirmed.
• The Kootenai Health and Minidoka Memorial Hospital figures are from secondary reporting (SecurityWeek, HIPAA Journal).

Last verified October 28, 2026. General education, not legal, compliance or medical advice; rule versions and dates are stated in the text, and the sources used are listed in the Notes and Sources below. Check the regulator's current text before relying on any point.

Notes

1. 21 U.S.C. 360n-2, "Ensuring cybersecurity of devices" (FD&C Act section 524B), added by Pub. L. 117-328, div. FF, title III, section 3305(a) (December 29, 2022), effective 90 days after enactment under section 3305(d), Cornell LII text (read Oct. 28, 2026). Read it online. ↩
2. FDA, "Cybersecurity in Medical Devices: Refuse To Accept Policy for Cyber Devices and Related Systems Under Section 524B of the FD&C Act," notice of availability, 88 FR 19148 (March 30, 2023) (read Oct. 28, 2026). Read it online. ↩
3. FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, final guidance, February 3, 2026, docket FDA-2021-D-1158, superseding the June 27, 2025 guidance, guidance web page (read Oct. 28, 2026). Read it online. ↩
4. FDA, "Medical Devices; Quality System Regulation Amendments," final rule, 89 FR 7496 (February 2, 2024), effective February 2, 2026 (read Oct. 28, 2026). Read it online. ↩
5. HHS Office for Civil Rights, "HIPAA Security Rule Notice of Proposed Rulemaking to Strengthen Cybersecurity for Electronic Protected Health Information" fact sheet (December 27, 2024), describing the proposal published at 90 FR 898 (January 6, 2025) (read Oct. 28, 2026). Read it online. ↩
6. HHS 405(d) Program and Health Sector Coordinating Council, Health Industry Cybersecurity Practices: Managing Threats and Protecting Patients, 2023 edition (original edition December 2018; 2023 edition released April 2023), five threats and ten practices (read Oct. 28, 2026). Read it online. ↩
7. HHS, "Healthcare and Public Health (HPH) Cybersecurity Performance Goals," HHS Cyber Gateway, voluntary goals released January 2024: 10 essential and 10 enhanced (read Oct. 28, 2026). Read it online. ↩
8. FDA, "Cybersecurity," Digital Health Center of Excellence page, content current as of July 6, 2026, including its lists of guidances, safety communications (2013 to 2025), reports, MOUs and reporting instructions (read Oct. 28, 2026). Read it online. ↩
9. FDA CDRH, webinar slides on the final guidance "Postmarket Management of Cybersecurity in Medical Devices," January 12, 2017 (controlled and uncontrolled risk, safety and essential performance, CVSS, program elements) (read Oct. 28, 2026). Read it online. ↩
10. Abbott, letter to physicians, "Pacemaker Firmware Update," August 28, 2017 (update duration, backup VVI mode at 67 bpm, observed update malfunction rates, recommendations) (read Oct. 28, 2026). Read it online. ↩
11. International Medical Device Regulators Forum, Principles and Practices for the Cybersecurity of Legacy Medical Devices, IMDRF/CYBER WG/N70FINAL:2023 (posted April 2023) (read Oct. 28, 2026). Read it online. ↩
12. Microsoft Learn, "Lifecycle FAQ: Windows" (Windows 10 end of support October 14, 2025; Extended Security Updates program) (read Oct. 28, 2026). Read it online. ↩
13. Microsoft Learn, "Upcoming Windows 10 and Office Long Term Servicing Channel (LTSC) releases," originally published February 18, 2021 (Windows 10 IoT Enterprise LTSC keeps a 10-year lifecycle) (read Oct. 28, 2026). Read it online. ↩
14. FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, February 3, 2026, full text PDF: sections IV to VII (SPDF, risk assessment, architecture views, testing, labeling, cybersecurity management plans, cyber devices and modifications) (read Oct. 28, 2026). Read it online. ↩
15. Morgan Lewis, "FDA Issues Final Guidance on Postmarket Cybersecurity" (summary of the December 2016 guidance, including the 30-day and 60-day conditions and routine updates) (read Oct. 28, 2026). Read it online. ↩
16. HHS 405(d), HICP Technical Volume 2: Cybersecurity Practices for Medium and Large Healthcare Organizations, 2023 edition, table of contents for Practice 9 and identity and access recommendations (read Oct. 28, 2026). Read it online. ↩
17. CISA, ICS Medical Advisory ICSMA-25-030-01, "Contec Health CMS8000 Patient Monitor," January 30, 2025, Update A February 25, 2025 (read Oct. 28, 2026). Read it online. ↩
18. Health Sector Coordinating Council, "Health Industry Publishes Guide for Medical Device and Health IT Security" (Medical Technology and Health IT Joint Security Plan 2.0), March 2024 (read Oct. 28, 2026). Read it online. ↩
19. 45 CFR 164.310(d)(1), device and media controls, with implementation specifications for disposal and media re-use, as amended through the 2013 Omnibus Rule, Cornell LII text (read Oct. 28, 2026). Read it online. ↩
20. Ropes & Gray, "FDA Final Guidance Confirms Role of Medical Device Firms in Cybersecurity Management," October 2014, on FDA's October 2, 2014 final guidance Content of Premarket Submissions for Management of Cybersecurity in Medical Devices (read Oct. 28, 2026). Read it online. ↩
21. FDA, "Postmarket Management of Cybersecurity in Medical Devices; Guidance for Industry and Food and Drug Administration Staff; Availability," Federal Register, December 28, 2016 (guidance dated December 27, 2016) (read Oct. 28, 2026). Read it online. ↩
22. FDA, "Cybersecurity in Medical Devices Frequently Asked Questions (FAQs)," last updated June 26, 2025 (scope, timing, eSTAR, previously authorized devices) (read Oct. 28, 2026). Read it online. ↩
23. 21 U.S.C. 331(q)(3), prohibited act: "The failure to comply with any requirement under section 360n-2(b)(2) of this title (relating to ensuring device cybersecurity)," Cornell LII text (read Oct. 28, 2026). Read it online. ↩
24. FDA, "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions; Guidance for Industry and Food and Drug Administration Staff; Availability," 88 FR 66458 (September 27, 2023), docket FDA-2021-D-1158 (read Oct. 28, 2026). Read it online. ↩
25. Health-ISAC, "HSCC Publishes Managing Legacy Technology Security" (describes Health-ISAC and the HIC-MaLTS guide, published March 2023) (read Oct. 28, 2026). Read it online. ↩
26. National Telecommunications and Information Administration, The Minimum Elements for a Software Bill of Materials (SBOM), July 12, 2021, issued under Executive Order 14028 (read Oct. 28, 2026). Read it online. ↩
27. Compliancy Group, "Cybersecurity Practice #9: Medical Device Security (medium/large)," summary of HICP Technical Volume 2 device sub-practices (secondary source; HICP PDF text for Practice 9 could not be extracted) (read Oct. 28, 2026). Read it online. ↩
28. American College of Cardiology, "FDA Approves Firmware Addressing Cybersecurity Vulnerabilities in Abbott Implantable Pacemakers," August 31, 2017, reporting FDA's August 29, 2017 safety communication (about 465,000 U.S. devices; in-person update; no prophylactic removal) (read Oct. 28, 2026). Read it online. ↩
29. CISA (then ICS-CERT), ICS Medical Advisory ICSMA-17-241-01, Abbott Laboratories Accent/Anthem, Accent MRI, Assurity/Allure and Assurity MRI pacemakers (August 29, 2017; archived) (read Oct. 28, 2026). Read it online. ↩
30. FDA news release "FDA warns patients and health care providers about potential cybersecurity concerns with certain Medtronic insulin pumps," June 27, 2019, as republished by BioSpace (read Oct. 28, 2026). Read it online. ↩
31. Regulatory Affairs Professionals Society, "FDA warns of cyber risk with Medtronic insulin pumps," June 2019 (11 models; replacement recommended) (read Oct. 28, 2026). Read it online. ↩
32. CISA, ICS Medical Advisory ICSMA-19-178-01, Medtronic MiniMed 508 and Paradigm series insulin pumps, CVE-2019-10964 (June 27, 2019; archived) (read Oct. 28, 2026). Read it online. ↩
33. CISA, ICS Medical Advisory ICSMA-20-023-01, GE Healthcare patient monitoring products, CVE-2020-6961 to CVE-2020-6966 (January 23, 2020) (read Oct. 28, 2026). Read it online. ↩
34. FDA, "Cybersecurity Vulnerabilities with Certain Patient Monitors from Contec and Epsimed: FDA Safety Communication," January 30, 2025, updated July 2, 2025 (read Oct. 28, 2026). Read it online. ↩
35. U.S. Department of Justice, "Illumina Inc. to Pay $9.8M to Resolve False Claims Act Allegations Arising from Cybersecurity Vulnerabilities in Genomic Sequencing Systems," July 31, 2025, United States ex rel. Lenore v. Illumina Inc., No. 1:23-cv-00372 (D.R.I.) (read Oct. 28, 2026). Read it online. ↩
36. CISA, "ICS Medical Advisories" index (ICSMA series); index page not reachable on Oct. 28, 2026, individual advisories read that day. Read it online. ↩
37. Health Sector Coordinating Council, Health Industry Cybersecurity: Managing Legacy Technology Security (HIC-MaLTS), March 2023, free download page (read Oct. 28, 2026). Read it online. ↩
38. HHS 405(d), HICP Technical Volume 1: Cybersecurity Practices for Small Health Care Organizations, 2023 edition (sub-practices 5.S.A to 5.S.C, 6.S.A and 9.S.A) (read Oct. 28, 2026). Read it online. ↩
39. ANSI Webstore listing, ANSI/NEMA HN 1-2019, Manufacturer Disclosure Statement for Medical Device Security (NEMA; includes the MDS2 form and instructions) (read Oct. 28, 2026). Read it online. ↩
40. CISA, "Known Exploited Vulnerabilities Catalog" and inclusion criteria; Binding Operational Directive 22-01 (read Oct. 28, 2026). Read it online. ↩
41. 42 U.S.C. 17941 (HITECH Act section 13412, added by Pub. L. 116-321, January 5, 2021), recognized security practices, Cornell LII text (read Oct. 28, 2026). Read it online. ↩
42. HHS Office for Civil Rights, "Summary of the HIPAA Security Rule" (scope, flexibility factors at 45 CFR 164.306(b)(2), required and addressable specifications at 164.306(d)) (read Oct. 28, 2026). Read it online. ↩
43. 45 CFR 164.308(a)(1)(ii)(A) and (B), risk analysis and risk management, as amended through the 2013 Omnibus Rule, Cornell LII text (read Oct. 28, 2026). Read it online. ↩
44. HHS Office for Civil Rights, "Guidance on Risk Analysis Requirements under the HIPAA Security Rule" (July 14, 2010) (read Oct. 28, 2026). Read it online. ↩
45. 45 CFR 164.312, technical safeguards, as amended through the 2013 Omnibus Rule, Cornell LII text (read Oct. 28, 2026). Read it online. ↩
46. Office of Information and Regulatory Affairs, Unified Agenda entry RIN 0945-AA22 (agenda publication 202510): long-term action, final action projected 07/00/2027 (read Oct. 28, 2026). Read it online. ↩
47. HHS Office for Civil Rights, "Guidance on HIPAA and Cloud Computing" (October 6, 2016; last reviewed December 23, 2022) (read Oct. 28, 2026). Read it online. ↩
48. HHS, "HHS Office for Civil Rights Settles HIPAA Investigation with Ambry Genetics Following Phishing Attack Affecting 225,000 Individuals," September 17, 2026 ($700,000) (read Oct. 28, 2026). Read it online. ↩
49. HHS, "OCR Settles Four Ransomware Investigations," April 23, 2026 (19 completed ransomware investigations; hacking and ransomware the most frequent type of large breach) (read Oct. 28, 2026). Read it online. ↩
50. National Rural Health Association, comment letter to HHS on the HIPAA Security Rule NPRM (90 FR 898), March 7, 2025 (read Oct. 28, 2026). Read it online. ↩
51. SecurityWeek, "460k Impacted by Kootenai Health Ransomware Attack" (2024; 464,088 people per Maine attorney general filing) (secondary source) (read Oct. 28, 2026). Read it online. ↩
52. HIPAA Journal, "Minidoka Memorial Hospital Cyberattack," April 22, 2026 (secondary source); Idaho Attorney General security breach notice list (read Oct. 28, 2026). Read it online. ↩