Case Study: Threat Modeling for Medical Software

Medical software can directly impact patient safety, making threat modeling essential during development. This structured process identifies and mitigates security risks, ensuring compliance with FDA regulations and protecting against potential harm. The case study focuses on an infusion pump management system, highlighting:

• Key risks: Spoofing, tampering, data breaches, denial of service, and privilege escalation.
• Mitigations: Encryption (TLS 1.2+, AES-256), secure boot, mTLS, RBAC, and tamper-evident logs.
• Regulatory alignment: FDA mandates threat modeling for submissions, requiring detailed documentation and integration with safety risk management.

Case Background: The Software and Its Environment

Clinical Workflow Overview

The focus of this case study is a Class II infusion pump management platform. This system allows clinical staff to handle critical tasks like configuring dosing, monitoring real-time infusions, and securely logging every change.

The platform is used by a variety of professionals, including bedside nurses, pharmacists, and biomedical engineers. Each role interacts with different types of data, ranging from protected health information (PHI) to commands that directly impact patient safety. Given the potential for harm from misconfigurations, the system demands high availability and rigorous access controls.

System Architecture and Interfaces

The platform’s architecture is built to support the detailed clinical workflows while addressing potential vulnerabilities. It operates on a three-tier architecture:

• Bedside pumps communicate via hospital Wi-Fi.
• A mobile clinical interface runs on staff-issued tablets.
• A cloud-hosted backend manages drug libraries, audit logs, and telemetry data.

An integration layer securely connects the system to the hospital’s electronic health record (EHR), enabling the exchange of admission data and infusion records. Each connection represents a separate trust boundary, requiring specific protections to maintain security.

Henry Anfang, Firmware Developer at Punch Through, emphasizes the importance of aligning security architecture with the threat model:

"The FDA guidance makes it clear that your security architecture is the direct, tangible response to your threat model." ^[5]

To address this, the system's architecture was documented using three specialized views instead of a single overarching diagram:

• A global system view, which maps all network interfaces and trust boundaries.
• An updateability view, detailing the secure chain for software updates from the build server to the pump.
• A multi-patient harm view, which highlights how network segmentation limits the impact of a compromised device to prevent ward-wide risks.

These architectural considerations underscore the importance of meeting regulatory standards.

Regulatory and Security Requirements

Meeting stringent regulatory requirements starts with a well-informed threat model. Since the platform includes Wi-Fi connectivity and software capable of altering therapy, it is classified as a networked medical device under Section 524B of the FD&C Act. This classification comes with specific obligations, such as:

• Creating a documented threat model.
• Providing a Software Bill of Materials (SBOM).
• Maintaining a post-market vulnerability monitoring plan.
• Demonstrating cybersecurity readiness at the time of submission ^[6].

Additionally, the FDA mandates that the system be designed under a hostile-network assumption - essentially treating hospital Wi-Fi as if it could be monitored or manipulated by adversaries ^[4]. Beyond FDA guidelines, the system also needed to align with other key standards, including AAMI TIR57 for security risk management and IEC 81001-5-1 for lifecycle security activities. These standards integrate cybersecurity findings with patient safety outcomes under ISO 14971.

The table below outlines the relevant standards and their impact on the project:

These regulations provide the foundation for the threat modeling strategies discussed in the next section.

sbb-itb-535baee

How to Apply Threat Modeling to Medical Software

Defining Scope and Objectives

The first step was identifying what needed protection. For the infusion pump platform, this meant cataloging assets like PHI (Protected Health Information), drug libraries, therapy commands, audit logs, and clinician credentials. Each of these was evaluated based on its potential clinical impact if compromised.

Defining the scope also involved documenting the environmental assumptions built into the design. Following FDA guidance, the team operated under the assumption of a hostile network environment, adopting a zero-trust mindset. This perspective influenced every subsequent decision. Felix Lenhard, MedTech Coach, summed it up well:

"The threat model you do not build in week 20 is the change control you will fund in week 80." ^[2]

With this scope defined, the team moved on to mapping data flows to identify critical trust boundaries.

System and Data Flow Mapping

Once the scope was clear, the team translated the system architecture into Data Flow Diagrams (DFDs). These diagrams detailed how data moved between key components: bedside pumps, the mobile interface, the cloud backend, and the EHR integration layer. The purpose was to highlight trust boundaries - those points where data crosses from one system or environment to another.

"Boundaries are where attacks cross. Running STRIDE on every component produces noise. Running it on every boundary produces a list of threats a human can actually review." - Felix Lenhard, MedTech Coach ^[2]

Instead of analyzing each system component in isolation, the team focused on trust boundaries. For example, they examined the pump-to-Wi-Fi link, the mobile app-to-cloud API, and the EHR integration endpoint. Sensitive pathways, like over-the-air (OTA) firmware updates and authentication processes, received extra scrutiny since compromises in these areas could directly impact patient safety.

Threat Identification and Risk Prioritization

With data flows clearly mapped, the team systematically identified and prioritized potential threats. They used the STRIDE framework, which categorizes threats into six areas: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. Each category targets a specific security property.

