Suppliers, Service and Lifecycle (SV)

Suppliers, Service and Lifecycle (CRI-SV), The Hospital: a radiograph of a laptop, a wrench and a vendor cloud.

Taxonomies › Hospitals and medical devices › Suppliers, Service and Lifecycle

The Hospital · CRI-SV · suit 15 of 17 · 13 entries

Vendor remote service, service laptops, manufacturer clouds, patching rights, end of support, procurement evidence, refurbished devices, disposal and vendor failure.

Scope: Vendor remote service, field engineers and service laptops, manufacturer clouds, patch validation and who may patch, end of support, SBOM and vulnerability disclosure, procurement and MDS2, refurbished and grey-market devices, loaned devices, decommissioning and data left on disposed devices, vendor insolvency, single-supplier dependencies, consumables.

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.

Suppliers, Service and Lifecycle: 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-SV-A One service password, every hospital

† Direct harm

Threat. A manufacturer uses the same service password, key or certificate on every unit it ships, and its engineers know it. Once it leaks, anyone can reach service functions on that model in every hospital at once, and the hospitals cannot change it.

Principle. Service credentials are unique per device, owned by the hospital, and changeable without the vendor.

Design measures:

  1. Require unique per-device service credentials at procurement, and refuse devices with shared or hard-coded ones.
  2. Let the hospital rotate service credentials and issue them to engineers for a visit, logged.
  3. Ask vendors to confirm in writing how service credentials are generated, stored and revoked.

Card prompts:

  • Is any service credential shared across every unit of this model?
  • Can the hospital change service credentials without the vendor?
  • What would one leaked service password open across your sites?

Mappings: STRIDE S, E · CAPEC-70, CAPEC-191 · CWE-798, CWE-1273 · ATT&CK T1078.001, T1199 · EMB3D TID-328, TID-311 · MDS2 PAUT, RMOT, AUTH · FDA premarket; IEC 81001-5-1

CRI-SV-K Always-on vendor remote service

† Wrong or delayed treatment

Threat. Vendors keep permanent tunnels, modems or remote-access tools into their devices for service, outside the hospital’s control. Compromise of the vendor, or of one technician, opens a path into many hospitals’ device networks at once.

Principle. Vendor remote access is brokered, approved per session, recorded, and closed when the work ends.

Design measures:

  1. Route all vendor access through the hospital’s managed access service with multi-factor login and per-session approval.
  2. Remove cellular modems and vendor-installed remote tools that bypass the hospital’s controls.
  3. Record sessions and review them against the service ticket.

Card prompts:

  • Which vendors hold permanent remote access into devices?
  • Who approves each remote service session, and is it recorded?
  • How would you know a vendor tunnel had been misused?

Mappings: STRIDE S, E · CAPEC-555 · CWE-923 · ATT&CK T1133, T1199, T1219 · MDS2 RMOT, AUDT · IEC 80001-1

CRI-SV-Q Care depends on the vendor’s cloud

† Wrong or delayed treatment

Threat. Treatment planning, device configuration, remote follow-up or reporting run in the manufacturer’s cloud. A ransomware attack or outage there stops care at every customer at once, and hospitals have no local fallback.

Principle. Clinically essential functions keep working, at least in a degraded mode, when the vendor’s cloud is unavailable.

Design measures:

  1. Identify which clinical functions need the vendor cloud and require a documented local fallback for each.
  2. Keep local copies of plans, configurations and data needed to treat current patients.
  3. Include the vendor’s incident notification and recovery commitments in the contract and exercise them.

Card prompts:

  • Which clinical functions stop if the vendor’s cloud is down?
  • What degraded mode keeps care running locally?
  • When was a vendor cloud outage last rehearsed?

Mappings: STRIDE D · CWE-1357 · ATT&CK T1489 · MDS2 DTBK, RDMP · IEC 80001-1

CRI-SV-J End of support with no exit

† Wrong or delayed treatment

Threat. Devices run operating systems and components the manufacturer no longer supports, and replacement is unaffordable or years away. Known vulnerabilities stay open in clinical use, and one worm can take out imaging, lab and monitoring together.

Principle. Every device has a planned end of support, and devices past it are isolated and scheduled for replacement.

Design measures:

  1. Record end-of-support dates for each device and its third-party components at purchase.
  2. Isolate unsupported devices in restricted segments with only the flows they need.
  3. Budget replacement cycles from end-of-support dates, and report the unsupported estate to the board.

