Infusion & Drug Delivery cybersecurity.

• Large-volume IV infusion pumps
• Smart syringe and PCA pumps
• Ambulatory and home infusion pumps
• Insulin and specialty drug-delivery pumps
• Connected auto-injectors and on-body delivery systems

• Pump ↔ hospital Wi-Fi (WPA-Enterprise, certificate-based)
• Pump ↔ drug-library / DERS server (signed payloads)
• Pump ↔ EHR (HL7, infusion documentation)
• Pump ↔ field-service / asset-management tools (authenticated)
• Pump ↔ manufacturer cloud for telemetry (where applicable)

How do you test infusion pumps without a hospital network?

We rebuild a representative hospital network segment in our lab - managed switch, VLAN segmentation, EHR simulator, drug-library distribution server, and pump management server - and run authenticated and unauthenticated tests against it. The lab environment is documented in the test plan so reviewers can map findings back to a defined topology, and on-site testing is reserved for hardware-specific surfaces and customer-environment validation.

Is drug-library distribution in scope for cyber?

Yes, explicitly. The drug library is safety-critical configuration data: a tampered library can produce a clinically meaningful (and litigable) overdose. We test the signing of library payloads, the distribution path from the management server to the pump, signature verification on the pump, rollback behavior, and the audit trail. The SPDF documents key custody, key rotation, and what happens when verification fails.

What about legacy pumps already deployed in the field?

Legacy fleets are addressed through a postmarket cybersecurity management plan under section 524B: SBOM monitoring, CVD intake, vulnerability disclosures, and a documented patching strategy aligned to FDA postmarket guidance and the hospital's ability to absorb updates without disrupting patient care. Where the firmware can no longer accept secure updates, compensating controls (segmentation, ACLs, monitoring) are documented and the EOL/EOS communications plan is part of the package.

Do you cover the pump server / management station?

Yes. The pump management server is treated as a connected system component with its own threat model, OS hardening review, application security testing, and pen test. It's frequently the highest-impact target in the segment because compromising it can affect every pump in the institution. The SPDF documents the server architecture, authentication model, audit logging, and update mechanism alongside the pump itself.

How do you handle interoperability with hospital EHRs (BCMA, smart-pump-EHR)?

HL7 v2 and FHIR endpoints, and any vendor-specific BCMA/smart-pump-EHR integrations, are tested for authentication, authorization, parser robustness under malformed and oversized payloads, and replay/order-injection resistance. We document the assumptions on the hospital network in the IFU and MDS2 - including what segmentation, ACLs, and PKI the institution is expected to provide - so the boundary between device and environment is clear in both clinical and procurement reviews.

Can you support a 510(k) Special for a cyber-only change?

Yes. We deliver a focused delta threat model, an updated SBOM with VEX, and a targeted test report scoped to the cyber change so reviewers can clear the supplement quickly. The package explicitly cross-references the previously cleared submission so the delta is unambiguous, which is what 510(k) Special reviewers look for.

How do you address wireless interfaces (Wi-Fi, BLE, cellular) on infusion pumps?

Each radio is enumerated as a distinct interface with its own threat model: 802.11 WPA2/WPA3-Enterprise configuration, EAP method, certificate validation, BLE pairing mode, and cellular APN/PKI where applicable. We exercise downgrade behavior, rogue AP/peer scenarios, and DoS resistance, and we verify that compromise of one radio cannot escalate into device control. The SPDF documents the supported configurations and the IFU tells the hospital how to deploy them safely.

Do you cover insulin pumps, PCA pumps, and ambulatory pumps differently?

The threat-model topology differs - insulin pumps usually pair with CGMs and a phone; PCA pumps live on the hospital network; ambulatory pumps move between home and clinic - but the same cyber playbook applies: signed configuration, authenticated control, secure updates, monitored telemetry, and a CVD program. We tune the test plan and labeling to the actual deployment topology rather than forcing one shape.

How do you handle alarms, alerts, and clinical decision support tied to the pump?

Alarm integrity is a safety property: suppressed, delayed, or spoofed alarms can cause direct patient harm. We model alarm paths (on-device, nurse call, mobile clinician notification, EHR) explicitly in the threat model and test for tampering at each hop. Findings are tied back to the IEC 14971 risk file so the safety and security teams act on the same evidence.

What standards stack applies to infusion and drug-delivery devices?

Typical baseline: FDA 2026 final premarket cybersecurity guidance, AAMI SW96, AAMI TIR57, IEC 62304 (typically Class C), ISO 14971, IEC 60601-1 with applicable particulars (e.g., -2-24 for infusion pumps), IEC 81001-5-1 for the secure software lifecycle, and IEC 80001 considerations for the connected hospital network. EU manufacturers add MDR Annex I §17.2 and MDCG 2019-16; we map across both regimes.

How long does an infusion-pump premarket cyber engagement typically take?

For a new connected pump platform with a management server and EHR integrations, end-to-end premarket cyber work generally runs 10-16 weeks. Threat modeling and SBOM front-load in weeks 1-4, pen testing across pump, server, distribution, and EHR integrations runs in weeks 4-12, and the consolidated submission package and postmarket plan close in the final weeks - all under a written clearance guarantee.