The What, Why and How of Medical Device Cybersecurity

Medical device cybersecurity threat modeling is the structured process of identifying how a connected device's design could allow a security threat to cause harm, and then building mitigations before those weaknesses reach the market. This article walks through the core building blocks, threats, vulnerabilities, Data Flow Diagrams, and the STRIDE framework, and how IEC 81001-5-1 and ISO 14971 tie them together.

Ransomware attacks on hospitals and the compromise of connected devices have pushed medical device cybersecurity to the top of the agenda for product managers, development engineers, and regulatory and quality specialists. The terminology can feel foreign to teams new to the space, and it isn't always clear how a concept like threat modeling connects to an established framework such as ISO 14971. This guide closes that gap.

What Is a Cybersecurity Threat in Medical Devices?

A cybersecurity threat is the potential for a security violation. A circumstance, capability, action, or event that could breach the confidentiality, integrity, or availability of a medical device's information assets (IEC 81001-5-1). A threat only becomes a security violation when a vulnerability, a weakness in code, configuration, protocol, or process, is actually exploited by an attacker.

Vulnerabilities can be introduced inadvertently through a design or coding oversight, or intentionally, and they exist wherever a device interacts with software, hardware, or human processes. Treating threat and vulnerability as a pair, rather than as separate concepts, makes it possible to reason about a device's actual exposure, rather than treating cybersecurity as an abstract compliance line item.

Why Does Medical Device Cybersecurity Depend on Threat Modeling?

Threat modeling is the structured analysis of the threats a device faces, conducted to identify, enumerate, and prioritize the vulnerabilities associated with each threat against the device's actual design. Rather than reacting to security incidents after release, a manufacturer uses threat modeling to design the exposure out before it exists.

Take a device that transmits health data over Bluetooth. Information disclosure is a foreseeable threat in this context. Modeling it shows that unencrypted Bluetooth transmission is the vulnerability an attacker would exploit to realize that threat, which is why a Bluetooth encryption requirement gets added to the design. Threat, to vulnerability, to design requirement: that sequence is the exercise in miniature.

What Is a Data Flow Diagram for Medical Device Cybersecurity?

A Data Flow Diagram (DFD) is the standard way to depict a medical device's components, how data moves between them, and the trust boundaries that separate elements with different levels of trust. Threat modeling is a cross-functional exercise, and a DFD provides the team with a shared visual reference rather than a lengthy design description that no one can hold in their head at once.

DFD version 3 uses five symbols to represent a device's internal and external components, their interactions, and their trust boundaries. The diagram below shows a fictional device: a sensor measuring a physiological parameter, transmitting the measurement to an app on the patient's phone, which then uploads it to cloud storage accessible to both the patient and their healthcare provider.

This level of detail doesn't capture every data flow or interaction, and it isn't meant to. It's enough to start a threat modeling exercise. Like most of medical device development, threat modeling is iterative — the diagram gains components, flows, and detail as the team works through it.

How Does the STRIDE Framework Work for Medical Device Threat Modeling?

STRIDE is a threat modeling framework, Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege, that groups threats into six categories, the same way ISO 14971 groups device hazards. Developed by security researchers at Microsoft in 1999, it remains the most widely used structured threat modeling technique.

STRIDE can be applied per element, per data flow, per interaction, per workflow, or per trust boundary crossing. For a fictional device's first iteration, the per-boundary-crossing approach works best: it focuses attention on the attack surfaces at each trust boundary while setting aside the internal complexity within a boundary for later.

The table below lists several threats identified for data flows crossing trust boundaries in the fictional device, as shown in the DFD above, following the initial round of brainstorming in a threat modeling session. The first table indexes threats for each boundary-crossing data flow by STRIDE category. The subsequent table provides descriptions for each threat. 

An early-stage threat description will often read as generic, and that's expected. At this point in a device's design, or where design information is still limited, the model is telling you where more analysis is needed rather than delivering a finished answer. For an already-designed device, expand the relevant DFD elements for deeper analysis; for a device still in development, keep iterating the model as new design details land, and feed what you learn back into the design.

How Does Threat Modeling Fit Into ISO 14971 Risk Management?

Threat modeling and ISO 14971 risk management run as parallel processes with a shared vocabulary: STRIDE's six threat categories function much like ISO 14971's hazard categories, and IEC 81001-5-1 was written to interlock with a device's existing risk management file rather than replace it. Where a security threat could plausibly compromise a safety-related function, that threat should be traceable in the risk management file as a hazard, not left only in the security team's records.

In practice, this means the outputs of a threat modeling session — the threats, the vulnerabilities behind them, and the design requirements chosen to mitigate them, need a defined path into the same risk file that documents clinical hazards, so a Notified Body reviewing the file sees one traceable picture of harm rather than two disconnected documents. The exact mechanics of that traceability (which fields, which templates, which sign-off) are specific to each manufacturer's QMS, which is why a gap assessment against your own procedures is usually the first useful step.

What Happens After the First Round of Threat Modeling?

Threat modeling continues throughout a device's entire lifecycle, incorporating new design details, design changes, and vulnerabilities identified through penetration testing, post-market surveillance, and public vulnerability databases. STRIDE is rarely used alone: Attack Trees provide a view of specific attack vectors and their exploitability, and the Cyber Kill Chain maps how a sophisticated, multi-stage attack would unfold against the device.

For more on applying these methodologies in practice, the Playbook for Threat Modeling Medical Devices, developed by MITRE with US FDA support, is a solid next resource.

How Qserve Can Help

Qserve's active medical devices team works alongside RA, QA, and engineering teams on the cybersecurity side of MDR, IVDR, and EU AI Act compliance, from facilitating threat modeling and IEC 81001-5-1 gap assessments to integrating cybersecurity evidence into an existing ISO 14971 risk file and Notified Body technical documentation.

• AI/ML Regulatory Support for connected and AI-enabled devices where cybersecurity and EU AI Act obligations increasingly overlap.
• Dossier Submission Support for folding cybersecurity documentation into a pre-market submission.
• Contact us to talk through your device's threat model with our team.