Card prompts:

  • Which devices are past their manufacturer’s end of support?
  • How are unsupported devices isolated until replacement?
  • When is each unsupported device due to be replaced?

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

CRI-SV-10 Only the vendor may patch

† Wrong or delayed treatment

Threat. Hospitals are not allowed to patch validated devices, and manufacturers take months to validate updates, often without saying what to do meanwhile. Known exploited vulnerabilities stay open, and staff patch anyway and break the device’s validated state.

Principle. Manufacturers commit to timelines for validated updates and give interim mitigations the hospital can apply safely.

Design measures:

  1. Contract for maximum times to validated security updates and for interim compensating controls.
  2. Ask for a list of operating system patches the hospital may apply without revalidation.
  3. Track each open vulnerability on clinical devices with its mitigation and review date.

Card prompts:

  • What timeline has the vendor committed to for validated updates?
  • Which interim mitigations can the hospital apply safely?
  • What happens when staff patch a validated device themselves?

Mappings: STRIDE T, D · CWE-1329, CWE-671 · ATT&CK T1210 · EMB3D TID-210 · MDS2 CSUP, SGUD · AAMI SW96; FDA premarket

CRI-SV-9 Service laptops carry infection between hospitals

† Wrong or delayed treatment

Threat. Field engineers plug their laptops and USB drives into devices at hospital after hospital, using service software with full control. Malware or a tampered tool spreads from one site to the next and onto devices the hospital’s protections never see.

Principle. Service tools and media are treated as transient assets: checked, controlled and recorded before they touch a device.

Design measures:

  1. Scan engineers’ laptops and media at a kiosk before connection, and record the asset used.
  2. Offer hospital-owned service workstations for vendors where devices allow it.
  3. Require vendors to describe how service laptops are managed, patched and protected.

Card prompts:

  • How are service laptops and USB drives checked before touching a device?
  • Who records which tools were used on which device?
  • Could malware travel on an engineer’s kit from another hospital?

Mappings: STRIDE T, E · CAPEC-457 · CWE-829 · ATT&CK T1091, T0864 · EMB3D TID-303 · MDS2 MLDP, RMOT · IEC 80001-1

CRI-SV-8 Update channel delivers malicious updates

† Direct harm

Threat. Device and software updates arrive from the vendor’s portal, a service engineer or a distribution server, and devices accept what they are given. A compromised vendor or update server pushes tampered firmware or software across the installed base.

Principle. Devices accept only updates signed by the manufacturer and verify them themselves, whatever the delivery route.

Design measures:

  1. Require signed updates verified on the device, with rollback protection.
  2. Verify update packages against published hashes before staging them in the hospital.
  3. Stage updates on a sample of devices and watch for unexpected behaviour before wider rollout.

Card prompts:

  • Does each device verify updates itself, whatever the delivery route?
  • Which servers and people can deliver updates to devices?
  • How many devices would one tampered update reach?

Mappings: STRIDE T, E · CAPEC-186, CAPEC-669 · CWE-494, CWE-347 · ATT&CK T1195.002 · EMB3D TID-211, TID-213, TID-216 · MDS2 IGAU, CSUP · FDA premarket; IEC 81001-5-1

CRI-SV-7 Bought without security evidence

Threat. Devices and clinical systems are bought on clinical and price criteria alone, without a security disclosure, SBOM, support period or vulnerability handling commitment. Once installed, the weaknesses cannot be bought back.

Principle. Security evidence and lifecycle commitments are procurement criteria with the same weight as clinical ones.

Design measures:

  1. Require an MDS2, an SBOM, a support end date and a disclosure process in every tender.
  2. Include clinical engineering and security in evaluation, with the power to fail a bid.
  3. Write security update and notification obligations into the contract.

Card prompts:

  • Is security evidence scored alongside clinical criteria at purchase?
  • Did the supplier commit to a support period and vulnerability handling?
  • Which installed systems were bought without an SBOM?

Mappings: STRIDE T, I, D · CWE-1357 · MDS2 SBOM, RDMP, SGUD · IEC 80001-1; AAMI SW96

CRI-SV-6 Refurbished and grey-market devices

† Direct harm

Threat. Refurbished, loaned and grey-market devices arrive with unknown firmware, counterfeit parts, another hospital’s configuration and sometimes its patients’ data. They can behave unpredictably and carry weaknesses or implants nobody checked for.

Principle. Every device entering service is restored to a known configuration and its origin and firmware are verified.

