← Chaunda C. Dallas · Healthcare Cybersecurity Strategist
Healthcare Cyber Risk Research Environment — v4.0

Digital
First
Responder
Lab

Where connected medical systems and clinical AI actually fail — not in theory, but in the moment when the decision still has to be made. Built from 28 years of clinical reality and lived device dependency.

Explore real healthcare failure scenarios, make the call in Decision Mode, and see where security frameworks stop short of patient safety.

9
Live Scenarios
9/9
Evidence-Labeled: Documented or Modeled
28+
Years Clinical Experience
3
Clinical AI Red-Team Scenarios
Scroll to explore
How the Lab Works
Underneath all three:Digital First Responder Framework·Triage → Stabilize → Treat → Recover
Core Philosophy

At 2am in the ER, I'm not waiting on a dashboard. Healthcare doesn't pause for data validation. Our security frameworks need to stop assuming it does.

Most healthcare cybersecurity focuses on protecting data. This lab focuses on what happens when the technology keeping a person alive fails — in real time, under real conditions, with real consequences that no framework fully accounts for.

I never left healthcare. I learned to defend it. I teach it, I live it, I build it, and I'm learning how attackers see it — so I can protect patients better than anyone who only knows one side.

01 — Explore · Failure Scenarios

Every scenario carries an evidence label, a failure chain, a patient-side reading on the five PSTM lenses, a control and framework analysis, and its sources. Tap a scenario to open it.

Evidence labelsDocumented IncidentDocumented VulnerabilityThreat ModelAuthor-Developed Scenario
9 scenarios
01 / SCENARIO
Author-Developed Scenario
Silent Battery Failure
Portable O₂ Concentrator
Critical

Battery indicator reports full charge. Device loses power within minutes. No backup source. Power infrastructure unstable.

IoMT & DevicesHome Care

Evidence basisBuilt from the author’s own device dependency. The failure chain is lived experience, not a published incident.

Failure Chain

1
False state reporting. Battery shows full. Actual runtime: 2–3 minutes.
2
No verification protocol. Patient trusts the indicator. No alert threshold configured.
3
Power outage occurs. Grid failure. AC disconnected.
4
No backup exists. No second device. No escalation path.
5
Oxygen deprivation begins silently. PAH + hypoxia. Cascading failure.

Patient-Side Impact PSTM →

Oxygen delivery stops → Indicator still reads full → Hypoxemia on top of pulmonary hypertension → Right-heart strain → Emergency intervention
Physiological dependency
Life-sustaining
Latency to harm
Minutes
Bedside detectability
Low — indicator shows full
Workaround pressure
None available at home
Downtime survivability
Untested — no backup source

Control / Framework Analysis

Existing control
Manufacturer battery indicators. HHS emPOWER and utility medical-need registries for people who depend on electricity-powered equipment.
Observed limitation
Indicator accuracy isn’t independently verified by the patient. Registries depend on enrollment and don’t replace a backup source.
Unaddressed dependency
Home power plus a single device is a single point of failure for a life-sustaining therapy.
Proposed control
Real-time battery health telemetry with verified discharge testing. Mandatory backup protocols for single-source oxygen-dependent patients. Infrastructure dependency mapping for high-risk home medical devices. Emergency registry enrollment at local utility and fire department level.
Frameworks referencedNIST 800-53 SI-13NIST AI RMF MANAGE 2.2HIPAA §164.310(a)(2)(i)FDA 21 CFR Part 820IEC 62443-4-2 CR 3.1Home Care Redundancy Gap
Evidence & References
02 / SCENARIO
Threat Model
AI Triage Override
Emergency Department
Critical

AI triage scores patient low acuity. Clinician overrides based on observation. System flags the override as anomalous.

Clinical AI

Evidence basisModeled on how triage AI and override logging interact. No specific product or incident is described.

Failure Chain

1
Model scores low risk. Misses nonverbal cues: skin color, work of breathing, diaphoresis.
2
Clinician escalates immediately. Patient is actually critical.
3
System flags override as deviation. Algorithm treats expert judgment as error.
4
Override used for retraining. Model learns wrong lesson.

