Medication Delivery (MD)

Medication Delivery (CRI-MD), The Patient: a radiograph of the bones of a hand with an IV cannula and line.

Taxonomies › Hospitals and medical devices › Medication Delivery

The Patient · CRI-MD · suit 05 of 17 · 13 entries

Infusion and PCA pumps, drug libraries, pump-EHR auto-programming, barcode administration, dispensing cabinets, pharmacy robots and controlled drug records.

Scope: Infusion and PCA pumps, drug libraries and their distribution, pump-EHR interoperability (auto-programming), dose limits, barcode medication administration, automated dispensing cabinets, pharmacy robots and compounding, controlled drug records, label printing, diversion.

Entries are ranked Ace (most severe) to 2. In the taxonomy the ID is a stable reference, not a severity: rate each finding in your own system.

Medication Delivery: each entry's ID, title, threat, mitigation principle and design measures. The full text follows below.

Text version: every entry is written out below, with its card prompts and mappings. The same text is in the PDF and Excel downloads on the overview page.

The threats

CRI-MD-A Drug library limits rewritten fleet-wide

† Direct harm

Threat. Drug libraries set the concentrations and hard dose limits for every infusion pump and are pushed to the whole fleet from one server. A tampered library raises or removes limits on every pump at once, so overdoses become possible across the hospital with no error on screen.

Principle. Drug libraries are authenticated end to end and every change is reviewed by pharmacy before it reaches a pump.

Design measures:

  1. Sign approved libraries in the pharmacy tool and have pumps verify the signature before loading.
  2. Require two-person pharmacy approval for any change that raises or removes a hard limit.
  3. Show the library version on each pump and alert centrally when pumps run an unapproved version.

Card prompts:

  • Who can change the drug library, and who reviews each change?
  • How does a pump know a library came from pharmacy unchanged?
  • Would a raised hard limit show anywhere before a patient is harmed?

Mappings: STRIDE T, E · CAPEC-186, CAPEC-75 · CWE-353, CWE-494 · ATT&CK T0836, T0889 · EMB3D TID-213 · MDS2 IGAU, CSUP, AUTH · IEC 80001-1; FDA premarket

CRI-MD-K Infusion pump reprogrammed over network

† Direct harm

Threat. An infusion pump that accepts commands over Wi-Fi or Ethernet without strong authentication can have its rate, volume or drug changed, or be stopped, by anyone on the network. The pump may show the change as a normal programme.

Principle. Pumps accept network commands only from authenticated systems, and dose changes need a clinician at the pump.

Design measures:

  1. Mutually authenticate the pump and its server, and refuse all commands from anything else.
  2. Disable network services the clinical workflow does not use, such as remote shells or diagnostic ports.
  3. Require confirmation at the pump for any change to rate, volume or drug.

Card prompts:

  • Which systems can send commands to a pump over the network?
  • Can a rate or drug change without a clinician at the pump?
  • How would a remote change look different from a normal programme?

Mappings: STRIDE S, T, E · CAPEC-151, CAPEC-137 · CWE-306, CWE-798 · ATT&CK T0836, T0886 · EMB3D TID-310, TID-328 · MDS2 NAUT, AUTH, SAHD · IEC TR 60601-4-5; FDA premarket

CRI-MD-Q Unsigned pump firmware accepted

† Direct harm

Threat. Pumps that install firmware without verifying who built it can be given modified software through the update server, a service laptop or a USB port. Altered firmware can change dose calculation or alarms on every pump that takes the update.

Principle. Pumps run only firmware signed by the manufacturer and verified on the device.

Design measures:

  1. Verify a manufacturer signature at install and at every boot, with the key held in hardware.
  2. Block rollback to older, vulnerable firmware versions.
  3. Restrict update installation to an authenticated, logged service path.

Card prompts:

  • Where does the pump verify that firmware is genuine?
  • Which routes can deliver firmware: update server, laptop, USB?
  • How many pumps would one bad update reach?

