Deciding Which Threats Are Relevant to Your Medical Device

Part of our Medical device vulnerability, threat, and attack-technique catalogue. For the full overview, start with The Top 50 Cybersecurity Issues with Medical Devices.

Most threat catalogs list the same forty items regardless of what the device does, and a reviewer can tell within a page whether your threat model was copied from one or actually derived from your architecture. The February 3, 2026 premarket guidance expects you to show your reasoning, not just your conclusions, because Section 524B puts the burden of a credible cybersecurity risk analysis on the manufacturer. This post is about the decision process: how intended use and use environment drive relevance, how to run STRIDE per element instead of per device, how to separate patient safety impact from data impact, and how to write the relevance decision so it survives a reviewer's questions. For the separate question of what interfaces exist to threat model in the first place, see the attack surface analysis post.

Why This Matters

The FDA's final guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, issued February 3, 2026 after the September 2023 and June 2025 versions in that chain, asks manufacturers to identify threats specific to their device under Section 524B rather than submit a generic threat inventory. A reviewer reading a threat model that lists every MITRE ATT&CK technique with no connection to the device's own interfaces cannot conclude the risk analysis is complete.

CISA's 2026 Minimum Elements for a software bill of materials, which supersede the NTIA 2021 framework, also assume the manufacturer has already reasoned about which components carry exploitable exposure, since a component inventory without a relevance judgment does not tell a reviewer anything about actual risk. AAMI TIR57 and TIR97 both frame threat identification as an exercise tied to your specific architecture and clinical context, not a literature review.

Getting relevance wrong in either direction causes real cost. Too broad, and the risk file drowns in low value entries that dilute attention from the threats that matter. Too narrow, and a plausible attack path goes unaddressed until postmarket surveillance or an incident surfaces it.

What makes a threat relevant instead of generic?

A threat is relevant when three things are all true for your device: a threat source with real capability and motive exists, that source can reach a specific interface or data flow in your architecture, and the resulting harm is one you can describe in concrete clinical or data terms. Drop any one of the three and the threat belongs in an exclusion log with a reason, not in the active risk register.

Generic catalogs fail this test because they list attack techniques without connecting them to your interfaces. "SQL injection" is not relevant to a device with no database exposed to untrusted input; it is highly relevant to a cloud API backend that stores patient records. The enumeration method in the attack surface analysis post is the input this exercise needs, because you cannot judge whether a threat source can reach an interface you have not identified.

How does intended use and use environment change relevance?

Intended use and use environment determine which threat sources have realistic access and which harms actually matter, so they are the first filter, not an afterthought. A device indicated for a monitored intensive care unit faces a different attacker population than one indicated for unsupervised home use, and the home use versus hospital cybersecurity post covers how that environment shift changes the assumptions your model can make.

How do you run STRIDE without turning it into a checklist?

Run STRIDE against each element of your data flow diagram, processes, data stores, and trust boundary crossings, rather than asking once whether the device as a whole is vulnerable to each category. A single device typically has ten to thirty elements once you break it into components and interfaces, and each one has its own plausible subset of the six STRIDE categories.

Elements that have no realistic exposure to a category get marked not applicable with a one-line reason, which is what separates a real STRIDE analysis from a checklist filled in on autopilot. A data store that never leaves the device and has no write interface does not need a tampering entry beyond physical access controls, and saying so explicitly is more useful to a reviewer than silence.

How do you separate patient safety impact from data impact?

Score patient safety impact and data impact on two separate axes, because the same threat can rate low on one and high on the other, and merging them into a single severity number hides that distinction from the people who need to act on it. ISO 14971 already asks for harm severity tied to the patient, and privacy impact under HIPAA or GDPR runs on a different scale entirely.

A threat that exposes patient names and device serial numbers without any effect on device function is a real data impact and a near-zero patient safety impact. A threat that could cause an incorrect therapy delivery is a severe patient safety impact even if no data is exposed at all. Keeping the two axes separate lets you prioritize the safety-relevant threats for design mitigation first, without deprioritizing the data-only threats that still need addressing under your privacy and security program.

How do you document a relevance decision a reviewer will accept?

Document three things for every threat: the reasoning that made it relevant or not, the element of the architecture it maps to, and the mitigation or the accepted risk decision tied to it. A reviewer checking your work wants to trace a line from architecture to threat to mitigation to test evidence, and a gap anywhere in that chain reads as an unresolved question.