Patient-Side Impact PSTM →

Low-acuity score → Delayed evaluation in a crowded waiting room → Deterioration before being seen → Override logged as error → Model learns to under-triage the next patient
Physiological dependency
Varies — high for a critical patient
Latency to harm
Minutes to hours
Bedside detectability
Moderate — the clinician sees it, the system doesn’t
Workaround pressure
High — overrides are flagged
Downtime survivability
Survivable — manual triage if staff are trained

Control / Framework Analysis

Existing control
FDA Clinical Decision Support Software guidance. NIST AI RMF govern and map functions. ONC HTI-1 decision-support transparency requirements.
Observed limitation
These address transparency and governance at the system level. None of them specifies how clinician overrides are logged or whether they feed retraining.
Unaddressed dependency
Nonverbal clinical observation has no input field, so the model never sees what the nurse sees.
Proposed control
Override logging that distinguishes expert judgment from error. Model retraining governance requiring human review. Mandatory human-in-the-loop thresholds for high-acuity clinical AI. Regular red-team exercises against experienced clinician baseline.
Frameworks referencedNIST AI RMF GOVERN 1.1NIST AI RMF MAP 3.5FDA AI/ML Action PlanONC HTI-1 RuleHuman Oversight Gap
Evidence & References
03 / SCENARIO
Documented Vulnerability
Infusion Pump
Network Compromise
High

Networked pump receives unauthorized parameter update during active medication delivery. Nurse managing four other patients simultaneously.

IoMT & DevicesData IntegrityIncident Response

Evidence basisNetworked infusion pump vulnerabilities are documented by FDA (Hospira Symbiq, 2015) and CISA advisories. This attack chain is a composite, not a single reported event.

Failure Chain

1
Pump on clinical network. Update mechanism lacks authentication. Lateral movement from prior breach.
2
Unauthorized parameter pushed. Change within acceptable range. No alarm fires.
3
Nurse managing four patients. Visual check interval 20+ minutes.
4
Wrong dose delivered over time. Subtle deterioration.

Patient-Side Impact PSTM →

Dose altered within safe limits → No alarm → Wrong dose over time → Toxicity or under-treatment found late
Physiological dependency
Life-sustaining during active delivery
Latency to harm
Minutes to hours
Bedside detectability
Low — change stays within limits
Workaround pressure
High — one nurse, five patients
Downtime survivability
Testable — manual programming or a swap pump

Control / Framework Analysis

Existing control
FD&C Act §524B and FDA premarket cybersecurity expectations for new devices. CISA ICS medical advisories. IEC 80001-1 risk management for networked medical IT.
Observed limitation
Many installed pumps predate current premarket requirements. Advisories only help if patching and segmentation actually happen.
Unaddressed dependency
SOC playbooks built for IT assets don’t route an alert to the nurse at the bedside.
Proposed control
Mutual TLS authentication for all pump updates. Real-time anomaly detection on rate changes. Clinical workflow-aware alerting. Mandatory FDA MedWatch reporting integration.
Frameworks referencedNIST 800-82 Rev 3FDA Cyber Guidance 2023HIPAA §164.312(b)IEC 80001-1Network Segmentation Gap
Evidence & References
04 / SCENARIO
Documented Incident
OSINT Recon on
Hospital Infrastructure
High

Before attackers touch a network, they watch it. What they find in 30 minutes would surprise most security teams.

IdentityIncident Response

Evidence basisHHS HC3 reported help-desk social-engineering attacks against health organizations in 2024. The hospital and caller here are composites.

Failure Chain

1
Public footprint mapped. Job postings name the EHR build, the VPN vendor and the imaging system. Staff rosters sit on LinkedIn. Vendor case studies name the hospital.
2
Exposed services indexed. Internet-wide search engines list a remote-access portal and a building-system interface still reachable from outside. Nobody owns the list.
3
The help desk becomes the target. Names, roles and shift patterns make a convincing call: a night-shift clinician, locked out, shift starts in an hour.
4
Access looks legitimate. Password reset, MFA re-enrolled to the attacker’s phone. No malware yet, so nothing alerts.
5
The clinical dependency map is done. The attacker knows which systems the ED can’t run without, and which night the staffing is thinnest.