Mappings: STRIDE T, E · CAPEC-186, CAPEC-533 · CWE-494, CWE-347 · ATT&CK T0800, T0862 · EMB3D TID-211, TID-213, TID-216 · MDS2 CSUP, IGAU · IEC TR 60601-4-5; FDA premarket; AAMI SW96

CRI-MD-J Auto-programming sends a wrong dose

† Direct harm

Threat. When the EHR programmes the pump directly from the order, nurses learn to trust the prefilled values. A tampered message, a mapping error between order units and pump units, or a spoofed integration server can load the wrong drug, rate or patient.

Principle. Pump-EHR messages are authenticated and every auto-programmed infusion is checked by a person against the order.

Design measures:

  1. Authenticate and integrity-protect messages between the EHR, the interoperability server and the pump.
  2. Match patient, drug and concentration by scanned identifiers before the programme is accepted.
  3. Show the full programme at the pump and require confirmation; never start automatically.

Card prompts:

  • How is an auto-programming message authenticated between EHR and pump?
  • Where could order units and pump units be mapped wrongly?
  • What makes the nurse check prefilled values against the order?

Mappings: STRIDE S, T · CAPEC-94, CAPEC-148 · CWE-353, CWE-924 · ATT&CK T1565.002, T0830 · EMB3D TID-406 · MDS2 TXIG, NAUT, IGAU · IEC 80001-1; IEC TR 60601-4-5

CRI-MD-10 PCA limits loosened

† Direct harm

Threat. Patient-controlled analgesia pumps let patients give themselves opioid doses within a lockout and hourly limit. If those limits can be changed remotely, by a shared clinician code or through a weak key lock, a patient can receive a fatal dose.

Principle. PCA limits change only with individual clinician authentication at the pump and stay within pharmacy-approved bounds.

Design measures:

  1. Require individual clinician authentication at the pump to change PCA limits.
  2. Enforce library hard limits on lockout and hourly dose that the bedside cannot override.
  3. Use a physical lock for the drug reservoir and alarm on door opening.

Card prompts:

  • Who can change PCA lockout and hourly limits, and how?
  • Are clinician codes on PCA pumps individual or shared?
  • What bounds does pharmacy set that no one can exceed?

Mappings: STRIDE T, E · CAPEC-122, CAPEC-391 · CWE-1391, CWE-1263 · ATT&CK T0836 · EMB3D TID-311 · MDS2 PAUT, AUTH, PLOK · IEC TR 60601-4-5

CRI-MD-9 Barcode checks quietly bypassed

† Direct harm

Threat. Barcode medication administration only protects patients when the scans are real. Relabelled drugs, copied wristbands, a scanner that accepts typed numbers, or a degraded mode that skips checks during an outage lets the wrong drug reach the wrong patient.

Principle. Bedside checks depend on scanned identifiers that cannot be typed or copied, and degraded modes are visible and recorded.

Design measures:

  1. Disable manual entry of drug and patient identifiers, or require a second clinician to witness it.
  2. Make any bypass or degraded mode visible on the ward and report bypass rates daily.
  3. Use tamper-evident wristbands and verify barcodes against the pharmacy dispensing record.

Card prompts:

  • Can a scanner accept a typed number instead of a scan?
  • What happens to bedside checks when the system is down?
  • How would copied wristbands or relabelled drugs be caught?

Mappings: STRIDE S, T, R · CAPEC-148, CAPEC-554 · CWE-807, CWE-602 · ATT&CK T1036 · MDS2 AUDT, IGAU · IEC 80001-1

CRI-MD-8 Compounding robot recipes altered

† Direct harm

Threat. Pharmacy robots and compounding systems prepare chemotherapy, parenteral nutrition and syringes from stored recipes and the order feed. An altered recipe or calibration produces many wrong-strength doses that look correctly labelled.

Principle. Recipes and calibration in compounding systems are controlled documents, and outputs are verified independently.

