> ## Content Index
> Fetch the complete content index at: https://www.ostering.com/llms.txt
> Use this file to discover other available public pages before exploring further.
# Implants and Programmers (IM)
- URL: https://www.ostering.com/taxonomies/hospital-and-medical-devices/cri-implants-and-programmers/
- Published: 2026-11-05T21:00:00.000Z
- Updated: 2026-11-05T20:43:56.844Z
- Description: Implants and Programmers: 13 threats in the Hospital and Medical Device Threat Taxonomy, each with a principle, design measures and mappings.
- Author: Brett Crawley
[Taxonomies](/taxonomies/) › [Hospitals and medical devices](/taxonomies/hospital-and-medical-devices/) › Implants and Programmers
**The Patient · CRI-IM · suit 01 of 17 · 13 entries**
Pacemakers, ICDs, neurostimulators, cochlear and retinal implants and implantable pumps, with the programmers, home transmitters and clouds that talk to them.
**Scope:** Pacemakers, ICDs, neurostimulators, cochlear and retinal implants, implantable pumps; RF and BLE telemetry, clinic programmers, bedside/home transmitters and their cloud, firmware updates in the body, battery-draining, therapy changes, explant cost, abandoned implants, emergency access for an unconscious patient vs authentication, magnet modes, patient data from remote follow-up.
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.
*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](/taxonomies/hospital-and-medical-devices/#downloads).*
## The threats
### CRI-IM-A Unauthenticated therapy commands over the air
**† Direct harm**
**Threat.** The implant accepts programming commands over its radio link without proving the programmer is genuine. Anyone within range with a suitable transmitter could change pacing, stop therapy or deliver a shock.
**Principle.** An implant acts only on commands from a programmer it has authenticated, over a link protected for integrity.
**Design measures:**
1. Require mutual authentication between implant and programmer before any therapy-changing command is accepted.
2. Protect every command with message integrity and freshness so injected or altered commands are rejected.
3. Limit the commands available over long-range radio; keep therapy changes to close-range sessions.
4. Log every programming session in the implant for review at the next follow-up.
**Card prompts:**
- How does the implant know the programmer talking to it is genuine?
- Which therapy changes can be made over the radio link at all?
- What stops a nearby transmitter injecting a programming command?
**Mappings:** STRIDE S, T, E · CAPEC-594, CAPEC-216 · CWE-306, CWE-940 · ATT&CK T0831 · EMB3D TID-406, TID-310 · MDS2 NAUT, AUTH, TXIG · FDA premarket; AAMI SW96; ISO 14971
### CRI-IM-K Malicious firmware loaded into the body
**† Direct harm**
**Threat.** Firmware for the implant can be installed from a programmer or home transmitter without verifying who signed it. A modified build changes therapy or bricks the device, and the only recovery is surgery to replace it.
**Principle.** Implant firmware is accepted only when signed by the manufacturer and is never allowed to roll back to a weaker version.
**Design measures:**
1. Verify a manufacturer signature in the implant before installing any firmware, whatever channel delivered it.
2. Refuse rollback to earlier firmware with known vulnerabilities.
3. Keep a protected fallback image and safe therapy mode if an update fails or is interrupted.
4. Restrict firmware installation to in-clinic sessions with a clinician present unless risk analysis justifies remote delivery.
**Card prompts:**
- Who signs implant firmware, and where does the implant check it?
- Can an older, weaker firmware version be installed again?
- What happens to therapy if an update fails part way?
**Mappings:** STRIDE T, E, D · CAPEC-186, CAPEC-669 · CWE-494, CWE-347 · ATT&CK T1495 · EMB3D TID-211, TID-213, TID-216 · MDS2 IGAU, CSUP · FDA premarket; IEC 81001-5-1
### CRI-IM-Q Remote monitoring cloud controls thousands
**† Direct harm**
**Threat.** Home transmitters link implants to the manufacturer's cloud for follow-up and updates. If that cloud or its update path is compromised, an attacker reaches every connected patient at once: harvesting their data, altering transmitters or pushing changes towards implants.
**Principle.** A compromise of the remote monitoring service cannot change therapy in the body or reach all patients at once.
**Design measures:**
1. Never let the cloud issue therapy changes; reserve them for authenticated clinician sessions.
2. Sign transmitter updates offline and verify them on the transmitter, so cloud compromise alone cannot push code.
3. Segment the service by region and clinic, and rate-limit any fleet-wide action with human approval.
4. Encrypt implant data end to end from transmitter to the clinic, not only to the cloud.
**Card prompts:**
- What can the monitoring cloud actually change in a patient's implant?
- How many patients would one cloud compromise reach?
- Who reviews changes pushed to home transmitters before release?
**Mappings:** STRIDE S, T, I, E · LINDDUN DD, L · CAPEC-187, CAPEC-439 · CWE-940, CWE-1357 · ATT&CK T1199, T1195.002 · EMB3D TID-303 · MDS2 RMOT, NAUT, CONN · IEC 81001-5-1; FDA premarket
### CRI-IM-J Locked out in an emergency
**† Direct harm**
**Threat.** Locking the implant to authenticated programmers can stop an emergency team reading or adjusting it for an unconscious patient far from their clinic. Leaving it open to any programmer instead leaves it open to anyone. Either design can harm the patient.
**Principle.** Emergency access is a deliberate, narrow and logged path, designed with clinicians, not a side effect of weak authentication.
**Design measures:**
1. Provide an emergency mode that needs close physical proximity, such as an inductive or magnet trigger, and expires quickly.
2. Limit emergency mode to reading status and applying safe therapy settings.
3. Record every emergency session in the implant and report it at the next follow-up.
4. Give patients an ID card and publish the emergency procedure for emergency departments worldwide.
**Card prompts:**
- How does an emergency team read this implant far from its clinic?
- What can emergency access change, and for how long?
- Where is an emergency session recorded, and who reviews it?
**Mappings:** STRIDE S, E, D · CAPEC-115 · CWE-636 · MDS2 EMRG, AUDT, PAUT · ISO 14971; AAMI SW96
### CRI-IM-10 Replayed programming sessions
**† Direct harm**
**Threat.** Programming messages carry no freshness check, so a recorded session can be played back later. A therapy change the patient once needed is reapplied when it is no longer safe, or a reset is repeated.
**Principle.** Every programming command is fresh, bound to one session and useless if replayed.
**Design measures:**
1. Bind commands to a session key agreed at the start of each authenticated session.
2. Use counters or nonces so the implant rejects any message it has already processed.
3. Expire sessions on a short timer and when the programmer moves out of range.
**Card prompts:**
- What makes each programming command unusable a second time?
- How is a command tied to one programming session?
- Would the implant notice a recorded session played back next week?
**Mappings:** STRIDE S, T · CAPEC-94 · CWE-294 · ATT&CK T0830 · EMB3D TID-407, TID-221 · MDS2 TXIG, NAUT · FDA premarket
### CRI-IM-9 Magnet and test modes as backdoors
**† Direct harm**
**Threat.** Magnet modes, factory test commands and undocumented engineering functions stay reachable in released implants. They suspend shocks, force fixed-rate pacing or expose memory without any electronic authentication, and few clinicians know they exist.
**Principle.** Every mode that changes therapy is documented, intended for clinical use and controlled; nothing from manufacturing survives in release.
**Design measures:**
1. Remove or permanently lock factory test and debug commands before implantation.
2. Document every magnet and special mode and its clinical effect in the labelling.
3. Log entry into special modes and show it at the next interrogation.
4. Test released firmware for undocumented commands as part of security verification.
**Card prompts:**
- Which magnet, test or engineering modes remain in the released implant?
- Who knows these modes exist, and are they documented for clinicians?
- Can any of these modes be triggered without authentication?
**Mappings:** STRIDE T, E · CAPEC-36, CAPEC-121 · CWE-912, CWE-1269 · ATT&CK T0858 · EMB3D TID-224, TID-401 · MDS2 SAHD, AUDT · FDA premarket; AAMI SW96
### CRI-IM-8 Abandoned implants
**† Wrong or delayed treatment**
**Threat.** The manufacturer leaves the market, is sold or stops supporting a product. Patients keep an implant that no clinic can program, no one patches and no one answers for, and replacing it means surgery.
**Principle.** Support for an implant is planned for the life of the patient's device, including what happens if the manufacturer cannot provide it.
**Design measures:**
1. Publish an end-of-support date and a support plan covering programmers, updates and vulnerability handling.
2. Escrow programmer software, keys and specifications so a successor or regulator can support patients.
3. Design implants to keep safe default therapy if their programmers and services disappear.
4. Tell patients and clinicians early when support is ending, with options.
**Card prompts:**
- Who programs and patches this implant if the maker stops supporting it?
- Is support promised for the full life of the patient's device?
- What would patients and clinics be told if the product were withdrawn?
**Mappings:** STRIDE D · CAPEC-682 · CWE-1277, CWE-1329 · EMB3D TID-210 · MDS2 RDMP, CSUP · AAMI SW96; FDA premarket; IEC 81001-5-1
### CRI-IM-7 Battery drained by wake-ups
**† Direct harm**
**Threat.** The implant's radio can be woken by unauthenticated requests. Repeated wake-ups drain a battery that cannot be recharged, forcing early replacement surgery and, before that, possible loss of therapy.
**Principle.** Unauthenticated traffic cannot make the implant spend meaningful energy.
**Design measures:**
1. Keep the radio asleep until a close-range, low-energy wake mechanism or a scheduled window.
2. Rate-limit wake-ups and authentication attempts, and back off sharply after failures.
3. Track energy spent on communication and raise an alert at follow-up if it is abnormal.
**Card prompts:**
- Can an unauthenticated request wake the implant's radio?
- How much battery could repeated wake-ups cost over a month?
- Would the clinic notice unusual radio activity draining the battery?
**Mappings:** STRIDE D · CAPEC-125 · CWE-770, CWE-799 · ATT&CK T1499 · EMB3D TID-405 · MDS2 CONN, NAUT · FDA premarket
### CRI-IM-6 Silent remote follow-up
**† Wrong or delayed treatment**
**Threat.** The home transmitter stops sending, is unplugged, loses its connection or sends stale data, and the clinic treats no news as good news. Alerts for arrhythmias, lead faults or low battery are missed for weeks.
**Principle.** Loss of remote follow-up is itself an alert, raised to the clinic and the patient.
**Design measures:**
1. Expect a heartbeat from every transmitter and alert the clinic when one is overdue.
2. Timestamp and sequence readings so stale or repeated data is visible.
3. Tell the patient on the transmitter or their phone when it cannot reach the service.
**Card prompts:**
- How does the clinic learn that a transmitter has gone silent?
- Who is told when follow-up data stops or goes stale?
- Does no news get treated as good news anywhere in this process?
**Mappings:** STRIDE D, T · CWE-754 · ATT&CK T0829 · MDS2 CONN, IGAU · IEC 80001-1; ISO 14971
### CRI-IM-5 Clinic programmer as the weak link
**† Direct harm**
**Threat.** Clinic programmers run old operating systems, use shared logins and leave the building with field staff. They hold keys and patient data, and a stolen or compromised programmer can reprogram any implant of that make.
**Principle.** A programmer holds no secret that unlocks every implant, and its use is tied to a named, authorised clinician.
**Design measures:**
1. Use per-device or per-session keys issued by a back end, not a fixed key shared by every programmer.
2. Require clinician login on the programmer and revoke lost or stolen programmers remotely.
3. Harden and patch the programmer's operating system, and encrypt patient data stored on it.
**Card prompts:**
- What secrets does a clinic programmer hold, and could one unlock every implant?
- Who may use the programmer, and how is each use attributed?
- What happens when a programmer is lost or stolen?
**Mappings:** STRIDE S, I, E · LINDDUN DD · CAPEC-191 · CWE-321, CWE-1104 · ATT&CK T1005 · EMB3D TID-214 · MDS2 PAUT, PLOK, SAHD · AAMI SW96; IEC 81001-5-1
### CRI-IM-4 Telemetry reveals the patient
**Threat.** Implant telemetry and home transmitter traffic travel unencrypted. Anyone nearby with a receiver learns the device serial, the patient's identity or diagnosis and their heart data.
**Principle.** Implant and transmitter traffic reveals nothing about the patient to a listener.
**Design measures:**
1. Encrypt all telemetry carrying patient or device identifiers.
2. Avoid sending names or diagnoses over the radio; use identifiers the clinic resolves.
3. Verify encryption on the air during security testing, not only in the design.
**Card prompts:**
- What can a listener learn from implant or transmitter traffic?
- Is the patient's identity or diagnosis visible on the radio link?
- Which links between implant, transmitter and cloud are encrypted?
**Mappings:** STRIDE I · LINDDUN I, DD, L · CAPEC-157 · CWE-319 · ATT&CK T1040 · EMB3D TID-408 · MDS2 TXCF · FDA premarket
### CRI-IM-3 Radio identifiers track the patient
**Threat.** The implant or its transmitter broadcasts a fixed identifier. It can be used to detect that a person carries a cardiac or neurological implant and to follow them between places.
**Principle.** The radio does not let a stranger recognise or follow the patient.
**Design measures:**
1. Advertise only when a session is wanted, and with rotating identifiers.
2. Keep fixed serial numbers inside the encrypted session.
3. Review radio behaviour against tracking during privacy impact assessment.
**Card prompts:**
- Does the implant or transmitter broadcast a fixed identifier?
- Could a stranger tell that someone carries an implant?
- How would you stop the radio being used to follow a patient?
**Mappings:** STRIDE I · LINDDUN L, I, D · CAPEC-651 · CWE-359 · MDS2 CONN, TXCF
### CRI-IM-2 No route for researchers' findings
**Threat.** Researchers and patients who find flaws in an implant have no clear way to report them, so issues stay unfixed, reach the public without a fix, or are sold. Clinicians learn about them from the news.
**Principle.** The manufacturer runs coordinated vulnerability disclosure and tells clinicians and patients what to do.
**Design measures:**
1. Publish a vulnerability disclosure policy and a monitored contact, and acknowledge reports promptly.
2. Agree timelines for fixes and advisories with regulators and reporters.
3. Send clinicians clear guidance on clinical risk and actions when an advisory is issued.
**Card prompts:**
- How does a researcher or patient report a flaw in this implant?
- Who tells clinicians and patients what to do about a reported flaw?
- How long does a reported implant flaw usually take to fix?
**Mappings:** STRIDE R, I · CAPEC-188 · MDS2 SGUD, CSUP · AAMI SW96; FDA premarket
## Seen in the wild
- **Medtronic Conexus telemetry, 2019** ([CRI-IM-A](/taxonomies/hospital-and-medical-devices/cri-implants-and-programmers/#cri-im-a), [CRI-IM-4](/taxonomies/hospital-and-medical-devices/cri-implants-and-programmers/#cri-im-4)). US government advisories warned that the Conexus radio protocol used by Medtronic implantable defibrillators, clinic programmers and home monitors had no authentication or encryption, so someone nearby could read or change device settings. Sources: [CISA: ICS Medical Advisory ICSMA-19-080-01](https://cisa.gov/ics/advisories/ICSMA-19-080-01).
- **Abbott (St. Jude Medical) pacemakers, 2017** ([CRI-IM-K](/taxonomies/hospital-and-medical-devices/cri-implants-and-programmers/#cri-im-k)). The FDA approved a firmware update for about 465,000 radio-enabled Abbott pacemakers in the US to stop unauthorised reprogramming; patients had to visit a clinic to have it applied, weighing a small risk of update failure. Sources: [Help Net Security: Patients with St. Jude pacemakers called in for firmware update](https://www.helpnetsecurity.com/2017/08/31/pacemakers-firmware-update/); [CSO: 465,000 Abbott pacemakers vulnerable to hacking need a firmware fix](https://www.csoonline.com/article/3222068/465000-abbott-pacemakers-vulnerable-to-hacking-need-a-firmware-fix.html).
- **Argus II retinal implant, 2020** ([CRI-IM-8](/taxonomies/hospital-and-medical-devices/cri-implants-and-programmers/#cri-im-8)). Second Sight phased out its Argus II retinal implant and, after laying off most staff in March 2020, could no longer support its more than 350 recipients; patients were left with implants that could not be repaired and, in one case, could not get an MRI without the maker's input. Sources: [IEEE Spectrum: Their bionic eyes are now obsolete and unsupported](https://spectrum.ieee.org/bionic-eye-obsolete).
## Mappings
Across the 13 entries, the STRIDE counts are Tampering 6, Elevation of privilege 6, Spoofing 5, Denial of service 5, Information disclosure 5, Repudiation 1 (an entry can carry more than one). 12 map to CAPEC 3.9, 12 to CWE 5.0, 9 to ATT&CK v20.0, 9 to MITRE EMB3D and 4 to LINDDUN. The MDS2 capabilities a buyer should check first are NAUT (4), CONN (4), CSUP (3). 8 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.
---
[Hospitals and medical devices overview](/taxonomies/hospital-and-medical-devices/) · [Body-worn and Home-use Devices](/taxonomies/hospital-and-medical-devices/cri-body-worn-and-home-use-devices/) →
*© 2026 Jonathan Brett Crawley. Licensed under [CC BY-NC-ND 4.0](https://creativecommons.org/licenses/by-nc-nd/4.0/) with additional permissions: see the licence on the [hospitals and medical devices overview](/taxonomies/hospital-and-medical-devices/).*