Networks and Wireless (NW)

Networks and Wireless (CRI-NW), The Hospital: a radiograph of a floor plan with a wireless antenna.

Taxonomies › Hospitals and medical devices › Networks and Wireless

The Hospital · CRI-NW · suit 11 of 17 · 13 entries

Segmentation, legacy systems inside devices, Wi-Fi, WMTS telemetry, Bluetooth, RTLS, device inventory and satellite sites.

Scope: Segmentation of clinical device networks, flat networks, legacy OS devices, Wi-Fi (clinical, staff, guest), WMTS telemetry bands, BLE, RTLS tags, private cellular, network access control, device discovery, DNS/DHCP/NTP dependencies, wireless jamming, remote sites and clinics, IoMT inventory.

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.

Networks and Wireless: 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-NW-A Life support on the office network

† Direct harm

Threat. Monitors, pumps, ventilators and imaging share flat network segments with office PCs and email. Ransomware or a worm landing on one desktop spreads to clinical devices, which stop or must be pulled off the network mid-care.

Principle. Clinical devices sit in segments sized to their safety role, with only the flows they need allowed.

Design measures:

  1. Segment medical devices by function and criticality, and permit only documented flows to named systems.
  2. Block office-to-device traffic by default, including file sharing and remote desktop protocols.
  3. Design devices to keep delivering therapy and local alarms when network segments are isolated in an incident.

Card prompts:

  • Which clinical devices share a segment with office PCs?
  • What flows does each clinical segment actually need?
  • How would ransomware on one desktop reach a ventilator?

Mappings: STRIDE T, D, E · CAPEC-700 · CWE-653, CWE-923 · ATT&CK T1210, T0866 · MDS2 CONN, SAHD · IEC 80001-1; IEC 62443

CRI-NW-K Unpatchable systems inside devices

† Wrong or delayed treatment

Threat. Imaging, lab and monitoring devices run frozen, certified builds of old operating systems that cannot be patched or run endpoint protection without the manufacturer. Known, public exploits reach them as soon as anything else on their network is compromised.

Principle. Devices that cannot be patched are compensated for by the network around them, and replaced on a planned date.

Design measures:

  1. Place unpatchable devices behind dedicated enforcement points that allow only their documented protocols.
  2. Require manufacturers to state patch support periods and validated update timelines at procurement.
  3. Monitor these segments for exploit traffic and keep a replacement date on every device record.

Card prompts:

  • Which devices run operating systems that cannot be patched?
  • What network controls compensate for each unpatchable device?
  • When is each one due to be replaced?

Mappings: STRIDE T, D, E · CAPEC-310 · CWE-1104, CWE-1329 · ATT&CK T1210 · EMB3D TID-210 · MDS2 CSUP, RDMP, MLDP · IEC 80001-1; AAMI SW96

CRI-NW-Q Telemetry lost without an alarm

† Wrong or delayed treatment

Threat. Wireless telemetry and Wi-Fi monitors drop out when the spectrum is jammed, crowded or misconfigured. Ambulatory and cardiac patients go unmonitored while the central station shows stale or missing traces that nobody treats as an alarm.

Principle. Loss of a wireless monitoring link is itself an alarm, raised locally and centrally.

Design measures:

  1. Raise a technical alarm at the bedside and central station whenever a wireless link drops beyond a short threshold.
  2. Survey and manage the spectrum for telemetry bands and clinical Wi-Fi, with interference monitoring in ward areas.
  3. Define which patients cannot be on wireless-only monitoring and plan fallback to wired or observation.

Card prompts:

  • Where on site is wireless monitoring coverage weak?
  • What raises an alarm when a wireless link drops?
  • Who watches the spectrum used by telemetry?

Mappings: STRIDE D · CAPEC-601, CAPEC-604 · CWE-754 · ATT&CK T0815, T0829 · MDS2 CONN · IEC 80001-1; IEC TR 60601-4-5

CRI-NW-J Clinical systems reachable from the internet

Threat. PACS, device consoles and vendor service ports end up reachable from the internet through misconfigured firewalls, NAT rules or vendor cellular modems. Search engines index them, and anyone can find patient images or a way in.

Principle. No clinical system is reachable from the internet except through an authenticated, monitored gateway.

Design measures:

  1. Scan the hospital’s own address ranges from outside regularly and act on any clinical service found.
  2. Ban direct internet exposure of devices and route vendor access through a managed remote-access gateway.
  3. Inventory cellular modems and out-of-band links built into devices and close or monitor them.

Card prompts:

  • Which clinical systems could be found from the internet today?
  • Which vendor modems bypass the hospital firewall?
  • When was external exposure last checked, and by whom?