To prioritize these threats, the team applied DREAD scoring, which evaluates threats based on Damage, Reproducibility, Exploitability, Affected Users, and Discoverability. Threats with high DREAD scores, especially those that could directly harm patients, were escalated into the ISO 14971 risk management file. This ensured cybersecurity findings were directly tied to clinical safety outcomes. By integrating security mitigations into the overall safety case, the team avoided treating cybersecurity as a separate concern, aligning it instead with the device's broader safety goals.

Threat Modeling for Medical Devices: Practical Steps for Stronger Cybersecurity

Findings: Threats, Risks, and Mitigations

Key Threats Identified

The STRIDE analysis and DREAD scoring revealed six major threat categories that could impact patient safety.

Spoofing emerged as one of the most severe risks. For example, an attacker could impersonate a legitimate device or clinician, injecting false sensor data - like fake glucose readings - to manipulate insulin dosing ^[7]. Similarly, Tampering posed critical dangers, such as unauthorized changes to drug library data or dosage calculations, potentially leading to life-threatening over- or under-dosing scenarios ^[7].

Information Disclosure was another significant concern, particularly with unencrypted telemetry. Sensitive data, including patient vitals and PHI, transmitted over wireless channels could be intercepted. This issue is magnified by predictions that by 2025, 89% of healthcare organizations will have internet-connected IoMT devices with known security vulnerabilities, many of which are already targeted by ransomware campaigns ^[1]. Denial of Service (DoS) threats directly impacted device availability, with attackers potentially flooding the pump's wireless interface to disrupt critical medication alerts. Repudiation and Elevation of Privilege rounded out the findings, with the latter being especially worrisome - an attacker gaining administrative access could compromise the broader hospital network.

To address these risks, targeted mitigation strategies were implemented, as detailed below.

Mitigation Strategies and Risk Reduction

Each identified threat was matched with specific controls to reduce risk. For Spoofing, mutual TLS (mTLS) and cryptographic device certificates were implemented to verify the identities of all devices and connections. Tampering risks were mitigated through secure boot processes and code signing, ensuring firmware integrity, particularly during over-the-air (OTA) updates.

To counter Information Disclosure, all data transmitted was encrypted using TLS 1.2 or higher, while PHI stored locally was secured with AES-256 encryption. Repudiation was addressed by introducing tamper-evident audit logs, while Elevation of Privilege risks were minimized with role-based access control (RBAC) and application sandboxing. For Denial of Service, rate limiting and watchdog timers were added to maintain device responsiveness during abnormal traffic conditions.

Christian Espinosa, CEO of Blue Goat Cyber, highlighted the evolving expectations in cybersecurity:

"Reviewers are no longer asking whether you threat-modeled - they are asking which methodology you used, which threats you missed, and how each control was verified." ^[4]

Each control was meticulously documented in the ISO 14971 risk management file, integrating cybersecurity measures into the clinical safety framework rather than treating them as separate tasks.

Threats and Mitigations Summary Table

The table below provides a concise overview of the threats identified, their risk ratings, the mitigation measures applied, and the residual risk levels after controls were implemented.

For residual risks rated Medium, such as certain DoS scenarios, formal acceptance was documented in the risk management file, following FDA guidance. This ensures that all remaining risks are consciously acknowledged and traceable, leaving no room for unaddressed vulnerabilities.

Operationalization and Continuous Risk Management

Keeping the Threat Model Current

A threat model created during the design phase can quickly lose its value if it isn’t kept up to date. Any architectural changes - like adding a third-party library, tweaking a wireless interface, or adjusting a clinical workflow - demand a fresh review of the threat model. For the infusion pump system in this case study, re-running STRIDE analysis is essential whenever a new SOUP component is added or a trust boundary shifts. Pairing this with a formal 90-day review cycle, overseen by the Information System Security Officer (ISSO), ensures that no mitigation efforts slip through the cracks. Linking the Software Bill of Materials (SBOM) to the threat model also allows for immediate action when new Common Vulnerabilities and Exposures (CVEs) are identified.

This constantly updated threat model becomes a critical input for broader risk management frameworks, as explained below.

Integration with HDO Risk Workflows

To maintain relevance, the outputs from threat modeling must seamlessly integrate with existing risk management processes. A common pitfall in this area is maintaining separate security and safety risk files, a practice that can lead to gaps in oversight. Tibor Zechmeister, a Notified Body Auditor, highlighted this issue:

"Threat modeling is the bridge between EN IEC 81001-5-1:2022 and the EN ISO 14971 risk file." ^[2]

Each threat identified through STRIDE must be directly traceable to a specific hazardous situation documented in the ISO 14971 risk management file. This traceability ensures clear connections to the corresponding control measures, security requirements, and verification test cases. For Healthcare Delivery Organizations (HDOs) evaluating third-party medical software, a well-maintained traceability matrix offers tangible, auditable proof that security has been integrated into the product's design. Additionally, under the FDA's 2026 cybersecurity guidance, manufacturers are required to maintain a Cybersecurity Management Plan, which must identify responsible individuals and establish patch timelines. This makes integrating threat modeling into broader risk workflows not just a smart move but a regulatory requirement.

