Body-worn and Home-use Devices (BW)

Body-worn and Home-use Devices (CRI-BW), The Patient: a radiograph of a forearm with a glucose sensor and an insulin pump.

Taxonomies › Hospitals and medical devices › Body-worn and Home-use Devices

The Patient · CRI-BW · suit 02 of 17 · 13 entries

Insulin pumps, CGMs and closed loops, patch and Holter ECG, pulse oximeters, BP cuffs, hearing aids and connected inhalers, and the phones that control them.

Scope: Insulin pumps and CGMs (and closed loops), patch and Holter ECG, pulse oximeters, BP cuffs, hearing aids, connected inhalers; phone apps as the controller, unpaired or spoofed sensors, DIY loops, Bluetooth pairing, data to manufacturer clouds, devices brought into hospital, shared family phones, sold second hand.

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.

Body-worn and Home-use Devices: 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-BW-A Spoofed controller doses insulin

† Direct harm

Threat. The insulin pump accepts bolus and basal commands from a remote or phone app without strong pairing or authentication. A nearby attacker or rogue app can deliver a fatal overdose or quietly stop insulin.

Principle. A pump acts only on dose commands from a paired, authenticated controller, within limits it enforces itself.

Design measures:

  1. Require authenticated, encrypted pairing and verify every dose command’s origin and integrity.
  2. Enforce maximum bolus and daily limits in the pump, whatever the controller asks.
  3. Ask for confirmation on the pump or the paired phone before large boluses.
  4. Alert the user on the pump when an unknown device tries to connect.

Card prompts:

  • Which controllers can send dose commands to the pump?
  • What dose limits does the pump enforce on its own?
  • How is a new controller paired, and who must confirm it?

Mappings: STRIDE S, T, E · CAPEC-151, CAPEC-594 · CWE-306, CWE-290 · ATT&CK T0831 · EMB3D TID-406 · MDS2 NAUT, AUTH, TXIG · FDA premarket; AAMI SW96

CRI-BW-K Closed loop trusts a spoofed sensor

† Direct harm

Threat. An automated insulin delivery algorithm doses from glucose sensor readings with no person in the loop. A spoofed, replayed or faulty reading drives it to overdose or withhold insulin, overnight, while the patient sleeps.

Principle. Automated dosing trusts only authenticated sensor data and stays within safe bounds when data looks wrong.

Design measures:

  1. Authenticate the sensor to the controller and protect readings against injection and replay.
  2. Check readings for physiological plausibility and rate of change before dosing on them.
  3. Fall back to a conservative basal rate and alert when sensor data is missing or implausible.

Card prompts:

  • How does the dosing algorithm know a sensor reading is genuine?
  • What does the loop do when readings look implausible?
  • What bounds stop the loop overdosing while the patient sleeps?

Mappings: STRIDE S, T · CAPEC-194 · CWE-1293, CWE-940 · ATT&CK T1565.002 · EMB3D TID-406 · MDS2 NAUT, IGAU · FDA premarket; ISO 14971

CRI-BW-Q Phone app as the controller

† Direct harm

Threat. The app that controls a pump or reads a sensor runs on a phone the manufacturer does not control: rooted, out of date, shared, full of other apps. Malware or an operating system change can alter doses or stop the app working.

Principle. A therapy-critical app assumes the phone may be hostile and keeps safety decisions on the medical device.

Design measures:

  1. Keep dose limits and safety checks on the pump, never only in the app.
  2. Check the phone’s integrity and operating system version, and warn or degrade safely when unsupported.
  3. Publish a list of supported phones and versions, and test new operating system releases before users get them.

Card prompts:

  • Which safety decisions are made on the phone rather than the device?
  • What happens to therapy if the phone is rooted or out of date?
  • How does the app behave after an operating system update?

Mappings: STRIDE T, E, D · CAPEC-441 · CWE-1357, CWE-602 · MDS2 MLDP, RDMP, SGUD · IEC 81001-5-1; IEC 62304

CRI-BW-J Firmware pushed through the phone

† Direct harm

Threat. Device updates arrive through the companion app without the device verifying them, or install at a bad moment. A modified update takes control of therapy, and a failed one leaves the patient without insulin or monitoring at night.

Principle. The device verifies every update itself and installs only when therapy can safely pause or continue.

Design measures:

  1. Verify a manufacturer signature on the device; never rely on the app to check.
  2. Schedule installation with the user and keep therapy running from the previous image until the new one is proven.
  3. Prevent rollback to vulnerable versions and keep a recovery image.

Card prompts:

  • Does the device verify an update itself, or trust the app?
  • When is an update allowed to install, and who decides?
  • What does the patient do if an update fails overnight?