Patient-Side Impact PSTM →

No patient harm yet → Attacker holds a valid login → Ransomware or data theft follows → Clinical downtime (see Scenario 06)
Physiological dependency
Indirect — every downstream system
Latency to harm
Days to weeks
Bedside detectability
Low — the login is legitimate
Workaround pressure
High — help desks are measured on speed
Downtime survivability
Depends on the downtime plan

Control / Framework Analysis

Existing control
HHS HPH Cybersecurity Performance Goals. HHS 405(d) HICP. HIPAA risk analysis. The HC3 2024 help-desk sector alert.
Observed limitation
Guidance recommends caller verification, but help desks are measured on speed. What outsiders can see is rarely inventoried.
Unaddressed dependency
Nobody owns the “what can an outsider already see” inventory.
Proposed control
Continuous external attack-surface monitoring with a named owner, including CISA’s free vulnerability scanning for health organizations. Identity verification for every password and MFA reset: a callback to the number on file or a manager confirmation, never the caller’s word. Job postings that describe skills without publishing the tech stack. A risk analysis that starts from what an outsider can already see.
Frameworks referencedMITRE ATT&CK TA0043 ReconnaissanceNIST CSF 2.0 ID.AMHHS HPH Cybersecurity Performance GoalsHHS 405(d) HICPHIPAA §164.308(a)(1) Risk AnalysisExternal Attack Surface Blind SpotHelp-Desk Identity Verification Gap
Evidence & References
05 / SCENARIO
Threat Model
Wearable Data Spoofing
Athlete & Patient Dual Perspective
High

Your Apple Watch says you're fine. The clinical system believes it. The coach clears you to play. You are not fine. Two perspectives — same failure, different stakes.

Data IntegritySports Tech

Evidence basisNo public attack on a specific wearable is described. Modeled on how consumer wearable data enters clinical and clearance decisions.

🏈 Sports Tech Bridge Scenario

This is the scenario that bridges healthcare and sports technology. Same device. Same biometric data. Two entirely different contexts — both with life-threatening stakes. The gap between consumer wearable and clinical medical device is where attackers operate, and where the frameworks reviewed here draw no clear line.

Failure Chain — Perspective 1: The Clinician

1
Patient enrolled in remote monitoring program. Apple Watch syncs health data to EHR via HealthKit. Clinician reviews wearable data between appointments.
2
Data transmission intercepted. Spoofed biometric values injected — falsely normal heart rate, falsely normal SpO2.
3
Clinical decision made on false baseline. Medication adjusted downward. Follow-up deferred. Warning signs masked.
4
Patient deteriorates without clinical awareness. No alert fires. Emergency presentation follows.

Failure Chain — Perspective 2: The Athlete

1
Elite athlete uses wearable for performance monitoring. Data feeds team health management system. Clearance decisions based on biometric thresholds.
2
Wearable data spoofed to show false fitness. Recovery metrics falsified. System clears athlete for full competition.
3
Athlete competes while physiologically compromised. Underlying cardiac stress undetected. No human override occurs.
4
Cardiac event during competition. Spoofed data masked the warning signs that should have kept this athlete off the field.

Failure Chain — Perspective 1: The Clinician

1
Patient enrolled in remote monitoring program. Apple Watch syncs health data to EHR via HealthKit. Clinician reviews wearable data between appointments.
2
Data transmission intercepted. Spoofed biometric values injected — falsely normal heart rate, falsely normal SpO2.
3
Clinical decision made on false baseline. Medication adjusted downward. Follow-up deferred. Warning signs masked.
4
Patient deteriorates without clinical awareness. No alert fires. Emergency presentation follows.

Failure Chain — Perspective 2: The Athlete

1
Elite athlete uses wearable for performance monitoring. Data feeds team health management system. Clearance decisions based on biometric thresholds.
2
Wearable data spoofed to show false fitness. Recovery metrics falsified. System clears athlete for full competition.
3
Athlete competes while physiologically compromised. Underlying cardiac stress undetected. No human override occurs.
4
Cardiac event during competition. Spoofed data masked the warning signs that should have kept this athlete off the field.