Design measures:

  1. Sign recipes and require pharmacist approval for each change, with version history.
  2. Verify each preparation by gravimetric or analytical check independent of the robot’s own software.
  3. Restrict the robot’s network access to the pharmacy system it serves.

Card prompts:

  • Who controls changes to compounding recipes and calibration?
  • How is a prepared dose checked independently of the robot?
  • How many doses would one altered recipe affect before anyone noticed?

Mappings: STRIDE T · CAPEC-176, CAPEC-165 · CWE-353, CWE-732 · ATT&CK T0836, T1565.001 · MDS2 IGAU, AUTH, AUDT · IEC 80001-1

CRI-MD-7 Pumps report infusing when stopped

† Direct harm

Threat. Central infusion views and alarm routing depend on status messages from pumps. A flood of traffic, a crashed pump stack or a forged status can stop an infusion of a vasoactive or sedative drug while the ward screen still shows it running.

Principle. Loss of infusion is detected and alarmed at the pump, not inferred from network status.

Design measures:

  1. Alarm locally at the pump on any stop or occlusion, independent of the network.
  2. Show stale or missing pump status as unknown at the central view, never as the last good value.
  3. Test pump network stacks against flooding and malformed traffic.

Card prompts:

  • How does the ward know an infusion has really stopped?
  • Does the pump alarm locally, or only through the network?
  • Could a forged status hide a stopped vasoactive infusion?

Mappings: STRIDE D, S · CAPEC-125, CAPEC-194 · CWE-770, CWE-392 · ATT&CK T0815, T0814 · EMB3D TID-405, TID-202 · MDS2 TXIG, SAHD · IEC 80001-1; IEC TR 60601-4-5

CRI-MD-6 Dispensing cabinets fail closed

† Wrong or delayed treatment

Threat. Automated dispensing cabinets unlock drawers only after checking orders and users with a central server. During a network outage or ransomware the cabinets lock, and emergency drugs are out of reach on the ward.

Principle. Cabinets keep emergency drugs available offline, with access recorded for later reconciliation.

Design measures:

  1. Hold a cached order and user list on each cabinet with an offline emergency mode.
  2. Keep a sealed emergency key procedure and practise it in downtime drills.
  3. Record all offline access locally and reconcile it when the server returns.

Card prompts:

  • Can staff reach emergency drugs when the cabinet server is down?
  • How is offline cabinet access recorded and reconciled later?
  • When was cabinet failure last rehearsed on a ward?

Mappings: STRIDE D · CAPEC-607 · CWE-636 · ATT&CK T0826, T0813 · MDS2 EMRG, DTBK · IEC 80001-1

CRI-MD-5 Pharmacy labels misprinted

† Wrong or delayed treatment

Threat. Labels for prepared doses and patient medication are printed from pharmacy systems through shared print queues. Altered label templates or queue tampering can print the wrong strength, route or patient on correctly prepared doses.

Principle. What is printed on a label is generated and checked from the verified dispensing record.

Design measures:

  1. Print labels only from the verified dispensing record, with the label content signed or check-summed.
  2. Isolate pharmacy label printers from general print queues.
  3. Scan the printed label back against the record before release.

Card prompts:

  • Where are label templates kept, and who can change them?
  • Is the printed label checked against the dispensing record?
  • Who else shares the print queues that pharmacy labels use?

Mappings: STRIDE T · CAPEC-148, CAPEC-75 · CWE-353 · ATT&CK T1565.001 · MDS2 IGAU

CRI-MD-4 Controlled drug records falsified

Threat. Electronic controlled-drug registers and cabinet logs can be edited by privileged users, shared accounts or service tools. Diversion of opioids is hidden, patients get substituted or short doses, and investigations cannot show who took what.

Principle. Controlled drug records are attributable to individuals and cannot be changed without trace.

Design measures:

  1. Require individual authentication and a witness for every controlled-drug transaction.
  2. Make the register append-only, with corrections as new entries.
  3. Analyse transactions for diversion patterns and review them routinely.

