Silent Battery Failure
Portable O₂ concentrator failure where loss of power can become a patient event before the failure is obvious.
Open scenario →01 — The inversion
Same device. Different question.
In enterprise IT, the triad runs Confidentiality → Integrity → Availability. At the bedside, that order can invert because the consequence is no longer abstract. PSTM makes the patient the unit of consequence.
The question that changes the register
How fast can this compromise become a clinical event?
Show the full network-side vs. patient-side comparison
| Network-side | Patient-side | |
|---|---|---|
| Core question | What can an attacker reach? | What happens to the human when it’s reached? |
| Priority order | C → I → A | A → I → C on life-sustaining tiers |
| Unit of risk | Asset / node | Patient / procedure |
| Prioritization driver | CVSS | Latency to harm |
| Detection endpoint | The SOC | The bedside |
| Blind spot | The clinical workaround | The workaround becomes a primary lens |
02 — The clinical reality
What the SOC cannot see.
Security telemetry tells you that something changed. It does not automatically tell you what that change means to the person in the bed, the clinician at the workstation, or the next patient waiting for care.
PSTM starts here
Follow the finding all the way to the bedside.
01 / DEVICE
The screen says the dose is correct.
The pump is lying.02 / CLINICIAN
The SOC sees the alert.
The nurse sees four patients.03 / CONTROL
The policy says timeout.
The code is still running.04 / DOWNTIME
The procedure exists.
Can tonight’s shift actually execute it?03 — Patient-side test
Run the finding through the patient-side lens.
Choose a clinical situation. PSTM shifts the question from technical severity to patient consequence — dependency, response window, detection and survivability.
Interactive demonstrationSame vulnerability. Different clinical consequence.
Networked infusion pump
Unauthorized parameter changes during active medication delivery.
Patient-side question
If this finding is exploited, what changes for the patient before someone can detect it?
Patient-side reading
Physiological dependencyHigh
Latency to harmMinutes
Bedside detectabilityLow
Downtime fallbackTestable
A technical finding becomes a clinical priority when the patient can be affected before the bedside can verify what happened.
PSTM response focus: validate dose integrity, isolate the affected fleet, and verify the clinical fallback.
Illustrative of the PSTM reasoning pattern — not a substitute for an environment-specific assessment.
04 — The five lenses
The method.
Each lens asks a question the network-side model cannot answer. Tap a card to see the clinical reality behind it. Run all five against a device, a finding, or a whole environment, and the risk register can be re-prioritized by patient consequence.
Lens 01 · Physiological Dependency
From the floor
The same vulnerability disclosure lands on a networked ventilator and on the server that stores its historical trend data. The register scores them identically. On the ventilator, exploitation is a code blue. On the archive, it’s a breach-notification workflow. Any model that can’t separate those two outcomes isn’t modeling healthcare — it’s modeling a data center that happens to contain patients.
Why network-side misses it
An asset inventory sees two nodes running the same OS with the same CVE. It cannot see that one is keeping a chest rising and the other is archiving vitals for the morning report. Same score. Not remotely the same risk. PSTM tiers every device before anything gets scored:
Life-sustainingventilator · pump running vasopressors · pacing
Life-supportingdialysis · BiPAP · anesthesia delivery
Monitoring / diagnostictelemetry · CGM · imaging
Conveniencebed scales · asset tags · smart TVs
What changesOn life-sustaining tiers, availability and integrity outrank confidentiality by orders of magnitude. Most risk registers have it exactly backwards.
Lens 02 · Latency to Harm
From the floor
A suppressed telemetry alarm hurts no one at minute one. It hurts someone at hour three, when the rhythm changes and nothing sounds. A deleted allergy field hurts no one for days — until the next admission, the next order, the next push of the wrong drug. Latency isn’t a technicality. It is the response window, and it tells you which findings you fix tonight and which can wait for the change window.
Why network-side misses it
CVSS measures exploitability and impact to the system. It has no axis for how fast a human deteriorates. Two findings with the same score can sit on opposite ends of the only clock that matters at the bedside.
MinutesInfusion pump dose manipulation. Ventilator settings. Pacing parameters.
HoursTelemetry suppression. Alarm rerouting. Lab interface tampering.
DaysEHR record tampering. Imaging integrity. Allergy fields quietly edited.
What changesLatency to harm, not CVSS score, drives patch and response prioritization in clinical environments.
Lens 03 · Bedside Detectability
From the floor
A compromised pump can display the ordered rate while delivering a different one. There is no visual difference at the bedside between a pump that is working and a pump that is lying. The nurse checks the screen — that’s the verification step the workflow allows — and the screen confirms the order. Every control downstream of that glance assumes the glance means something.
Why network-side misses it
Detection engineering ends at the SOC. But a “detected” event in the SOC is not a detected event on the floor. Most IoMT compromise is silent at the point of care: the device keeps displaying what the clinician expects to see, and the clinician has four other patients.
Alarm fatigue makes it worse — it is an attacker’s ally. Clinical staff silence hundreds of alarms per shift because most mean nothing. An attacker doesn’t have to hide the alarm. The environment hides it for them.
What changesDetection engineering for clinical environments must account for the human at the bedside, not just the sensor on the wire.
Lens 04 · Workaround Pressure
From the floor
I have been the clinician the screen timeout fired on — mid-resuscitation, gloves on, seconds mattering. The next shift, that workstation stays logged in as whoever touched it first. Security calls that an audit finding. The floor calls it Tuesday. Design the control for the code, not the demo, or the floor will redesign it for you.
Why network-side misses it
Shared logins. Propped doors. A badge taped over the reader. Screens left unlocked because the timeout fires mid-code. Every one of them was invented by a rational person trying to keep a patient alive.
The workaround is the vulnerability. No scanner finds it, no register scores it, and no network-side model can produce this lens — because producing it requires having been the clinician who invented the workaround.
What changesA control that clinicians route around is a control that does not exist. Controls must survive the bedside, or they aren’t controls.
Lens 05 · Downtime Survivability
From the floor
Downtime survivability is a set of testable questions. Are the downtime forms in the box current? Does the charge nurse know where the box is? Is the read-only EHR snapshot fresher than 24 hours? Has anyone on nights — the shift ransomware actually hits — run a paper med pass end to end? Every one of those has a yes/no answer. Almost nobody asks.
Why network-side misses it
The register ends where the outage begins. Paper downtime procedures exist on paper. Most staff hired after 2015 have never executed one — never charted a med pass by hand, never run orders on carbon-copy forms, never worked a floor where the EHR simply is not coming back this shift.
What changesRansomware resilience in healthcare is a training and process problem at least as much as a technical one. The fallback is testable — so test it.
05 — Worked example · Scenario 03
One scenario. Two priority lists.
Scenario 03 in this lab is an infusion pump compromise on an oncology floor: a networked pump receives unauthorized parameter updates during active chemotherapy delivery, while the nurse covers four other patients. Below are six findings a standard assessment of that environment produces — scored the way a network-side register scores them, then run through the five lenses.
6Findings re-ranked
The test: what disappears when the register only knows CVSS? What rises when the patient becomes the unit of consequence?
F1Unauthenticated remote code execution in the pump’s legacy remote-management service.CVSS 9.8
F2Drug-library updates accepted unsigned from any host on the clinical VLAN — dose limits and concentrations can be rewritten in transit.CVSS 8.8
F3PHI transmitted in cleartext between the pump gateway and the integration engine.CVSS 7.5
F4Flat clinical VLAN — the pump fleet shares a network segment with non-clinical systems.CVSS 6.5
F5Shared login on the med-room workstation; screen lock disabled by staff.No CVE · unscored
F6Paper downtime medication procedure last exercised 2019; night shift never drilled.No CVE · unscored
Network-side register
Ordered by CVSS
1F19.8 — critical. Remote code execution tops every list it appears on.
2F28.8 — high. Unsigned update channel.
3F37.5 — high. Cleartext PHI in transit.
4F46.5 — medium. Segmentation gap.
—F5Not on the register. No CVE to score.
—F6Not on the register. Not a technical finding.
Patient-side re-prioritization
Ordered by the five lenses
1F2The finding that reaches the patient.Critical
Life-sustaining tier · latency in minutes · bedside detectability near zero — the pump displays the ordered dose while delivering a different one. Lenses 01 · 02 · 03
Life-sustaining tier · latency in minutes · bedside detectability near zero — the pump displays the ordered dose while delivering a different one. Lenses 01 · 02 · 03
2F1Same fleet, louder failure. Exploitation most plausibly crashes the pump: the infusion stops, the alarm sounds, the nurse sees it. Serious — and visible. Lenses 01 · 03
3F6The response to rank 1 or 2 is “pull the fleet.” That plan is only as real as a paper fallback nobody has run since 2019. Lens 05
4F5The audit trail you’d need to investigate F1 or F2 is already gone — when everyone charts as everyone, attribution dies first. Lens 04
5F4The enabler. It widens the path to F1 and F2; on its own it touches no one.
6F3The register’s #3. Real, reportable, worth fixing — and the only finding here where nobody’s physiology changes.
Two of the top four patient-side risks never appeared on the network-side register at all. The register’s number three landed last. Same environment, same findings — a different question. That reordering is the method.
06 — Framework mapping
PSTM does not replace your frameworks. It reorders them by patient consequence.
PSTM does not replace the standards your organization already uses. It gives those controls a clinical consequence layer, so the output can drop into an existing GRC program.
Existing controlsNIST CSF, HIPAA, FDA, IEC 62443 and HHS 405(d) remain the control environment.
Patient consequencePSTM adds the bedside questions that determine urgency, detection and survivability.
Show the detailed framework mapping
| PSTM lens | NIST CSF 2.0 | HIPAA Security Rule | FDA Pre/Postmarket | IEC 62443 | HHS 405(d) HICP |
|---|---|---|---|---|---|
| 01 Physiological Dependency | ID.AM — assets prioritized by criticality | §164.308(a)(7)(ii)(E) criticality analysis | Premarket: security risk assessment tied to safety risk (ISO 14971) | Zone criticality & security-level targets (62443‑3‑2) | IT asset management |
| 02 Latency to Harm | ID.RA — risk analysis; response prioritization | §164.308(a)(1)(ii)(A) risk analysis | Postmarket: exploitability plus severity of patient harm | Consequence-driven risk assessment (62443‑3‑2) | Vulnerability management |
| 03 Bedside Detectability | DE.CM / DE.AE — monitoring & event analysis | §164.312(b) audit controls | Premarket: design for detection of security events | Timely event response & monitoring (SR 6.x) | Security operations & incident detection |
| 04 Workaround Pressure | PR.AA access control; PR.AT training | §164.308(a)(5) workforce security & training | Human factors & usability engineering guidance | Identification & authentication (SR 1.x), fit for clinical workflow | Identity & access management |
| 05 Downtime Survivability | RS / RC — response & recovery | §164.308(a)(7) contingency plan; (ii)(D) testing & revision | Postmarket: response, resilience & recovery expectations | Backup & system recovery (SR 7.3 / 7.4) | Data protection & incident response planning |
07 — Scenario lab
These are not hypotheticals. Each is a Patient-Side Threat Model.
Choose a lens to see which failure modes exercise it. The full scenario index is still available, but the first view is now designed for scanning.
AI Triage Override
Emergency-department decision support where a manipulated recommendation can look plausible at the bedside.
Open scenario →Infusion Pump Network Compromise
The worked example: unauthorized parameter changes during active chemotherapy delivery.
See worked example →OSINT Recon on Hospital Infrastructure
Publicly observable infrastructure signals that can expose clinical attack paths and operational dependencies.
Open scenario →Wearable Data Spoofing
Athlete and patient data can share the same security failure, but the clinical consequence changes the response.
Open scenario →Ransomware in the ER
The 2am decision: what fails first, what clinicians work around, and whether the fallback actually survives the shift.
Open scenario →CPAP Firmware Integrity
Connected home therapy where device function, patient dependence and detection all sit outside the hospital perimeter.
Open scenario →Major Neurocognitive Disorder Home Health Failure Chain
A patient who cannot self-advocate changes the meaning of detectability, dependency and downtime.
Open scenario →CGM Signal Compromise
Dosing on manipulated glucose data makes signal integrity a direct patient-side concern.
Open scenario →AI Symptom Checker, Steered
Indirect prompt injection that downgrades an emergency, with the clinical failure hiding inside a plausible interaction.
Open AI Red Team →System Prompt Leakage
A clinical assistant gives up guardrails, creating a patient-side question that technical logs alone cannot answer.
Open AI Red Team →Over-Permissioned Scheduling Agent
Machine-speed workflow changes where authorization failure can propagate faster than a human review cycle.
Open AI Red Team →Healthcare Ransomware Intelligence Tracker
PSTM applied at population scale to connect ransomware events with clinical response windows and downtime pressure.
Open intelligence tracker →Showing 13 scenario records. Filter by lens to see where a particular patient-side question is exercised.
08 — Put it to work
Bring Patient-Side Threat Modeling to your team.
PSTM can be applied to a connected-device environment, a clinical ransomware exercise, a GRC program, or a specific AI or medical-device risk. The goal is practical: make the patient consequence visible early enough to change the response.
Speaking, media, or expert-network inquiries: connect@chaundacdallas.com