Keep an explicit exclusion log alongside the active threat register. A threat you considered and excluded, with a stated reason such as "no network exposure" or "requires physical access already excluded by the enclosure's tamper design," is far more defensible than a threat that simply never appears anywhere in the documentation. Reviewers who ask "did you consider X" are almost always looking for that log, not looking to catch you skipping X entirely.

Are Ephemeral Ports a Relevant Threat for Your Device?

See also: What Is MedTech? MedTech vs Medical Device vs Life Sciences, CVSS Scoring for Medical Devices: A Complete Walkthrough, and Medical Device Software Development: A Compliance Guide.

Ephemeral ports become relevant to a threat model only when your architecture actually uses outbound connections, and for most connected devices, telemetry, cloud sync, update checks, that condition is almost always true. Ephemeral ports are the temporary, automatically assigned client-side ports, in IANA's 49152-65535 dynamic and private range, that a device's operating system hands out for each outbound connection so many sessions can run at once. They are not a vulnerability by themselves, but running the relevance test from this article against them shows exactly where they do and do not matter.

Applying the three-part relevance test: a threat source (a network attacker or a misconfigured hospital firewall) can reach the interface (the device's outbound connection behavior), and the harm (a missed vulnerability indicator or a failed clinical connection) is concrete. That clears the bar for inclusion, but the specific STRIDE categories that apply are narrower than a generic port-scanning entry would suggest.

The documentation a reviewer expects is not a claim that ephemeral ports are "secured." It is a data flow description: destination IP or FQDN, destination port, protocol, and the logging that would surface an unusual outbound connection or a repeated failure. Excluding ephemeral port ranges themselves from the active threat register, with a one-line reason that they are client-side and not exposed listeners, is a legitimate exclusion under the documentation standard this article describes, as long as egress logging and destination allow-listing are addressed as the actual relevant controls.

Does Steganography Belong in Your Threat Model?

Steganography, hiding data or executable payloads inside legitimate-looking files or traffic, clears the relevance bar for any device with an imaging interface, a firmware update channel, or a telemetry stream, because the threat source, capability, and harm are all documented in the wild rather than theoretical. CISA and the HHS Health Sector Cybersecurity Coordination Center have both published advisories on payloads embedded in DICOM headers and on update-channel abuse where a firmware image passes a naive signature check while carrying smuggled code. That is exactly the kind of sourced, real-world threat source this article's relevance test asks you to look for before adding an entry to the active register.

Running STRIDE at the element level, rather than treating "steganography" as one generic line item, surfaces where it actually attaches to your architecture:

A device with no imaging interface, no update channel accepting external files, and no telemetry stream leaving the device has a legitimate basis to exclude covert-channel threats, with that reasoning stated in the exclusion log rather than left implicit. Most connected devices do not meet that bar, since firmware updates alone are close to universal.

The mitigations trace back to the same integrity controls this site covers elsewhere: signed and verified updates, egress filtering against a known destination list, entropy or size anomaly monitoring on outbound data, and payload validation for DICOM or HL7 interfaces. Documenting the relevance decision, and the specific interface it maps to, is what turns "we considered steganography" from a narrative claim into evidence a reviewer can trace.

How Blue Goat Cyber Approaches This

We start relevance decisions from your intended use statement and your interface inventory, not from a generic threat list, because those two inputs are what actually change which threats apply to your device. Our team, which includes CISSP and OSCP certified engineers and former military red team members, runs STRIDE at the element level and documents both the included and excluded threats so the reasoning survives a reviewer's questions.

We keep patient safety impact and data impact on separate tracks throughout the analysis, which lets us hand engineering a prioritized list for design mitigation rather than a single blended severity score that obscures which threats need physical redesign versus which need an encryption fix. If the FDA raises cybersecurity deficiencies tied to our submission work, we resolve them at no additional cost. Our FDA premarket cybersecurity services build this relevance analysis as a documented, traceable deliverable rather than a narrative summary.

Frequently Asked Questions

Is a generic threat catalog ever useful?

How many threats should a typical device's threat model contain?

Do we need separate threat models for different use environments?

How does STRIDE differ from a DREAD or CVSS scoring approach?

What happens if a reviewer disagrees with a relevance exclusion?

Does threat relevance change after the device ships?

CTA

If your threat model reads like a catalog rather than an argument built from your own architecture, that is what a reviewer will notice first. Book a discovery session and we will walk your device's interfaces into a threat model that holds up to that scrutiny.