> ## 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.
# Structural hazards (TR)
- URL: https://www.ostering.com/taxonomies/hospital-and-medical-devices/cri-structural-hazards/
- Published: 2026-11-05T21:00:00.000Z
- Updated: 2026-11-05T20:38:26.354Z
- Description: The ten structural hazards of hospitals and medical devices, the Trumps in Critical Condition, each with a principle and design measures.
- Author: Brett Crawley
[Taxonomies](/taxonomies/) › [Hospitals and medical devices](/taxonomies/hospital-and-medical-devices/) › Structural hazards
**Both decks · CRI-TR · 10 structural hazards, played as Trumps**
Ten structural hazards of hospitals and medical devices as a whole. Both decks carry them, ranked 1 (highest) to 10.
**Scope:** properties of hospitals and medical devices as a whole, not of one component. Play a Trump against the whole design.
Trumps rank 1 (highest) to 10.
*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 hazards
### CRI-TR-1 Life before login
**† Wrong or delayed treatment**
**Threat.** Clinical urgency beats every control that slows care. Staff will bypass, share or switch off any security that delays treatment, so a design that only works when people comply fails on the busiest night, and a control that fails closed can harm a patient.
**Principle.** Design security so the safe and secure path is also the fastest path in an emergency.
**Design measures:**
1. Time every security step in real clinical workflows and set targets in seconds.
2. Provide accountable emergency access instead of hoping staff will not need it.
3. Decide, per function, whether failure should be open or closed, and justify it in the safety case.
**Card prompts:**
- Which security steps slow care in an emergency, and by how long?
- Is the secure path also the fastest one on the busiest night?
- Which controls fail closed where failing closed could harm a patient?
**Mappings:** STRIDE E · CAPEC-416 · CWE-655 · MDS2 EMRG · IEC 80001-1; ISO 14971
### CRI-TR-2 The device outlives its software
**† Wrong or delayed treatment**
**Threat.** Medical devices stay in service for ten to twenty years, while their operating systems and components lose support in a few. Hospitals run certified builds that cannot change, so known weaknesses stay open for most of a device's life.
**Principle.** Plan the whole service life of a device's software at design and at purchase.
**Design measures:**
1. Require a support roadmap for every third-party component and an end-of-support date in the contract.
2. Design devices so components can be updated without replacing the clinical function.
3. Budget and plan replacement or isolation before support ends, not after.
**Card prompts:**
- How long will this device stay in service, and its software supported?
- What happens to it once its operating system loses support?
- Who plans the device's software life at purchase?
**Mappings:** CWE-1104, CWE-1329 · MDS2 RDMP, SBOM, CSUP · AAMI SW96; FDA premarket; IEC 81001-5-1
### CRI-TR-3 Nobody owns the bedside
**† Wrong or delayed treatment**
**Threat.** Clinical engineering, IT, the supplier and the ward each assume another owns a connected device's security. Patching, monitoring, configuration and incident response fall between them, and attackers find the gaps first.
**Principle.** Every connected device has a named owner for its security, across its whole life.
**Design measures:**
1. Assign responsibilities for each device class in a written agreement between clinical engineering, IT and the supplier.
2. Keep one inventory of connected devices, shared by all owners, with a named contact per device.
3. Include connected devices in incident response playbooks with clear decision rights.
**Card prompts:**
- Who owns the security of each connected device in this design?
- Where do clinical engineering, IT, vendor and ward responsibilities meet?
- Who responds first when a bedside device is compromised?
**Mappings:** CWE-671 · MDS2 SGUD · IEC 80001-1
### CRI-TR-4 Safety cases assume accidents
**† Wrong or delayed treatment**
**Threat.** Risk files and safety cases model random failures and honest mistakes. An adversary chooses the worst moment, defeats several safeguards together and hides the evidence, so controls judged independent fail at once and residual risk is far higher than the file says.
**Principle.** Treat intentional misuse as a cause of hazards in the safety risk file, not a separate concern.
**Design measures:**
1. Link security threats to hazards in the ISO 14971 risk file and score them together.
2. Check that safeguards relied on as independent cannot be defeated by one compromise.
3. Reassess the safety case whenever a new vulnerability or attack technique affects the device.
**Card prompts:**
- Does the safety risk file treat an adversary as a cause of hazards?
- Which safeguards could one attacker defeat together?
- How would the residual risk change if failures were deliberate?
**Mappings:** CWE-1357 · ATT&CK T0880, T0837 · MDS2 IGAU · ISO 14971; AAMI SW96; IEC TR 60601-4-5
### CRI-TR-5 Alarm fatigue hides the attack
**† Wrong or delayed treatment**
**Threat.** Wards hear hundreds of alarms a shift, most of them false, so staff silence, widen or ignore them. Manipulated readings, suppressed alarms or a device behaving oddly blend into the noise and are noticed late, if at all.
**Principle.** Alarms are few, meaningful and protected from change, so an abnormal one gets attention.
**Design measures:**
1. Reduce non-actionable alarms through tuning and clinical review before adding new ones.
2. Protect alarm limits and routing from unauthorised change and log every change.
3. Report alarm silencing and limit changes per device so unusual patterns are seen.
**Card prompts:**
- How many alarms does each ward hear in a shift?
- Would a manipulated alarm stand out from the noise?
- Who can change alarm settings, and is that protected?
**Mappings:** STRIDE T, R · CWE-778 · ATT&CK T0832 · MDS2 AUDT, IGAU · IEC 80001-1
### CRI-TR-6 One supplier, many hospitals
**† Wrong or delayed treatment**
**Threat.** A handful of suppliers provide the record systems, laboratories, imaging platforms, remote service tools and clouds for most hospitals in a region or country. One compromise or one failure at a supplier becomes an incident at every customer together.
**Principle.** Know where many hospitals share one supplier and keep a way to work without it.
**Design measures:**
1. Map shared suppliers across the region and treat concentration as a risk to manage.
2. Require suppliers to separate customers so one breach does not reach all of them.
3. Plan mutual aid and fallbacks that do not use the same supplier.
**Card prompts:**
- Which suppliers in this design also serve most nearby hospitals?
- What would one supplier's compromise do to every customer at once?
- How would you keep working without that supplier?
**Mappings:** STRIDE D · CWE-1357 · ATT&CK T1199, T1195.002 · MDS2 RMOT · IEC 80001-1
### CRI-TR-7 Patch means revalidate
**† Wrong or delayed treatment**
**Threat.** Changing a certified device's software means verification by the maker and sometimes the regulator, and hospitals are told not to patch themselves. Fixes arrive months or years after the weakness is public, and the hospital must defend a device it is not allowed to change.
**Principle.** Design and contract for timely, validated updates as part of the device, not an exception.
**Design measures:**
1. Design devices so security updates can be verified quickly without re-certifying clinical function.
2. Agree update timelines and compensating controls in the purchase contract.
3. Isolate and monitor devices awaiting validated updates, with the supplier's guidance.
**Card prompts:**
- How long does a validated fix take to reach this device?
- What may the hospital do while a fix is awaited?
- Does the contract commit the maker to timely validated updates?
**Mappings:** CWE-1329 · EMB3D TID-213 · MDS2 CSUP, RDMP · FDA premarket; AAMI SW96; IEC 81001-5-1
### CRI-TR-8 Every patient is a target
**Threat.** Health records are permanent, deeply personal and valuable for fraud, extortion, discrimination and intelligence. Every patient is a data subject whose information can be sold, published or used against them, long after the care has ended.
**Principle.** Collect, keep and expose only what care needs, and protect the most sensitive data most strongly.
**Design measures:**
1. Classify record categories by sensitivity and apply stronger controls to the most sensitive.
2. Minimise copies of patient data in secondary systems, exports and test environments.
3. Give patients a way to see who has accessed their record.
**Card prompts:**
- What patient data does this design collect that care doesn't need?
- Which data would do most harm if sold or published?
- How long is patient data kept after care ends?
**Mappings:** STRIDE I · LINDDUN L, I, DD, U, Nc · CWE-359 · MDS2 MPII, STCF, DIDT · ISO 27799
### CRI-TR-9 The hospital never closes
**† Wrong or delayed treatment**
**Threat.** Hospitals run every hour of every day with no maintenance window. Patching, testing and recovery all compete with care, and the only way to switch a hospital off safely is to divert patients elsewhere.
**Principle.** Build maintenance and recovery into the design so they do not require stopping care.
**Design measures:**
1. Design redundant clinical systems so one side can be updated while the other runs.
2. Plan maintenance with clinical leads around activity, not around IT convenience.
3. Treat the ability to recover without closing as a design requirement.
**Card prompts:**
- When can this system be patched, tested or restored without stopping care?
- What does the design assume about maintenance windows?
- Is diversion the only way to take this service offline safely?
**Mappings:** STRIDE D · ATT&CK T0826 · MDS2 DTBK, CSUP · IEC 80001-1
### CRI-TR-10 Hospitals are strategic targets
**† Wrong or delayed treatment**
**Threat.** Hospitals are critical infrastructure. Criminals target them because they pay, and states may pre-position in them or disrupt them in a crisis or conflict to cause fear and overwhelm emergency response. Plans built for accidents and petty crime do not survive a determined adversary.
**Principle.** Plan for a patient, capable adversary who wants disruption, not only for criminals who want money.
**Design measures:**
1. Include state-level scenarios, such as simultaneous attacks on several hospitals, in continuity planning.
2. Share threat intelligence with sector bodies and national authorities and act on it.
3. Hunt for long-term access in clinical and device networks, not only for ransomware.
**Card prompts:**
- Does the design assume a patient, capable adversary or just criminals?
- What would a state actor gain by disrupting this system in a crisis?
- Which plans would fail against a deliberate, coordinated attack?
**Mappings:** STRIDE D, E · ATT&CK T1078, T1133 · IEC 62443; IEC 80001-1
## Seen in the wild
- **Argus II retinal implant, 2020** ([CRI-TR-2](/taxonomies/hospital-and-medical-devices/cri-structural-hazards/#cri-tr-2)). 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).
- **Synnovis pathology attack, London, 2024** ([CRI-TR-6](/taxonomies/hospital-and-medical-devices/cri-structural-hazards/#cri-tr-6)). Ransomware at Synnovis, pathology provider to King's College Hospital and Guy's and St Thomas', led to thousands of postponed operations and appointments and an appeal for O-type blood donors. In June 2025 King's confirmed a patient had died unexpectedly during the attack, with a long wait for a blood test result among the contributing factors; the local care board reported 170 patients harmed, mostly low harm. Sources: [The Register: Qilin ransomware attack on NHS supplier contributed to patient fatality](https://www.theregister.com/2025/06/26/qilin_ransomware_nhs_death/); [Digital Health: Patient death linked to cyber attack on NHS pathology provider](https://www.digitalhealth.net/2025/06/patient-dies-as-a-result-of-cyber-attack-on-nhs-pathology-provider/).
- **Change Healthcare, 2024** ([CRI-TR-6](/taxonomies/hospital-and-medical-devices/cri-structural-hazards/#cri-tr-6)). Ransomware at Change Healthcare, which handles about one in three US health transactions, left many providers and pharmacies unable to process claims and prescriptions for weeks; the data of about 192.7 million people was taken. Sources: [Becker's: Change Healthcare data breach toll reaches 192.7 million](https://www.beckershospitalreview.com/healthcare-information-technology/cybersecurity/change-healthcare-data-breach-toll-reaches-192-7-million); [Fierce Healthcare: UnitedHealth estimates 190M people impacted](https://www.fiercehealthcare.com/payers/unitedhealth-estimates-190m-people-impacted-change-healthcare-cyberattack).
- **Vastaamo psychotherapy records, Finland, 2020** ([CRI-TR-8](/taxonomies/hospital-and-medical-devices/cri-structural-hazards/#cri-tr-8)). Therapy records of about 36,000 patients of the Vastaamo psychotherapy centre were stolen in 2018 and 2019; in October 2020, after the company refused to pay, patients were extorted individually. A Finnish court convicted the attacker in April 2024 and the appeal court upheld the conviction in 2025. Sources: [Wikipedia: Vastaamo data breach](https://en.wikipedia.org/wiki/Vastaamo_data_breach); [AP via NY1: Finnish hacker gets prison for accessing psychotherapy records](https://ny1.com/nyc/all-boroughs/ap-top-news/2024/04/30/finnish-hacker-gets-prison-for-accessing-thousands-of-psychotherapy-records-and-demanding-ransoms).
## Mappings
Across the 10 entries, the STRIDE counts are Denial of service 3, Elevation of privilege 2, Tampering 1, Repudiation 1, Information disclosure 1 (an entry can carry more than one). 1 maps to CAPEC 3.9, 8 to CWE 5.0, 5 to ATT&CK v20.0, 1 to MITRE EMB3D and 1 to LINDDUN. The MDS2 capabilities a buyer should check first are CSUP (3), RDMP (2), IGAU (2). 9 carry the amber † for wrong or delayed treatment. A blank means nothing fitted well; a loose tag would mislead.
---
← [Continuity and Downtime](/taxonomies/hospital-and-medical-devices/cri-continuity-and-downtime/) · [Hospitals and medical devices overview](/taxonomies/hospital-and-medical-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/).*