Patient-Side Impact PSTM →

Falsely normal vitals → Treatment reduced or clearance granted → Deterioration or a cardiac event under exertion
Physiological dependency
Monitoring — drives treatment and clearance
Latency to harm
Hours to weeks
Bedside detectability
Low — data looks normal
Workaround pressure
High — coach and schedule pressure
Downtime survivability
Survivable — in-person assessment

Control / Framework Analysis

Existing control
FDA General Wellness policy keeps most consumer wellness wearables outside device regulation. HIPAA applies once data enters a covered entity’s record.
Observed limitation
In the frameworks reviewed here, the integrity of consumer wearable data isn’t verified before it’s used for clinical or clearance decisions.
Unaddressed dependency
Sports clearance workflows can sit outside both HIPAA and FDA scope.
Proposed control
Data integrity verification at every point in the wearable-to-EHR pipeline — not just transmission encryption, but authenticity verification of the data itself. Clear regulatory boundaries on when consumer wearable data can be used for clinical decision-making. Anomaly detection that compares wearable data against in-person vitals. Sports medicine protocols that require human clinical confirmation before automated clearance decisions. The gap between consumer wellness device and clinical medical device is where this failure lives.
Frameworks referencedFDA Digital Health Policy (Consumer Wearables)NIST AI RMF MAP 3.5HIPAA §164.312 (Transmission Security)No Wearable Data Integrity StandardHealthKit API Security GapSports Medicine Technology GapConsumer Device to Clinical Use Boundary Gap
Evidence & References
06 / SCENARIO
Documented Incident
Ransomware in the ER
The 2am Decision
Critical

The EHR is locked. The patient is crashing. 90 seconds. No medication history. This is not a drill.

Incident Response

Evidence basisEHR downtime, paper charting and diversion are documented in real attacks, including Ascension (2024) and Luminis Health (2026). The patient case is a composite.

Failure Chain

1
The EHR goes dark at 02:00. Encryption hits at the lowest staffing of the day. Downtime gets declared late because at first it just looks like “the system is slow.”
2
The downtime kit is incomplete. The read-only downtime reports are hours old, or sit on a server that was encrypted too. Nobody can find the key to the paper forms.
3
A crashing patient with no history. Unknown anticoagulant, unknown allergies. Dispensing cabinets on override. Lab and imaging results stop flowing back.
4
Paper chaos. Verbal orders, lost times, duplicate-dose risk. Most staff hired in the last decade have never run a real paper downtime.
5
Diversion cascades. The ED diverts, neighboring hospitals saturate, ambulances drive farther. Recovery takes weeks, and reconciliation errors surface long after.

Patient-Side Impact PSTM →

EHR dark → No medication or allergy history → Treatment on incomplete information; diversion delays → Medication errors and delayed care
Physiological dependency
High — ED operations run on the EHR
Latency to harm
Minutes
Bedside detectability
High for the outage, low for the data errors it causes
Workaround pressure
Extreme — paper everything
Downtime survivability
The core question — often untested on nights

Control / Framework Analysis

Existing control
HIPAA contingency-plan requirement (§164.308(a)(7)). CMS Emergency Preparedness Rule (42 CFR 482.15). HHS 405(d) HICP.
Observed limitation
Plans have to exist and be tested, but testing is often an IT tabletop, not a night-shift clinical drill.
Unaddressed dependency
Regional diversion capacity when neighboring hospitals saturate.
Proposed control
Downtime drills run with clinicians, at night, on the floor, not just an IT tabletop. A downtime workstation and printer on an isolated network, with medication and allergy reports refreshed on a schedule. Paper order sets and MARs stocked on every unit and checked like a crash cart. A regional plan for diversion so one hospital’s outage doesn’t become three. This is what the 3 A.M. Downtime Drill is built to test.
Frameworks referencedHIPAA §164.308(a)(7) Contingency PlanCMS Emergency Preparedness Rule (42 CFR 482.15)NIST CSF 2.0 RC.RPHHS 405(d) HICPHHS HPH Cybersecurity Performance GoalsClinical Downtime Survivability GapRegional Diversion Coordination Gap
Evidence & References
07 / SCENARIO
Threat Model
CPAP Firmware Integrity
ResMed AirSense 11
Critical

