A Threat Modeling Card Game for Hospitals and Medical Devices

TL;DR

• Critical Condition is a trick-taking threat modeling card game for the people who design, buy, connect and run hospitals and the medical devices in them.
• Two decks: The Patient (116 cards) for the devices in, on and around the patient, and The Hospital (129 cards) for the systems, communications, building and suppliers that care depends on. Ten Trumps, the structural hazards, sit in both.
• Every card is an entry in the Hospital and Medical Device Threat Taxonomy: 221 threats and 10 structural hazards, each with a mitigation principle, design measures and mappings.
• A red † marks direct physical harm to a patient and an amber † marks wrong or delayed treatment. 156 of the 231 entries carry one.
• An optional player, the Patient Advocate, speaks for the one person who is never in the design review.

In Black Start I looked at the services that keep a country fed, watered and powered. Hospitals were in the background of almost every card: they’re where a power cut, a water outage or an attack on a supplier ends up. So I’ve given them a game of their own.

Critical Condition is a threat modeling card game for hospitals and medical devices. It follows the same pattern as my other games: you draw the system, you play cards against the drawing, and every card is a question the table has to answer about its own design. In this post I’ll explain why hospitals need their own deck, how the game plays, and what’s in the box.

Why hospitals?

At first glance a hospital looks like any other large organisation with a lot of IT. It isn’t, for three reasons.

• The consequence is a patient. A security failure that costs another business money can cost a patient their treatment, or their life. Most of the cards in this game carry a dagger for exactly that reason.
• Care can’t stop. A hospital has no maintenance window. Patching, testing and recovery all compete with care, and the only real off switch is diverting ambulances to someone else.
• The devices outlive their software. An infusion pump, a scanner or an implant stays in service for years after its operating system and components lose support, and changing it means revalidating it.

The public record shows what that looks like. In 2017 WannaCry disrupted at least 81 of England’s 236 NHS trusts and infected 595 GP practices, and over 19,000 appointments were cancelled (NAO). In 2021 Conti ransomware encrypted about 80% of the IT environment of Ireland’s Health Service Executive, which shut its national IT down and took around four months to recover fully (HSE). In 2024 ransomware at Synnovis, the pathology provider to two London hospital trusts, led to thousands of postponed operations and appointments and an appeal for O-type blood donors; in June 2025 King’s College Hospital confirmed that a patient had died unexpectedly during the attack, with a long wait for a blood test result among the contributing factors (Digital Health).

The devices have their own story. In 2019 the FDA warned that certain older Medtronic MiniMed insulin pumps could be reached over their radio link by someone nearby and their settings changed. The pumps couldn’t be updated, so they were recalled and replaced (Infosecurity).

None of those incidents started at the bedside. They started in the network, a shared service, a supplier or a radio protocol, and ended with a patient. A threat model that stops at the device misses most of that. One that stops at the network misses the patient. Critical Condition puts both on the same table.

Two decks

The Patient (116 cards) covers what touches the patient: Implants and Programmers, Body-worn and Home-use Devices, Patient Monitoring, Life Support and Therapy, Medication Delivery, Imaging and Radiation, Laboratory and Diagnostics and Clinical Software and AI.

The Hospital (129 cards) covers what runs care: Records and Patient Data, Integration and Interoperability, Networks and Wireless, Clinical Communications, Emergency and External Communications, Facilities and Building Systems, Suppliers, Service and Lifecycle, Identity and Access and Continuity and Downtime.

Communications get two suits of their own, because care stops when a call doesn’t get through. Clinical Communications is the nurse call, the alarm routed to a handset, the bleep and the crash call. Emergency and External Communications is the ambulance link, the pre-alert, the radio, the diversion board, telehealth and the text message to a patient.

Both decks carry the same ten Trumps: structural hazards of hospitals and medical devices as a whole, such as Life before login, The device outlives its software, Nobody owns the bedside and The hospital never closes. A Trump beats any suit card, and when you play one you say how it shows up across the whole design, not just in one device.

Each deck plays on its own. Device makers and clinical engineering will mostly reach for The Patient; hospital IT, estates and suppliers for The Hospital. The Whole Hospital variant plays both over several sessions, and the 30-minute Bedside variant uses one suit and the Trumps.

How a session runs

1. Draw the system on the A3 Hospital Map: the patient at the centre, the ward and bedside, the clinical departments, the clinical systems and integration, the networks, communications, the building, the suppliers and vendor clouds, and the outside world (the ambulance service, other hospitals, the patient at home).
2. Choose two or three suits plus the ten Trumps, deal the cards and name a Scribe.
3. Play tricks. Follow suit if you can. The highest card of the suit led wins the trick unless a Trump is played, in which case the highest Trump wins. Ranks run from Ace high to 2, and Trumps from 1 high to 10.
4. Make it real. When you play a card, read it aloud, say how the threat could happen in the system on the drawing and point at it. Then the table answers the card’s three prompts. A card that can’t apply is still played, and the Scribe logs the reason, because “we checked and it doesn’t apply” is a finding too.
5. Score. One point for a threat that applies, one for each trick you win, and one for a Patient Advocate challenge the table accepts.
6. Keep the findings log. Card ID, element on the drawing, what could happen, the dagger, the decision (fix, accept, find out, or not applicable with the reason), the owner and the ticket.

Two daggers

A red † means the threat can physically harm a patient: a wrong dose delivered, therapy changed, life support stopped. It isn’t accepted without the person who owns clinical safety for the system in the room. An amber † means wrong or delayed treatment: a missed alarm, a wrong result, an ambulance sent to the wrong place. It needs a clinical lead’s sign-off before anyone accepts it. Across the taxonomy, 55 entries carry a red dagger and 101 an amber one.

