Infusion Pump Security: Protecting Wireless Pumps, Servers and Drug Libraries

Wireless infusion pumps deliver medication directly into patients and connect to pump servers, drug libraries and electronic health records, so a weakness in the pump ecosystem can expose patient data, alter dosing limits or stop pumps working. NIST's National Cybersecurity Center of Excellence (NCCoE) built a reference design for exactly this problem in NIST SP 1800-8, and published advisories show the same weaknesses recurring: unencrypted credentials on devices, missing authentication between pump and server, and legacy services such as Telnet and FTP. This guide goes deeper than our Medical Device Security Guide on one device class. It is written for hospital clinical engineering (biomedical) teams, network and security engineers and medication safety leads who run infusion systems day to day. Vendors and products appear only where official advisories or NIST name them, in alphabetical order, and naming is not a ranking.

Key takeaways

• Secure the ecosystem, not just the pump. NIST SP 1800-8 treats pumps, pump servers, drug library management, the wireless network and vendor remote access as one system with separate zones.
• Drug library integrity is a patient safety control. NCCoE names changes to prescribed doses and protection of drug library dosing limits as core concerns, so library changes need the same change control as clinical content.
• Known weaknesses repeat across products. NIST lists hard-coded or factory default passcodes, missing encryption at rest and in transit, Telnet and FTP, dormant accounts and debug interfaces; CISA advisories show the same patterns.
• Use certificate-based Wi-Fi and dedicated network zones. The NCCoE build used WPA2-Enterprise with EAP-TLS, VLANs and firewalls between zones with no inherent trust between them.
• Decommissioning leaks credentials. Pumps and wireless modules that are sold, returned or repaired without a full wipe can carry network credentials and patient data out of the hospital.

The infusion pump ecosystem and its risks

NIST SP 1800-8, Securing Wireless Infusion Pumps in Healthcare Delivery Organizations, was finalised in August 2018 after a 2017 draft. It was produced by the NCCoE with MITRE, uses a questionnaire-based risk assessment, and maps the ecosystem's security characteristics to cybersecurity standards and the HIPAA Security Rule. The NCCoE names three threats: unauthorised access to patient health information, changes to prescribed drug doses, and interference with a pump's function.

See the Medical Device Security Guide for the regulatory and programme context, which this page does not repeat.

Common vulnerabilities and what advisories show

NIST SP 1800-8 section 4.1.5 lists the device vulnerabilities its risk assessment found: lack of asset inventory, hard-coded or factory default passcodes, lack of encryption on sensitive data at rest and in transit, weak remote access controls, dormant accounts, debug-enabled interfaces and removable media use. Section 4.1.6 explains that Telnet and FTP do not encrypt sessions, so credentials, configuration data and patient information can be captured, and flags improper third-party vendor connections. Section 1.1 notes that most pumps ship with a default maintenance passcode.

The FDA states on its cybersecurity page that it is not aware of patient injuries or deaths associated with these alerts, but that unpatched vulnerabilities may potentially lead to patient harm. Treat every pump advisory as a joint clinical engineering, pharmacy and security decision. See the FDA Medical Device Cybersecurity Guide for the manufacturer side.

Network architecture for pumps

The NCCoE example implementation places each zone in its own VLAN connected to the core through a firewall, with subnets matching VLANs, and states that there is no inherent trust between network zones. Its zones include core network, guest network, business office, database server, enterprise services, clinical services, biomedical engineering, medical devices with wireless LAN, and remote access for external vendor support. Firewall rules differ by zone purpose, and core routers share routes through authenticated OSPF.

• Wireless: the NCCoE build used pumps and access points supporting WPA2-Enterprise with EAP-TLS and a network access control service for authentication. Avoid pre-shared keys for pump SSIDs, because a key recovered from one decommissioned pump unlocks the whole fleet. See the 802.1X and EAP-TLS Enterprise Wi-Fi Guide.
• Patching the wireless layer: SP 1800-8 section 4.2 says all patching should be applied, including fixes for the KRACK WPA2 flaws. Track access point and controller firmware with the same urgency as pump firmware.
• Segmentation design: the Hospital Clinical Network Segmentation Guide covers zone design across all clinical systems; for pumps, the key point is that drug library distribution must survive a segmentation change.

Identity, certificates and access

• Device certificates: the NCCoE build used a certificate authority and device provisioning tooling to issue certificates to pumps, and section 4.2 recommends mutual TLS and certificate-based authentication for the pump server. Plan certificate lifetimes against the pump's operational life and the effort of re-provisioning hundreds of devices. See the IoT and Device Certificate Provisioning (EST, SCEP) Guide.
• Maintenance passcodes: change default maintenance and biomedical passcodes where the device allows it, store them in a privileged access vault, and restrict who knows them. Where the passcode is fixed by the manufacturer, record that as an accepted risk with compensating physical controls.
• Pump server administration: the NCCoE build used a console management tool providing role-based access control and recording all management actions. Apply the same model with your own privileged access tooling: named accounts, MFA, session recording and no shared vendor accounts.
• Service and interface accounts: integration accounts between the pump server and EHR or medication systems are non-human identities with clinical impact. Inventory them, rotate their credentials, and alert on interactive use. See the Healthcare Identity Security Guide.
• Drug library authorship: separate the roles of drafting, pharmacist approval and publishing a library release, and keep an auditable record of each version pushed to pumps.

Implementation: a phased programme