Connected to the internet. Can receive software updates remotely. The patient depending on it is also the analyst who built this lab.

IoMT & DevicesHome Care

Evidence basisNo public CVE for the AirSense 11 was found as of September 2026. This models the remote-update path as an attack surface.

Failure Chain

1
Device connected to the myAir cloud platform. Cellular modem built in. Remote monitoring active. Remote update path open.
2
The update path becomes the attack surface. Modeled assumption: an attacker abuses the remote-update or configuration path. The change is applied without patient notice or consent.
3
Malicious firmware pushed during sleep window. Patient asleep. Device behavior altered silently — pressure settings, therapy modes, alarm thresholds.
4
Therapy degraded without clinical detection. myAir data still transmits normally. Clinician sees clean data.
5
PAH patient with compromised nightly therapy. Degraded CPAP therapy directly impacts cardiovascular strain and oxygen saturation.

Patient-Side Impact PSTM →

Therapy settings altered overnight → Degraded support while asleep → Nocturnal desaturation and cardiovascular strain → Clean data hides it
Physiological dependency
Life-supporting — nightly therapy with PAH
Latency to harm
Hours, cumulative over nights
Bedside detectability
Low — patient asleep, data looks clean
Workaround pressure
Low to moderate
Downtime survivability
Survivable — therapy can run with connectivity off

Control / Framework Analysis

Existing control
FDA premarket cybersecurity expectations for new submissions, including code signing and an SBOM. The manufacturer’s vulnerability disclosure program.
Observed limitation
In the frameworks reviewed here, there’s no patient-facing standard for notice or consent before a remote update to a home therapy device.
Unaddressed dependency
The patient is asleep during the attack window, and clinician dashboards read device-reported data.
Proposed control
Mandatory patient notification and consent before any remote firmware update on a home medical device. Cryptographic code signing with independent verification before update acceptance. Anomaly detection on therapy parameter changes post-update. FDA-mandated Software Bill of Materials (SBOM) for all connected home medical devices. Patient-accessible audit log of all remote device interactions.
Frameworks referencedFDA Cybersecurity Guidance 2023IEC 62443-4-2 CR 3.4NIST 800-53 SI-7NIST 800-53 SA-10HIPAA §164.312(a)(2)(iv)No Patient Consent Standard for Remote UpdatesHome Device Monitoring Gap
Evidence & References
08 / SCENARIO
Threat Model
Major Neurocognitive Disorder
Home Health Failure Chain
Critical

A patient with major neurocognitive disorder (DSM-5; formerly called dementia) living at home relies on a connected ecosystem of smart sensors, GPS tracking, automated medication dispensers, and telehealth platforms. Each device is a lifeline. Each connection is a potential failure point. The patient cannot self-advocate when the system fails.

Home CareData Integrity

Evidence basisModeled on a real care pattern: connected home monitoring for a family member living alone. No specific product or incident.

Failure Chain

1
Ecosystem dependency established. Smart sensors, GPS, automated dispenser, telehealth. All connected. All networked. None secured.
2
Single network compromise cascades across all devices. Home router exploited. Sensor data manipulated. Medication schedule altered. GPS spoofed.
3
Patient cannot self-report the failure. Short-term memory impairment. No self-advocacy. No internal alarm system.
4
Remote caregiver receives false normal data. Clean dashboards. No alerts. No anomalies. No reason to intervene.
5
Delayed detection. Preventable harm. Fall not detected. Medication missed or doubled. Wandering event not caught.

Patient-Side Impact PSTM →

False-normal dashboards → Missed fall, wandering or dose error → Patient can’t report it → Delayed rescue
Physiological dependency
High — safety and medications run through the ecosystem
Latency to harm
Hours to days
Bedside detectability
Very low — the patient can’t self-report
Workaround pressure
High — falls on family caregivers
Downtime survivability
Untested — no fallback check-in