Mappings: STRIDE T, D, E · CAPEC-186 · CWE-494, CWE-347 · ATT&CK T1495 · EMB3D TID-211, TID-217 · MDS2 CSUP, IGAU · FDA premarket

CRI-BW-10 Cloud account takeover

† Direct harm

Threat. Manufacturer cloud accounts for patients and caregivers use reused passwords and no second factor. Taking one over exposes years of readings and, where the service allows, changes alarm thresholds or therapy settings remotely.

Principle. Cloud accounts that can see or change therapy are protected like clinical systems.

Design measures:

  1. Offer and encourage multi-factor authentication, and require it for any account that can change settings.
  2. Detect credential stuffing and unusual logins, and notify the patient of new devices.
  3. Require confirmation on the medical device for any remote settings change.

Card prompts:

  • What can a caregiver or patient cloud account change remotely?
  • Do cloud accounts need a second factor before changing settings?
  • Who is alerted when alarm thresholds change from the cloud?

Mappings: STRIDE S, I, T · LINDDUN I, DD · CAPEC-600 · CWE-308, CWE-307 · ATT&CK T1078, T1110 · MDS2 PAUT, AUTH · IEC 81001-5-1

CRI-BW-9 Alarms lost on the phone

† Wrong or delayed treatment

Threat. Low and high glucose or arrhythmia alerts travel through the phone. Battery optimisation, do-not-disturb, revoked permissions or an operating system update silence them, and nobody notices the alarm path has broken until a patient is harmed.

Principle. The alarm path is monitored end to end, and a broken path is itself loud.

Design measures:

  1. Use critical-alert channels where the platform offers them, and check permissions on every launch.
  2. Send a periodic test or heartbeat and warn the user when the app cannot raise alerts.
  3. Keep an audible alarm on the medical device itself for the most dangerous conditions.

Card prompts:

  • What on the phone could silence a low glucose alert?
  • How would anyone know the alarm path had broken?
  • Is there a second route for critical alerts besides the phone?

Mappings: STRIDE D · CWE-754 · ATT&CK T0878 · MDS2 SGUD, CONN · IEC 80001-1; ISO 14971

CRI-BW-8 Radio stack crash stops therapy

† Direct harm

Threat. Malformed Bluetooth packets crash or hang the device’s radio chip or stack. Readings stop, the pump or hearing aid freezes, and the device may not restart into a safe state until someone notices.

Principle. Faults in the radio stack cannot stop therapy or leave the device in an unsafe state.

Design measures:

  1. Isolate the radio from therapy logic so a radio fault cannot halt delivery or sensing.
  2. Use a watchdog that restarts the radio and alerts the user without interrupting therapy.
  3. Track vulnerabilities in the radio chip’s software and fuzz the stack before release.

Card prompts:

  • What happens to therapy if the radio stack crashes or hangs?
  • Does the device restart into a safe state on its own?
  • Has the Bluetooth stack been tested against malformed packets?

Mappings: STRIDE D · CAPEC-666, CAPEC-28 · CWE-617, CWE-754 · ATT&CK T1499 · EMB3D TID-202, TID-404 · MDS2 SAHD, CSUP · FDA premarket

CRI-BW-7 Weak pairing invites strangers

† Direct harm

Threat. Pairing uses fixed PINs, legacy modes or no confirmation, or lets a nearby device push the link down to weak encryption. A stranger pairs, listens in or injects readings and commands.

Principle. Pairing is deliberate, confirmed by the user and resistant to downgrade.

Design measures:

  1. Use authenticated pairing with out-of-band confirmation such as a code shown on the device.
  2. Refuse legacy pairing and keys shorter than current standards allow.
  3. Show paired devices to the user and let them remove any they do not recognise.

Card prompts:

  • How does pairing confirm the user really meant to pair?
  • Can a nearby device force the link down to weaker encryption?
  • Which pairing modes remain enabled that nobody needs?

Mappings: STRIDE S, I, T · LINDDUN DD · CAPEC-668, CAPEC-667, CAPEC-620 · CWE-1390, CWE-326 · ATT&CK T0860 · EMB3D TID-411 · MDS2 NAUT, TXCF · FDA premarket

CRI-BW-6 No supported way to automate

† Direct harm

Threat. With no supported way to automate their therapy, some patients build or download unofficial loops that drive older pumps through weak radio protocols. Nobody else knows what is dosing, and vulnerable pumps stay in service by choice.

Principle. Patients have a supported, secure way to get the automation they need, and devices make unofficial control visible.

Design measures:

  1. Offer supported interoperability through authenticated, documented interfaces.
  2. Record on the device which controller issued each dose so clinicians can see it.
  3. Give clinicians guidance on reviewing patients who use unofficial controllers, without penalising them.