1. Inventory. Identify every pump, wireless module and server with model, firmware, location, network address and owner. The NCCoE used network access control profiling to discover and profile connected devices; reconcile that with the clinical engineering asset system.
2. Collect manufacturer documentation. Obtain the MDS2 form, port and protocol list, SBOM where available and patch support dates for each model. See the MDS2 and Medical Device SBOM Guide for Hospitals.
3. Risk assess with clinical input. Use the SP 1800-8 questionnaire approach with pharmacy, nursing and clinical engineering, ranking risks by patient impact as well as data exposure.
4. Segment in monitor mode first. Build the pump VLAN and firewall rules, log matching traffic for several weeks, then enforce. Test drug library push, event log upload and any EHR auto-programming in a pilot ward before hospital-wide enforcement.
5. Move Wi-Fi to EAP-TLS. Provision device certificates in batches during routine maintenance, keeping the old SSID available only until each pump has moved, then retire it and rotate any shared key.
6. Close legacy services. Apply manufacturer updates that disable Telnet and FTP, and block those protocols at the firewall where updates are not yet available.
7. Control vendor access. Replace standing VPNs with brokered, approved and recorded sessions.
8. Define rollback. For every network or firmware change, document how pumps continue to operate safely if connectivity is lost (confirm the behaviour with the manufacturer) and how to revert the change within the clinical downtime window. See the Clinical Downtime and EHR Downtime Procedures Guide.
9. Decommission safely. Follow manufacturer data erasure procedures, which for the products in ICSMA-22-251-01 include resetting network settings, deleting the drug library and clearing the history log, before any device leaves the organisation.

Decision guidance

• Patch now or compensate: pump firmware updates can require clinical validation and device-by-device work. Where a fix is not yet deployable, network isolation, blocking unused protocols and monitoring are the compensating controls advisories recommend.
• Wireless or wired: disabling wireless removes a remote attack path but, as the ICSMA-22-251-01 vendor guidance notes, slows drug library updates. Use it as a last resort for models with unmitigated, remotely exploitable flaws.
• Smaller hospitals: with few staff, prioritise a dedicated pump SSID and VLAN, blocking Telnet and FTP, changing default passcodes and a decommissioning checklist. These need little tooling.
• Large systems: centralise pump server hosting with strong change control, use network access control for device profiling, and feed pump traffic into the security operations centre with clinical engineering on the escalation path.
• Replacement planning: when a pump model leaves manufacturer support, include security capability (802.1X, encryption at rest, mutual authentication, signed firmware) in procurement criteria for its successor. The FDA's final premarket cybersecurity guidance of June 2025, which superseded the September 2023 version and added recommendations under section 524B for "cyber devices", sets out what manufacturers should submit, so ask bidders for the security documentation that guidance expects, including an SBOM and their vulnerability disclosure and patching commitments over the device's supported life.
• Who owns the decision: agree a standing triage group of clinical engineering, pharmacy, nursing informatics and security, with authority to approve compensating controls, so pump advisories do not wait for a committee cycle.

Detection and measurement

The NCCoE build included network anomaly detection and a side-channel integrity assessment of pump behaviour. Most hospitals can start with simpler signals.

• New or unknown devices on the pump VLAN, and pumps appearing on any other VLAN.
• Telnet, FTP or other unexpected protocols to or from pumps, as both vendor and CISA recommend monitoring for.
• Drug library changes outside an approved release, and library pushes from unexpected hosts.
• Pump server logons by vendor or shared accounts outside an approved window.
• Pumps not checking in to the server, which may indicate network failure, tampering or devices removed from service without decommissioning.

Common failure patterns

• Shared Wi-Fi key across the fleet: one pump returned for repair without a wipe exposes the key, and with it every pump on that SSID.
• Pumps on the general clinical VLAN: workstations, printers and pumps share a flat network, so ransomware or a compromised laptop can reach the pump server directly.
• Drug library treated as IT data: library releases are pushed by whoever has access to the server, without pharmacist sign-off or version records.
• Standing vendor VPN: a permanent tunnel into the clinical zone, using a shared vendor account, outside the hospital's monitoring.
• Segmentation enforced without a clinical test: a firewall change blocks library distribution or event upload, and clinicians lose updated dosing limits on the wards.
• Advisories filed and forgotten: nobody owns the decision to patch, compensate or accept, so legacy services stay enabled for years.

Framework mapping

Practitioner checklist

• Inventory every pump, wireless module and pump server with firmware, location and owner.
• Place pumps and pump servers in dedicated zones with firewall rules limited to documented flows.
• Move pump Wi-Fi to certificate-based EAP-TLS and retire shared keys.
• Block Telnet and FTP to pumps and apply manufacturer updates that disable them.
• Change default maintenance passcodes where possible and vault them.
• Require pharmacist approval and version records for every drug library release.
• Broker, approve and record all vendor remote access.
• Assign an owner and decision deadline for every pump advisory.
• Wipe network settings, libraries and logs before any device leaves the organisation.
• Test every network or firmware change on a pilot ward with a rollback plan.

Standards and references

• NIST: SP 1800-8 Securing Wireless Infusion Pumps in Healthcare Delivery Organizations
• NIST NCCoE: Securing Wireless Infusion Pumps project
• NIST: SP 1800-8 full publication (PDF)
• CISA: ICS Medical Advisory ICSMA-22-251-01
• FDA: Cybersecurity (medical devices)
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Medical Device Security Guide · Hospital Clinical Network Segmentation Guide · FDA Medical Device Cybersecurity Guide · Healthcare Identity Security Guide