Control / Framework Analysis

Existing control
HIPAA administrative safeguards where a covered entity is involved. FDA digital health policy for home-use devices. Consumer smart-home security left to vendors.
Observed limitation
Much of this ecosystem is consumer tech outside device regulation, and caregiver dashboards trust device-reported data. The public summary of a 2025 WHO/Europe overview of telemedicine in dementia care doesn’t address device or data security.
Unaddressed dependency
The patient can’t self-advocate, so detection depends entirely on other people.
Proposed control
A security baseline for connected home care ecosystems serving people who can’t self-advocate, separate from hospital IoMT assumptions. Network segmentation between care devices and general household WiFi. Caregiver alert integrity checks. A scheduled human check-in that doesn’t depend on the dashboard.
Frameworks referencedFDA Digital Health Policy (Home Devices)NIST 800-53 SC-3HIPAA §164.308 (Admin Safeguards)NIST AI RMF GOVERN 6.1No Home IoMT Security StandardCaregiver Alert Integrity GapVulnerable Population Protection Gap
Evidence & References
09 / SCENARIO
Threat Model
CGM Signal Compromise
Dexcom G7
Critical

A compromised continuous glucose monitor transmits falsely normal readings. An endocrinologist makes an insulin dosing decision on manipulated data. The patient never knew the signal was wrong.

IoMT & DevicesData Integrity

Evidence basisNo public exploit against the Dexcom G7 is known. This models where integrity can fail between sensor and screen.

Failure Chain

1
Glucose data travels a long chain. Sensor to Bluetooth, to the phone app or receiver, to the cloud, to follower apps and clinic reports, and sometimes to an insulin pump.
2
Integrity breaks inside the chain. A malicious app on the phone or a tampered data path changes values before they display. The readings look in range while the patient runs high.
3
The patient trusts the number. CGM readings like these are cleared for treatment decisions without a fingerstick check. There is no reason to doubt a clean curve.
4
The clinician reviews a clean report. Fourteen days of manipulated data show strong time in range. The dose stays the same. The lab A1c doesn’t match, and that gets read as a lab issue.
5
Harm arrives slowly and silently. Months of hidden hyperglycemia. Follower alerts stay quiet too, because they read the same bad data.

Patient-Side Impact PSTM →

Falsely in-range readings → Insulin unchanged or mis-dosed → Months of hidden hyperglycemia, or an unrecognized low
Physiological dependency
Drives treatment decisions
Latency to harm
Days to months (hours for a low)
Bedside detectability
Low — the curve looks clean
Workaround pressure
Moderate
Downtime survivability
Survivable — fingerstick meter

Control / Framework Analysis

Existing control
iCGM special controls (21 CFR 862.1355). FD&C Act §524B for new cyber devices. FDA premarket cybersecurity guidance.
Observed limitation
Controls emphasize accuracy and secure communication. Integrity checks don’t clearly extend to every downstream display, such as clinic reports and follower apps.
Unaddressed dependency
The phone app is a trust boundary the manufacturer doesn’t control.
Proposed control
Integrity protection from sensor to every screen, including clinic reports, not just encrypted transmission. An automatic flag when the lab A1c and the CGM-estimated average disagree by a wide margin. Patient teaching: if how you feel doesn’t match the number, check a fingerstick. Hardened phone-app trust boundaries and a device SBOM. Post-market monitoring that watches for integrity anomalies, not only outages.
Frameworks referencedFD&C Act §524B (Cyber Devices)FDA Premarket Cybersecurity Guidance21 CFR 862.1355 (iCGM)IEC 81001-5-1AAMI TIR57Mobile App Trust Boundary GapData Integrity vs. Confidentiality Gap
Evidence & References
02 — Respond · Decision Mode

You Are The Responder.

Select a scenario — read the situation — make the call.

0
Correct Decisions
Your Response
Healthcare Breach Intelligence

Healthcare Breach
Incident Tracker

Real incidents. Real patient impact. Real framework gaps. Attacks on hospitals are attacks on human life — not just data. A few of the largest below — the full searchable tracker has the complete dataset.