The Patient Advocate

The Patient Advocate is an optional role, and my favourite part of the game. They play their hand as normal, and they also speak for the patient and their family, who are never in the design review. Once per trick they can challenge a player who says a threat doesn’t apply, with one question:

“What happens to the patient when this fails?”

If the table agrees the threat applies after all, the Scribe logs it and the Patient Advocate scores the point. The role ties into Trumps CRI-TR-1 Life before login and CRI-TR-8 Every patient is a target.

One card in full

CRI-PM-K · Alarms silenced from afar (Patient Monitoring, King, amber †)

Alarm limits, volume and pause states can be changed from a central station, a remote viewer or the network without authorisation, and alarm forwarding can be turned off. Deterioration alarms never reach a nurse.

The three prompts the table answers:

1. Who can change alarm limits, and from where?
2. Does the bedside show a remote change, and who made it?
3. Can anyone turn alarm forwarding off without a clinician knowing?

In the taxonomy the same entry adds the mitigation principle (Changes to alarm behaviour are authorised, local where possible, visible and logged), 4 design measures, and its mappings: STRIDE T, E, R; CAPEC-176; CWE-862 and CWE-306; ATT&CK for ICS T0838 and T0878; EMB3D TID-310; MDS2 AUTH and AUDT; and the standards IEC TR 60601-4-5 and ISO 14971.

What’s in the box

• Two decks in their own tuck boxes: The Patient (116 cards) and The Hospital (129 cards), each with a quick-reference card and a taxonomy card.
• A rule book (A5, 16 pages) with the variants, the 17 suits and the 10 Trumps.
• A worked example (A5, 20 pages): Ward 12 at the fictional Wrenmoor District General Hospital, with wireless cardiac telemetry, alarms routed to nurses’ handsets, smart infusion pumps programmed from the patient record and remote follow-up of patients with implanted defibrillators. It plays four tricks with real cards, answers every prompt, uses the Patient Advocate’s challenge once and ends with 12 findings looked up in the taxonomy.
• A practice booklet (A5, 8 pages): the emergency department at the fictional Kestrel Bay General Hospital and its ambulance links, with a drawing, a briefing, suggested suits and three hints, and no answers.
• The A3 Hospital Map, a score pad and a findings log pad.

The game came first

As with my other games, the game came first and the taxonomy is its reference. Every card’s ID, such as CRI-PM-K, is its entry in the Hospital and Medical Device Threat Taxonomy, and the taxonomy card in each deck carries a QR code to it. The ID is written with hyphens so that it’s one searchable token: put it in your findings and tickets, and anyone can come back to the full entry. I write about the taxonomy itself in The Hospital Never Closes, and about how it maps to the frameworks you already use in the mapping post.

Notes

Note to device makers: play The Patient deck against the architecture you’re about to submit. Regulators already expect a threat model; the findings log gives you one with stable IDs, and the MDS2 mapping on every entry tells you which answer a hospital will check when it buys your device.

Note to clinical engineering: bring the vendor. Most of the threats in The Patient deck sit between the device, the network and the service contract, and Nobody owns the bedside is a Trump for a reason.

Note to hospital IT and security teams: play The Hospital deck against the integration engine, the alarm routing and the downtime plan, not just the network diagram. Many of the cards ask what still works when the network is down.

Note to estates and facilities: the Facilities and Building Systems suit is yours: medical gases, theatre ventilation, backup power, cold storage and the pneumatic tubes. Ask to be in the room.

Credits

The trick-taking format comes from Elevation of Privilege by Adam Shostack, released by Microsoft under the Creative Commons Attribution 3.0 licence. Critical Condition reuses none of its card text or artwork.

Critical Condition is part of my family of threat modeling games, alongside Elevation of Email Flow, Software Factory, Elevation of Care, Open House, Black Start and the Elevation of Autonomy deck. If you want the background to all of them, it’s in my book, Threat Modeling Gameplay with EoP (Packt, 2024).

Coming soon. If you’d like the decks when they’re published, send me a message on LinkedIn. Knowing there’s demand helps a publisher decide which games to prioritise.

Final thoughts

Critical Condition won’t replace a safety case, a risk file or a penetration test. What it will do is get the device maker, the clinical engineer, the ward manager, the integration team and the person who runs the estate around one drawing, arguing about the same threats and writing down what they find. In my experience, that’s the part that rarely happens.

I’d love to hear how it plays at your table: the cards that started arguments, the challenges the Patient Advocate won, and the threats you think are missing.

Stay tuned!

Related

• Hospital and Medical Device Threat Taxonomy: every card’s threat, principle, design measures and mappings
• The Hospital Never Closes: A Threat Taxonomy for Hospitals and Medical Devices
• Mapping the Hospital and Medical Device Threat Taxonomy to STRIDE, LINDDUN, CAPEC, CWE, ATT&CK, EMB3D and MDS2

References

• WannaCry and the NHS, 2017. NAO: Investigation, WannaCry cyber attack and the NHS; GOV.UK: Foreign Office Minister condemns North Korean actor for WannaCry attacks
• Conti attack on Ireland’s HSE, 2021. HSE: Conti cyber attack on the HSE, full report (PwC); HHS HC3: Lessons learned from the HSE cyber attack
• Synnovis pathology attack, London, 2024. The Register: Qilin ransomware attack on NHS supplier contributed to patient fatality; Digital Health: Patient death linked to cyber attack on NHS pathology provider
• Medtronic MiniMed insulin pumps, 2019. Infosecurity: Insulin pumps recalled by FDA for cybersecurity risks; Becker’s: Medtronic recalls insulin pumps that can be wirelessly hacked