Mappings: STRIDE I, E · LINDDUN DD · CAPEC-292, CAPEC-300 · CWE-1188, CWE-923 · ATT&CK T1190, T1133 · EMB3D TID-310 · MDS2 CONN, RMOT · IEC 80001-1

CRI-NW-10 Shared network stack flaws

† Direct harm

Threat. Many device types embed the same third-party network stack. One flaw in it lets a single malformed packet crash or take over pumps, monitors and imaging from many makers, and nobody knows which devices carry it.

Principle. The hospital knows which components each device contains and can shield affected devices quickly.

Design measures:

  1. Require SBOMs at procurement and map them against the device inventory so stack flaws resolve to device lists.
  2. Keep network signatures and filtering ready to shield vulnerable device segments within hours.
  3. Require manufacturers to fuzz their network stacks and disclose affected models promptly.

Card prompts:

  • Which devices embed the same third-party network stack?
  • How quickly could affected devices be shielded on the network?
  • Where would you learn about a flaw in that stack?

Mappings: STRIDE D, E · CAPEC-28 · CWE-1395, CWE-1104 · ATT&CK T1210, T0814 · EMB3D TID-202, TID-405 · MDS2 SBOM, CSUP, RDMP · AAMI SW96; FDA premarket

CRI-NW-9 Spoofed and shared Wi-Fi

Threat. Medical devices join clinical Wi-Fi with one pre-shared key that never changes and is printed in service manuals. Anyone with the key can join, impersonate the network with an evil twin, or read and alter device traffic.

Principle. Devices authenticate to the network individually, and the network authenticates itself to devices.

Design measures:

  1. Use certificate-based 802.1X for devices that support it, and per-device keys for those that do not.
  2. Detect rogue and evil-twin access points in clinical areas and contain them.
  3. Rotate any shared keys on staff and vendor departures and remove them from documentation.

Card prompts:

  • How do devices authenticate to clinical Wi-Fi?
  • When did the pre-shared key last change, and who knows it?
  • How would devices detect an evil twin network?

Mappings: STRIDE S, I, T · LINDDUN DD · CAPEC-94, CAPEC-616 · CWE-1391, CWE-322 · ATT&CK T1557.004, T0860 · EMB3D TID-411 · MDS2 NAUT, TXCF · IEC 80001-1

CRI-NW-8 No list of connected devices

Threat. Nobody can say which medical devices are on the network, where they are, what software they run or who owns them. Segmentation, patching, incident response and recalls all start by guessing.

Principle. Every connected device is known, with its location, software, owner and risk recorded and kept current.

Design measures:

  1. Combine passive network discovery with the clinical engineering asset register and reconcile them continuously.
  2. Record software versions, SBOM, network flows and clinical criticality for every connected device.
  3. Make network connection depend on the device being registered.

Card prompts:

  • Can you list every connected device, its location and owner?
  • How is the inventory kept current as devices move?
  • How long would a recall search take today?

Mappings: STRIDE R · CAPEC-169 · MDS2 CONN, SBOM · IEC 80001-1

CRI-NW-7 Bluetooth from the corridor

† Direct harm

Threat. Bedside and wearable devices accept Bluetooth connections with weak or no pairing. Someone in the corridor or next bed can crash them, read readings or send commands, and flaws in common Bluetooth chips affect many devices at once.

Principle. Bluetooth links to clinical devices are authenticated, encrypted and limited to the intended peer.

Design measures:

  1. Require authenticated pairing with numeric comparison or out-of-band exchange, never just-works for therapy devices.
  2. Accept connections only from bonded peers and disable advertising once paired where possible.
  3. Track chipset vulnerabilities through the SBOM and patch or shield affected models.

Card prompts:

  • Which bedside devices accept Bluetooth connections, and how?
  • Could someone in the corridor connect to them?
  • Which common Bluetooth chips do your devices share?

Mappings: STRIDE S, T, D · LINDDUN DD · CAPEC-667, CAPEC-668, CAPEC-666 · CWE-940, CWE-322 · ATT&CK T1011.001 · EMB3D TID-406, TID-408 · MDS2 NAUT, TXCF · FDA premarket; IEC TR 60601-4-5

CRI-NW-6 Clocks and names shared with devices

Threat. Monitors, pumps and the record depend on hospital DNS, DHCP and time servers built for office IT. A failure or spoof misdirects device data or skews timestamps, so trends, alarms and drug timings are recorded out of order.

Principle. Clinical devices rely on core network services that are hardened, redundant and authenticated.

