Threat Modeling in Medical IoT Devices
In most software, the worst an attacker can do is steal data or take the system down. In a medical device, the worst is to hurt the person wearing it. That one difference changes how you threat model.
If you want the method itself, start with What is Threat Modeling. This piece applies it where the stakes are physical.
Take a real kind of product: a diabetes management tool. Call the patient Emma. She wears a device that reads her glucose and helps manage insulin, she has an app on her phone that logs doses and shows trends, a cloud service stores her data, and a link lets her doctor see it. Convenient, connected, and full of boundaries where trust changes hands.
Now run STRIDE across it, the same six questions you would ask of any system:
- Spoofing: someone logs in as Emma or her doctor and changes her plan.
- Tampering: someone alters her glucose readings, or worse, a dosing instruction.
- Repudiation: an action is taken and no log can prove who did it.
- Information disclosure: her health data leaks.
- Denial of service: the service goes down and she or her doctor cannot reach it when it matters.
- Elevation of privilege: an attacker reaches an admin function in the records system and touches many patients at once.
Watch what happens to the ranking
In an e-commerce app you would put information disclosure and denial of service near the top, because the damage is money and reputation. Here the ranking inverts. The nightmare is Tampering, and specifically anything that changes a dose, or changes the reading a dose is based on. A leaked glucose history is a serious privacy harm. A silently altered dose is a medical emergency. When the worst case is physical, damage to the patient has to dominate, not sit as one factor among five.
This is why I am wary of running a medical device through DREAD and trusting the total. DREAD averages five factors, and averaging can drown the one that matters. A dose-tampering threat might score “medium” on how easy it is to reproduce and discover, and come out looking moderate, while its damage potential is “someone could be seriously harmed.” Average that and you have hidden the only number that counts. For safety-critical systems, rank by worst-case harm first, then let the other factors break ties.
This is not hypothetical
In 2019 the US Food and Drug Administration warned that certain Medtronic MiniMed insulin pumps could be reached over their wireless link and have their settings changed, and the devices were recalled. Researchers had shown the pump trusted commands it should not have. The risk was not a data leak. It was an attacker, or even stray interference, changing how much insulin a person received. That is the exact threat sitting at the top of Emma’s model, confirmed in the real world on a shipping product that people depended on to stay alive.
What the model tells you to build
The reframe changes which fixes come first:
- Protect the dosing path above everything. The command that changes insulin delivery is the crown jewel. Authenticate it, and do not let the device trust a command just because it arrived on the expected channel.
- Put the safety limit in the device, not the app. This is the medical version of a lesson that runs through all of security: never trust one layer to protect another. The hardware itself should refuse a dose outside safe bounds, no matter what the app or the cloud says. If the phone is compromised, the device still says no.
- Make every clinical action undeniable. Tamper-evident logs, so a changed plan can always be traced. In a dispute about a patient’s care, “we cannot tell what happened” is its own harm.
- Then handle disclosure and availability. Still real, still required, just ranked below the thing that can put Emma in the hospital.
The point
Threat modeling a medical device uses the same four questions and the same STRIDE checklist as anything else. What changes is the weight. When a bug can cost a life, the model is not a compliance exercise and the score is not an average. The whole job is to find the handful of failures that reach the patient and make them impossible, or as close to impossible as engineering allows, even when something upstream has already been compromised.
So the question to ask of any connected medical device is the blunt one: what is the worst thing that could happen to the person wearing this, and have we built it so that no single attacker, and no single failure, can make it happen? Everything else on the list matters. That question decides whether the device is safe.