Card prompts:

  • Can every controlled drug entry be traced to one person?
  • Who can edit the register, including service tools?
  • How would opioid diversion show up in these records?

Mappings: STRIDE R, T · LINDDUN Nr · CAPEC-268, CAPEC-122 · CWE-778, CWE-862 · ATT&CK T1565.001, T1078 · MDS2 AUDT, PAUT, AUTH

CRI-MD-3 Pumps run stale drug libraries

† Direct harm

Threat. Pumps that are off the network, in storage or on loan never receive library updates, and nothing reports which version each pump holds. A withdrawn concentration or an unsafe old limit stays in use without anyone knowing.

Principle. Every pump’s library version is known, and outdated pumps are kept out of use.

Design measures:

  1. Report each pump’s library version centrally and flag pumps that have not checked in.
  2. Block programming from a library older than an approved minimum version.
  3. Include library checks in the process for pumps returning from storage, repair or loan.

Card prompts:

  • How do you know which library version each pump holds?
  • What happens to pumps in storage or on loan when libraries change?
  • Can a pump with an outdated library still be used on a patient?

Mappings: STRIDE T · CAPEC-176 · CWE-672 · EMB3D TID-210 · MDS2 CSUP · IEC 80001-1

CRI-MD-2 Infusion history leaks patient data

Threat. Pumps and their servers keep infusion histories with drug, dose, time and often patient identifiers. Transmitted in clear, stored unencrypted on the pump, or left on decommissioned units, they reveal sensitive treatments such as chemotherapy or HIV therapy.

Principle. Infusion histories are minimised, encrypted and wiped when a pump leaves service.

Design measures:

  1. Encrypt pump data at rest and in transit to the server.
  2. Keep only the identifiers the workflow needs on the pump itself.
  3. Wipe pumps verifiably before repair, resale or disposal.

Card prompts:

  • What patient details do pumps keep in their infusion history?
  • Is infusion history encrypted on the pump and in transit?
  • What is wiped before a pump leaves the hospital?

Mappings: STRIDE I · LINDDUN DD, I, L · CAPEC-117, CAPEC-675 · CWE-319, CWE-359, CWE-226 · ATT&CK T0882 · EMB3D TID-408, TID-108 · MDS2 STCF, TXCF, MPII · IEC 80001-1; ISO 27799

Seen in the wild

  • Hospira Symbiq infusion pumps, 2015 (CRI-MD-K). The FDA advised hospitals to stop using Hospira Symbiq infusion pumps because they could be accessed remotely over the hospital network and their dosing changed. Sources: MDDI: FDA, stop using infusion pump vulnerable to hacking.
  • URGENT/11, 2019 (CRI-MD-7). The FDA warned that 11 vulnerabilities in IPnet, a third-party network stack inside several embedded operating systems, could let attackers take over or crash medical devices and hospital network equipment, and that manufacturers might not know their products contained it. Sources: Healthcare IT News: URGENT/11, FDA issues alert.

Mappings

Medication Delivery: the mappings of each entry to STRIDE, LINDDUN, CAPEC, CWE, ATT&CK, EMB3D, MDS2 and standards.

Across the 13 entries, the STRIDE counts are Tampering 10, Elevation of privilege 4, Spoofing 4, Repudiation 2, Denial of service 2, Information disclosure 1 (an entry can carry more than one). 13 map to CAPEC 3.9, 13 to CWE 5.0, 12 to ATT&CK v20.0, 8 to MITRE EMB3D and 2 to LINDDUN. The MDS2 capabilities a buyer should check first are IGAU (6), AUTH (5), CSUP (3). 9 carry the red † for direct harm and 2 the amber † for wrong or delayed treatment. A blank means nothing fitted well; a loose tag would mislead.

← Life Support and Therapy · Hospitals and medical devices overview · Imaging and Radiation →

© 2026 Jonathan Brett Crawley. Licensed under CC BY-NC-ND 4.0 with additional permissions: see the licence on the hospitals and medical devices overview.