Design measures:

  1. Buy refurbished devices only through manufacturer-authorised channels with documented provenance.
  2. Reset devices to factory configuration and verify firmware versions and hashes before clinical use.
  3. Check incoming devices for previous owners’ data and network credentials, and remove them.

Card prompts:

  • How is a refurbished or loaned device restored to a known state?
  • Who verifies a second-hand device’s origin and firmware?
  • Could a device arrive holding another hospital’s patients or settings?

Mappings: STRIDE T, I · LINDDUN DD · CAPEC-535, CAPEC-530 · CWE-1357, CWE-226 · ATT&CK T1195.003 · EMB3D TID-113 · MDS2 IGAU, MPII

CRI-SV-5 Disposed devices leak patients and passwords

Threat. Devices returned to the vendor, sold or scrapped still hold patient data, network keys and service credentials. Anyone who buys them on the second-hand market can read the data and use the keys to get onto the hospital’s network.

Principle. Every device leaving the hospital is sanitised to a recorded standard, and credentials it held are rotated.

Design measures:

  1. Wipe or destroy storage in every departing device using a method the manufacturer confirms, and keep a certificate.
  2. Rotate Wi-Fi keys, certificates and accounts the device held when it leaves service.
  3. Require vendors taking devices back to sanitise them and confirm it in writing.

Card prompts:

  • What standard is used to sanitise devices before they leave?
  • Which credentials does a disposed device hold that need rotating?
  • Who records that sanitisation actually happened?

Mappings: STRIDE I · LINDDUN DD, I · CAPEC-675 · CWE-1266, CWE-226 · ATT&CK T1052 · EMB3D TID-108 · MDS2 MPII, STCF, DIDT · ISO 27799

CRI-SV-4 Vendor collapses or changes hands

† Wrong or delayed treatment

Threat. A manufacturer goes bust, withdraws a product or is acquired, and support, cloud services, signing keys and spare parts go with it. Hospitals and patients are left with devices nobody can update, service or safely replace.

Principle. Hospitals plan for losing a supplier and contract for what happens to support, keys and data if they do.

Design measures:

  1. Contract for escrow of documentation, service tools and update capability if the vendor exits the market.
  2. Identify single-supplier devices and plan alternatives before they are needed.
  3. Require notice of product withdrawal and a support period after it.

Card prompts:

  • What happens to support, keys and spares if the vendor fails?
  • Does the contract cover a change of ownership?
  • Which devices depend on one vendor’s continued existence?

Mappings: STRIDE D · CWE-1329 · MDS2 RDMP · AAMI SW96

CRI-SV-3 No SBOM, no answer

Threat. When a vulnerability is announced in a common component, the hospital cannot tell which of its devices contain it, and the vendor takes weeks to say. Exposure is unknown while attackers already know where to look.

Principle. Hospitals hold current component lists for their devices and can match a new vulnerability to devices in hours.

Design measures:

  1. Require machine-readable SBOMs at purchase and with every update.
  2. Load SBOMs into the asset inventory and match them automatically against new vulnerability notices.
  3. Ask vendors for exploitability statements so effort goes where it matters.

Card prompts:

  • Can you match a new component vulnerability to your devices in hours?
  • Which devices have no current component list?
  • How quickly do vendors answer exposure questions?

Mappings: STRIDE I · CWE-1395, CWE-1104 · EMB3D TID-202 · MDS2 SBOM, RDMP · FDA premarket; IEC 81001-5-1

CRI-SV-2 Advisories never reach the ward

Threat. Manufacturers’ security notices go to a sales or procurement contact, not to clinical engineering, and hospitals have no published way to report problems. Fixes and warnings sit in an inbox while vulnerable devices stay in use.

Principle. Security advisories have a named destination on both sides, and the hospital can report problems to the vendor.

Design measures:

  1. Register a monitored security contact with every device vendor and keep it current.
  2. Require vendors to run a coordinated vulnerability disclosure process and say how they notify customers.
  3. Route advisories to clinical engineering and track each to closure.

Card prompts:

  • Who at the hospital receives manufacturers’ security advisories?
  • How does the hospital report a problem to a vendor?
  • How long does an advisory take to reach clinical engineering?

Mappings: STRIDE I · CWE-1357 · MDS2 SGUD, CSUP · AAMI SW96

Seen in the wild

Mappings

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

← Facilities and Building Systems · Hospitals and medical devices overview · Identity and Access →

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