How Censinet RiskOps™ Supports Continuous Risk Management

Manually managing the level of rigor required for continuous risk assessment can be overwhelming. Censinet RiskOps™ simplifies this by consolidating vendor and enterprise risk assessments into a single, continuously updated platform. Instead of relying on static spreadsheets, the platform maintains live risk profiles with complete assessment histories, automated Corrective Action Plans (CAPs), and real-time alerts for breaches and ransomware. These alerts are tied directly to an organization’s specific inventory, ensuring that security measures stay aligned with both clinical safety standards and the latest threat landscape.

For example, Tower Health, a healthcare system in Pennsylvania, used Censinet RiskOps™ to reduce the time needed for risk assessments from 5–6 weeks to under one week. Terry Grogan, their CISO, shared:

"Censinet RiskOps allowed 3 FTEs to go back to their real jobs! Now we do a lot more risk assessments with only 2 FTEs required." ^[9]

Conclusion: Key Insights and Best Practices

Lessons Learned

Threat modeling becomes genuinely effective when it’s embraced as an integral part of engineering, rather than just a compliance exercise. Tibor Zechmeister, a Notified Body Auditor, highlights this perfectly:

"Threat modeling is the single activity that distinguishes a security-aware manufacturer from one running on optimism." ^[2]

One standout takeaway? Focusing on trust boundaries yields better results than scrutinizing every single component. Why? Because most attacks happen where these boundaries intersect. Another critical shift is moving away from probability-based scoring to exploitability-based metrics like CVSS. After all, deliberate attacks aren’t about chances - they’re about ease of execution. These principles lay the groundwork for a more practical and effective approach to threat modeling.

The financial argument for early action is compelling. Fixing security issues post-release can be 4 to 5 times more expensive than addressing them during the design stage ^[3]. To put it in perspective, software-related quality issues cost the medical device industry up to $5 billion annually ^[3].

Recommendations for Implementation

To put these lessons into practice, start with the basics: draw a Data Flow Diagram. Highlight all trust boundaries and cross-check them with your risk file before identifying threats. Use the STRIDE methodology for each trust boundary, not for individual components, to keep the process streamlined and easy to audit.

Two habits separate high-performing teams from the rest. First, log every identified threat in your ISO 14971 file - this helps avoid audit issues ^[2]. Second, treat your threat model as a dynamic document. Connect it to your SBOM, update it with every architectural change, and automate SBOM generation using tools like Syft or CycloneDX within your CI/CD pipeline ^[5].

Looking ahead to FDA submissions in 2026? The eSTAR system will require 11 specific cybersecurity deliverables, including Architecture Views, a Vulnerability Assessment, and a Postmarket Cybersecurity Management Plan ^[8]. Starting with a traceable threat model from the very beginning will save you time and headaches down the road.

FAQs

What should I include in a threat model for a networked medical device?

To build an effective threat model for a networked medical device, it's crucial to pinpoint security risks throughout the entire system. This includes areas like cloud platforms, mobile applications, and hospital networks. Start by using system architecture diagrams and data flow diagrams (DFDs) to map out all components and identify trust boundaries within the system.

Frameworks such as STRIDE or MEDICALHARM can help systematically analyze potential threats. Additionally, incorporating a Software Bill of Materials (SBOM) ensures transparency about the software components in use. It's also important to connect identified threats to potential patient safety impacts, following the guidelines outlined in ISO 14971.

Finally, document all mitigation strategies and evaluate any residual risks to ensure the system remains as secure as possible while prioritizing patient safety.

How do I connect cybersecurity threats to ISO 14971 patient safety risks?

When addressing cybersecurity threats in your ISO 14971 risk file, consider treating security events as potential hazards that could lead to clinical harm. Your existing threat model can serve as a valuable input for updating your risk management documentation.

Here’s how:

• Identify threats: Use established frameworks like STRIDE to pinpoint threats. Then, link these threats to possible clinical outcomes, such as a delay in therapy or compromised patient safety.
• Evaluate risks: Apply ISO 14971 principles, but instead of using traditional probability metrics, assess risks based on exploitability - how likely it is that a vulnerability could be exploited.
• Document thoroughly: Ensure all identified risks are recorded within your primary risk file. This step is crucial for maintaining traceability and aligning with regulatory requirements.

By following these steps, you integrate cybersecurity considerations seamlessly into your risk management process, ensuring a more comprehensive approach to patient safety.

How often should a medical device threat model be updated, and what triggers a re-review?

A medical device threat model isn't something you create once and forget about - it needs to evolve alongside the product. Anytime there's a change in the device's architecture - whether it's a tweak to the design, swapping out components, or adjustments to the operational environment - the threat model should be updated to reflect those changes.

This isn't just a one-time task during development either. As cybersecurity risk analyses are refined and new security measures are introduced, the model should be revisited and revised. Keeping it up-to-date ensures it remains a reliable tool for identifying and addressing potential threats throughout the device's lifecycle.

Related Blog Posts

• How STRIDE Enhances Medical Software Security