● MAINTAINED DATASET
Last verified: Sept 26, 2026
Source: HHS OCR + HIPAA Journal + Comparitech
Change Healthcare
Feb 2024 · ALPHV/BlackCat
192.7M
individuals impacted
The decade's defining event. Prescription processing offline nationwide for weeks — the blueprint every 2025 attacker followed.
DentaQuest
Jul 2026 · ShinyHunters
15M
individuals notified
Dental/vision benefits administrator for ~33M people. A researcher counted 1.7M SSNs — most belonging to children. The largest health breach disclosed in 2026.
McKesson
Aug 2026 · ShinyHunters
6.4M
individuals in leaked data
Cloud accounts behind McKesson's oncology and med-surg units were hit through social engineering. The $55M ransom went unpaid and the data went public: diagnoses, medical notes, cancer details.
View the full Incident Tracker → Data methodology →
NOTE: All incidents sourced from public disclosures, the HHS breach portal, and verified media reporting. Every incident here represents real patients — whether their care was disrupted or their most sensitive records were exposed. Attacks on healthcare organizations are attacks on human life.
03 — Assess · Use the Lab

Bring the Lab into
your organization.

The same scenarios, decisions and patient-side method, run against your environment, with your clinicians and your security team in the room.

  • IoMT tabletop exercises
  • Clinical downtime drills
  • Clinical AI risk reviews
  • Incident-response training
  • Security awareness for clinical staff
  • Patient-side threat modeling
Book a 20-minute Fit Call →
For hospitals & health systems
The 3 A.M. Downtime Drill
Built on Scenario 06. A clinical ransomware exercise for ED, nursing and emergency management.
For digital health & AI vendors
Clinical AI Harm Review
Built on Scenario 02 and the DFR AI Red Team. Findings scored by what they would do to a patient.
For AI & health tech teams
Fractional Clinical Safety Advisor
A standing clinical voice for security, product and customer conversations.
About This Lab

Built from
Lived
Reality.

What is this?

A public research environment for healthcare cyber risk: where connected medical devices, clinical AI and hospital systems fail, and what that failure does to a patient.

How is it built?

From clinical practice, public incident reporting, regulatory guidance, and daily device dependency: pulmonary hypertension managed with a portable oxygen concentrator and a CPAP connected to the internet. Every scenario is labeled as a documented incident, a documented vulnerability, a threat model, or an author-developed scenario, and lists its sources.

What method does it use?

Patient-Side Threat Modeling (PSTM) reads each failure through five lenses: physiological dependency, latency to harm, bedside detectability, workaround pressure and downtime survivability. Response follows the Digital First Responder sequence: Triage, Stabilize, Treat, Recover.

How can organizations use it?

As source material for tabletop exercises, downtime drills, clinical AI reviews and training. See how to bring it in →

Created by Chaunda C. Dallas, MSIT, Healthcare Cybersecurity Strategist. chaundacdallas.com →

9
Live Scenarios, Each Evidence-Labeled
3
Grounded in Documented Incidents or Vulnerabilities
5
PSTM Lenses Applied to Every Scenario
26
Incidents in the Breach Tracker Dataset
28+
Years of Clinical Experience Behind It
Key Resources
FDA Guidance
Cybersecurity in Medical Devices
FDA's 2023 guidance on cybersecurity requirements for medical device submissions. The baseline for IoMT security compliance.
FDA.gov →
NIST Framework
AI Risk Management Framework
NIST AI RMF 1.0 — governance framework for trustworthy AI. Directly applicable to clinical AI decision support tools.
NIST AIRC →
HHS Resource
405(d) Cyber Performance Goals
HHS Healthcare Cybersecurity Performance Goals — the healthcare-specific security baseline from the federal government.
405d.HHS.gov →
Threat Intelligence
HHS Breach Portal
Official HHS portal tracking healthcare data breaches affecting 500+ individuals. Primary source for incident intelligence.
HHS OCR Portal →
Community
Women in CyberSecurity (WiCyS)
Primary community for women in cybersecurity. Scholarships, mentoring, and career development resources.
WiCyS.org →