Design measures:

  1. Provide dedicated, redundant DNS, DHCP and time sources for clinical segments.
  2. Use authenticated time and pinned server addresses for devices that support them.
  3. Alert on clock drift between devices and the record beyond a clinical tolerance.

Card prompts:

  • Which DNS, DHCP and time servers do devices depend on?
  • Are those services redundant and protected from spoofing?
  • How would skewed timestamps show up in the record?

Mappings: STRIDE S, T, D · CAPEC-142, CAPEC-697 · CWE-350, CWE-346 · ATT&CK T1557.003 · MDS2 IGAU, CONN · IEC 80001-1

CRI-NW-5 Live ports in public areas

Threat. Network ports in patient rooms, waiting areas and corridors are live and give full access to clinical networks. A visitor or patient plugs in a laptop or small device and reaches monitors and records.

Principle. Only known, authorised devices can use a network port, and public areas have none that reach clinical networks.

Design measures:

  1. Enforce network access control on every port, placing unknown devices in an isolated segment.
  2. Disable unused ports and patch only what each room needs.
  3. Alert on new devices appearing on clinical segments.

Card prompts:

  • Which network ports in public areas are live?
  • What happens when an unknown device plugs in?
  • Could a visitor’s laptop reach a monitor or the record?

Mappings: STRIDE S, E · CAPEC-390 · CWE-1263 · ATT&CK T1200 · MDS2 CONN, PLOK · IEC 80001-1

CRI-NW-4 Location tags leak movements

Threat. Real-time location tags on patients, staff and equipment broadcast identifiers and feed location history to dashboards open to many users. Movements of vulnerable or high-profile patients can be tracked, and spoofed tags send staff looking in the wrong place.

Principle. Location data is collected for a stated purpose, protected like clinical data and limited to those who need it.

Design measures:

  1. Rotate tag identifiers and encrypt tag transmissions where the technology allows.
  2. Restrict location views by role and keep history only as long as its purpose needs.
  3. Tell patients and staff what is tracked and why.

Card prompts:

  • Who can see location history from RTLS dashboards?
  • What purpose justifies tracking each patient or staff tag?
  • How would spoofed tags be detected?

Mappings: STRIDE S, I · LINDDUN L, I, D, U · CAPEC-619, CAPEC-612 · CWE-359 · MDS2 MPII, TXCF · ISO 27799

CRI-NW-3 Patient and guest Wi-Fi not isolated

Threat. Guest and patient Wi-Fi share infrastructure and routing with clinical networks. A patient’s infected laptop, or a device bridging two networks, becomes a path into clinical systems.

Principle. Guest networks are isolated from clinical networks in design, not only by configuration.

Design measures:

  1. Route guest traffic straight to the internet on separate infrastructure or tunnelled VLANs with no internal routes.
  2. Enable client isolation on guest Wi-Fi.
  3. Test isolation after every network change.

Card prompts:

  • How is guest Wi-Fi separated from clinical networks?
  • Could a device bridge guest and clinical networks?
  • What shared infrastructure do both networks use?

Mappings: STRIDE E · CAPEC-700 · CWE-653 · ATT&CK T1599 · MDS2 CONN · IEC 80001-1

CRI-NW-2 Satellite sites trusted completely

Threat. Clinics, community sites and partner buildings connect over links with weaker controls, yet the main network trusts them fully. A compromise at the smallest site reaches the main hospital’s devices.

Principle. Every site is treated as its own trust zone, with only required flows allowed into the main hospital.

Design measures:

  1. Terminate site links at enforcement points that filter to documented services.
  2. Apply the same device and identity standards at small sites, or limit what they can reach.
  3. Monitor inter-site traffic for unexpected protocols.

Card prompts:

  • What can a small clinic site reach in the main hospital?
  • Which flows from satellite sites are actually required?
  • How are controls at the smallest site checked?

Mappings: STRIDE E · CAPEC-700 · CWE-653 · ATT&CK T1199 · MDS2 CONN · IEC 80001-1

Seen in the wild

Mappings

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

Across the 13 entries, the STRIDE counts are Elevation of privilege 7, Denial of service 6, Tampering 5, Spoofing 5, Information disclosure 3, Repudiation 1 (an entry can carry more than one). 13 map to CAPEC 3.9, 12 to CWE 5.0, 11 to ATT&CK v20.0, 5 to MITRE EMB3D and 4 to LINDDUN. The MDS2 capabilities a buyer should check first are CONN (8), TXCF (3), CSUP (2). 3 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.

← Integration and Interoperability · Hospitals and medical devices overview · Clinical Communications →

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