Card prompts:

  • Do patients have a supported way to automate their therapy?
  • Would the device or clinic notice an unofficial controller dosing?
  • Which older pumps stay in service because unofficial loops need them?

Mappings: STRIDE S, R, E · CAPEC-212 · CWE-1357 · MDS2 RDMP, CONN, AUDT · IEC 80001-1

CRI-BW-5 Home readings without provenance

† Wrong or delayed treatment

Threat. Readings from home blood pressure cuffs, pulse oximeters or ECG patches upload with no way to tell which device or person produced them. A family member’s, replayed or edited values enter the record and shape treatment.

Principle. Every home reading carries authenticated provenance: which device, which patient, when.

Design measures:

  1. Bind each device to one patient at enrolment and sign readings on the device.
  2. Show provenance and any manual edits beside the reading in the clinical record.
  3. Flag readings that arrive late, out of sequence or from an unbound device.

Card prompts:

  • How does the record know which device and patient produced a reading?
  • Could a family member’s or replayed reading enter the record?
  • Which home readings change treatment without a clinician checking them?

Mappings: STRIDE S, T, R · LINDDUN I · CAPEC-194 · CWE-346, CWE-1293 · ATT&CK T1565.002 · EMB3D TID-406 · MDS2 IGAU, NAUT · IEC 81001-5-1

CRI-BW-4 Own devices on the ward

† Wrong or delayed treatment

Threat. Patients bring their own pumps, sensors, hearing aids and phones into hospital. Staff cannot read or control them, they join the guest network or lose their cloud link, and nobody owns their security or the clinical decisions they drive.

Principle. The hospital has an agreed way to accept, use and support patients’ own devices.

Design measures:

  1. Define a policy for patients’ own devices covering who reviews them and how therapy is handed over.
  2. Provide a network path for them that keeps their cloud link without reaching clinical systems.
  3. Record in the patient’s notes which personal devices are in use and their settings.

Card prompts:

  • What is the process for accepting a patient’s own device on the ward?
  • Who owns the security of patients’ own devices while they are inpatients?
  • Which network do patients’ devices join, and what can they reach?

Mappings: STRIDE D, T · CAPEC-700 · CWE-1357 · MDS2 CONN, SGUD · IEC 80001-1

CRI-BW-3 Companion apps sell health data

Threat. Companion apps for inhalers, sensors and monitors carry analytics and advertising code that sends device identifiers and readings to third parties. Patients do not know, and the data links them to a condition for years.

Principle. Health data leaves the app only for the patient’s care, and only with their informed agreement.

Design measures:

  1. Inventory every third-party SDK in the app and remove any that receive health or device data.
  2. Collect the minimum data and state each use in plain language before collection.
  3. Let patients see, export and delete what is held about them.

Card prompts:

  • Which third parties receive data from the companion app?
  • Does the patient know what leaves the app, and agree to it?
  • What analytics or advertising code ships inside the app?

Mappings: STRIDE I · LINDDUN L, I, U, DD, Nc · CAPEC-569 · CWE-359 · MDS2 MPII, DIDT · ISO 27799

CRI-BW-2 Second-hand devices keep old data

Threat. Devices that are resold, loaned, refurbished or reused across family phones keep the previous patient’s data, pairings or cloud account link. The new user’s readings flow to someone else’s account or clinic.

Principle. Every change of user wipes the device and breaks every old link.

Design measures:

  1. Provide a factory reset that erases data, pairings and account links, and verify it.
  2. Require fresh enrolment with the clinic before a reused device sends readings.
  3. Tell patients how to reset devices before passing them on.

Card prompts:

  • What is wiped when a device changes user or is refurbished?
  • Which pairings and cloud links survive a change of owner?
  • How would a new user notice data flowing to someone else?

Mappings: STRIDE I · LINDDUN DD, L, I · CAPEC-675 · CWE-1266, CWE-226 · MDS2 MPII, STCF

Seen in the wild

Mappings

Body-worn and Home-use Devices: 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 8, Spoofing 6, Denial of service 5, Elevation of privilege 4, Information disclosure 4, Repudiation 2 (an entry can carry more than one). 12 map to CAPEC 3.9, 13 to CWE 5.0, 8 to ATT&CK v20.0, 6 to MITRE EMB3D and 5 to LINDDUN. The MDS2 capabilities a buyer should check first are NAUT (4), IGAU (3), SGUD (3). 8 carry the red † for direct harm and 3 the amber † for wrong or delayed treatment. A blank means nothing fitted well; a loose tag would mislead.

← Implants and Programmers · Hospitals and medical devices overview · Patient Monitoring →

© 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.