Design-Time Security Risk Management for Medical Devices
1.0 Purpose
The purpose of this guide is to describe Velentium Medical’s process for managing cybersecurity risks during the design phase of medical device development. By identifying and mitigating risks at design time, manufacturers avoid embedding vulnerabilities into their systems and ensure compliance with international regulations and standards. This guide explains how design-time risk management works, what artifacts are produced, and how the process aligns with FDA Premarket Guidance, EU MDCG 2019-16/MDCG cybersecurity expectations, AAMI SW96, IEC 62304, IEC 81001-5-1, IEC 60601-4-5, and MITRE EMB3D. SEC-GUIDE-07 describes Velentium Medical’s Total Product Lifecycle Security approach, whereas this document focuses on only the Secure Design and Architecture phase.
2.0 Scope
This guide applies to design-time activities within the Secure Product Development Framework (SPDF). It focuses on:
Defining and reviewing security requirements.
Performing threat modeling and security risk assessments.
Documenting security controls and mapping to standards.
Creating security architecture and use case views that show how risks are managed in the system.
Tracing risks to assessments, controls, and requirements.
The process is intended for medical device manufacturers and engineers who need to demonstrate compliance with FDA, EU, and international cybersecurity expectations.
3.0 Introduction to Design-Time Risk Management
At its core, security risk management follows a simple cycle:
Identify risks – Understand what assets are being protected and what could go wrong.
Assess risks – Evaluate the severity and exploitability of vulnerabilities to understand which risks we should be concerned with and what needs addressed or mitigated.
Manage risks – Apply mitigations, define security requirements, and verify that risks are controlled.
This mirrors the well-established practices of safety risk management but focuses on cybersecurity threats that can impact patient safety, device effectiveness, and data protection. The international standard ANSI/AAMI SW96:2023 provides a structured framework for cybersecurity risk management in medical devices. It requires manufacturers to integrate security into their risk management system, ensuring vulnerabilities are systematically identified, assessed, and mitigated in a way that is traceable and aligned with ISO 14971 safety practices. At design time, this means analyzing risks before a device is built, focusing on vulnerabilities introduced by architecture, design decisions, or integration choices.
The Threat Modeling Manifesto complements this framework by reframing risk management into four guiding questions:
What are we working on? – Define the system and its boundaries.
What could go wrong? – Identify potential threats and vulnerabilities.
What are we going to do about it? – Define mitigations and security controls.
Did we do a good job? – Reassess and update the model as designs evolve.
Both AAMI SW96 and the Threat Modeling Manifesto align to help inform design-time risk management for medical devices, as shown below.
Together, AAMI SW96 and the Threat Modeling Manifesto highlight that security risk management is not a one-time activity. It is a structured, repeatable process that must be woven into the medical device lifecycle. At design time, this process produces tangible outcomes: security requirements, threat models, risk assessments, and defined controls, all aligned with FDA, EU MDCG 2019-16/MDCG 2019-16, IEC 62304, IEC 81001-5-1, and AAMI SW96. AAMI SW96 also defines how a security risk management process must be interconnected but different from a typical safety risk management process per ISO 14971.
4.0 Core Concepts
4.1 Systematic Threat Modeling
Threat Modeling is a process that requires many perspectives, from system engineers to embedded, firmware and software developers, to managers, regulatory, and quality. Therefore, it also requires standardization. A good threat model is simple yet effective and is comprehensive so that we know when we are complete and finished. Data flow diagrams (DFDs) and applying STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to identify potential vulnerabilities is a simple and common approach. Creativity is still required, as is security expertise in the medical domain to ensure a wholistic approach.
4.2 Rigorous, Purpose-Driven Risk Assessment
Velentium Medical scores vulnerabilities with a modified version of CVSSv2 tailored for design time. Different than postmarket scoring, this method emphasizes exploitability and severity while linking to patient safety and device effectiveness with the retention of the Collateral Damage Potential metric.
4.3 Controls and Traceability
Documenting and implementing proper security controls to the levels of detail expected from regulators is crucial, as is testing the effectiveness of those controls. In the US market, the FDA provides eight control categories (e.g., Authentication, Authorization, Cryptography, Integrity) that must be mapped to in controls documentation. Each control must also be traced to vulnerabilities and requirements, meeting FDA and EU MDCG 2019-16 traceability expectations.
4.4 Integration with Global Standards
Velentium Medical’s process includes security activities aligned with IEC 62304 (software lifecycle), IEC 81001-5-1 (secure health software development), and IEC 60601-4-5 (security for medical electrical equipment). The process aligns to global standards, ensures deliverables are submission-ready for FDA and EU MDCG 2019-16, and medical devices are designed and developed with security and patient safety in mind.
5.0 The Design-Time Risk Management Process
Velentium Medical’s process is described at a high level below.
5.1 Define Security Requirements
Every secure product begins with clear requirements. Security requirements are derived from security goals, regulatory expectations, and best practices.
System-level requirements capture high-level expectations (e.g., “All critical operations shall be authenticated and authorized before being performed”).
Product/software-level requirements provide detail (e.g., “The application shall uniquely authenticate all users at the beginning of a session”).
Cross-functional review is essential. Architects, developers, testers, QA, and security experts should all contribute to ensure requirements are realistic, testable, and complete. This step satisfies IEC 81001-5-1 and FDA guidance by embedding security into design inputs. Requirements may need updating following Post-Mitigation Cybersecurity Risk Assessments. See SEC-GUIDE-08 for more information on security requirements and controls.
5.2 Build Data Flow Diagrams (DFDs)
A Data Flow Diagram represents users, processes, data stores, data flows, and trust boundaries. It provides a shared understanding of the system and forms the foundation for identifying vulnerabilities. This step solves the first Threat Modeling Manifesto question – “What are we working on?” – and when paired with additional documentation, creates a shared and easily communicated scope and frame of reference for everyone involved in the threat modeling process. Velentium Medical uses custom templates with the Microsoft Threat Modeling Tool to generate DFDs. Once the DFD is finalized, Velentium Medical uses a custom risk assessment spreadsheet to centralize the remainder of the process into one source of truth, such as threat modeling, security risk assessment, and security control documentation and architecting should all be one interconnected process if done right.
5.3 Identify Design Vulnerabilities with STRIDE
The STRIDE methodology is applied to each element of the DFD. Potential vulnerabilities are listed and reviewed for accuracy, false positives, and relevance to patient safety. This step and the following step together answer the second Threat Modeling Manifesto question – “What could go wrong?” – as well as “How wrong?”.
5.4 Perform Pre-Mitigation Risk Assessment
Each true vulnerability is scored using a modified Common Vulnerability Scoring version 2 (CVSSv2) rubric. This method emphasizes exploitability and severity, with particular attention to patient safety impacts, while considering collective harm to all stakeholders involved in the system.
5.5 Define Security Controls
Mitigations are defined and categorized according to FDA control categories: Authentication; Authorization; Cryptography; Code, Data, and Execution Integrity; Confidentiality; Event Detection and Logging; Resiliency and Recovery; and Firmware and Software Updates. Controls are documented with specific implementation details and mapped back to requirements and vulnerabilities. This ensures consistency with FDA expectations, IEC 81001-5-1, and EU MDCG 2019-16 principles for secure device design. Velentium Medical uses a custom mitigation inventory mapped to IEC 62443-4-2, IEC 62443-3-3, IEC 60601-4-5, and MITRE EMB3D (see SEC-GUIDE-08 for an overview of security requirements and controls and their key differences and considerations). This step addresses the third Threat Modeling Manifesto question – “What are we going to do about it?” The Threat Model is documented in the Threat Modeling and Security Architecture Report.
5.6 Post-Mitigation Risk Assessment
Once controls are defined, vulnerabilities are re-assessed with the controls now considered in a Post-Mitigation Security Risk Assessment using the same scoring rubric as in the Pre-Mitigation assessment to measure residual risk. This answers question #4 from the Threat Modeling Manifesto – “How good of a job did we do?” – and ensures we have defined adequate and appropriate controls and requirements into the system from a design perspective. The Pre-Mitigation and Post-Mitigation Cybersecurity Risk Assessment are summarized in the Cybersecurity Risk Assessment Report.
5.7 Process Threat Modeling
So far, we have only discussed Asset Threat Modeling, focused specifically on the assets in the system and their interconnections from a design and architectural perspective. We must also consider various risks associated with processes related to premarket development and postmarket production and maintenance. At Velentium Medical, we perform Threat Modeling on the following processes:
Supply Chain – Third-party suppliers and vendors and their products present manufacturers with many supply chain risks that must be considered. The OpenSSF S2C2F and the SLSA framework are both great standards for evaluating supply chain risks and implementing appropriate controls into development environments and third-party interactions.
Manufacturing and Deployment – Ensuring software and firmware are transferred to manufacturing and are programmed onto devices going into the field with integrity is crucial for safe and effective operations. Once manufactured, certain systems will have to be provided to customers and integrated within their networks. These activities present unique risks to manufacturers and your customers.
Interoperation – Once systems are deployed and integrated, your devices can become an entry point into a customer network, or the network could contain malicious activity affecting your device. Interoperability risks must be discussed and mitigated.
Maintenance / Update Activities – Updating and patching of software and firmware typically has four fundamental issues that can occur:
Spoofing of the update source – Mitigate by signing all software and firmware and ensuring devices check that an update or patch is coming from a valid source.
Tampering with the update image – Mitigate by ensuring integrity is verified by devices to ensure the image has not been tampered with, similar to the authentication verification discussed above.
Disclosure of the update image – Your intellectual property could be exposed, or your software or firmware could be analyzed to identify other vulnerabilities in your products if you do not protect your updates with encryption independent of communication channel. Devices being updated should decrypt updates only.
Rollback of the software or firmware to an older, insecure version – Mitigate by ensuring metadata protected within the controls above is included with the update image to verify which software and which version the update contains, and then only allow devices to update to newer versions.
Decommissioning (Retirement or EOS/EOL) – Once a customer is done with a product or the product reaches end of support (EOS) or end of life (EOL), devices must be decommissioned of sensitive data including PHI, user credentials, network credentials, etc. Such information must also be communicated to end users in the product labeling.
Process Threat Models are contained in the Threat Modeling and Security Architecture Report.
5.8 Cybersecurity Controls Report
All security controls are documented in detail and mapped to the control categories discussed in Section 5.5. This information is contained in the Cybersecurity Controls Report (see SEC-GUIDE-08 for useful resources and information on cybersecurity controls).
5.9 Security Architecture and Use Case Views
Once the system design and architecture are finalized and sound per the threat model and risk assessment, we now need to document the architecture so that it can be communicated to end users and regulators. Security architecture views illustrate how controls fit into the design. Security use case views highlight critical events (e.g., authentication, software updates, key exchanges) and show how they are protected. Although these are specific artifacts required for FDA submissions, other global markets also require various architectural diagrams for security purposes, and these diagrams are very useful in the product labeling or Instructions for Use (IFU). Architecture views show the security controls implemented in the system overlaid on the architecture (topology) of the system. An example view is provided below.
The FDA requires four types of architecture views:
Global System View
Multi-Patient Harm
Updateability / Patchability View
Security Use Case View(s)
These views are contained in the Threat Modeling and Security Architecture Report.
6.0 Key Deliverables and Artifacts
Design-time risk management produces the following artifacts, each required or strongly recommended by regulators. Recorded review meetings occur throughout this process, and all artifacts are approved and released into the manufacturer’s QMS per roles and responsibilities defined in a Security Risk Management Plan. This plan must also align procedures implemented within the manufacturer’s QMS.
Threat Modeling and Security Architecture Report – contains a summary of the threat models and the security architecture and use case views.
Cybersecurity Risk Assessment Report – contains a summary of the pre-mitigation and post-mitigation cybersecurity risk assessments performed.
Cybersecurity Controls Report – documents the controls and maps them to various standards, including FDA’s Premarket Cybersecurity Guidance Appendix 1 Control Categories.
Integrated security requirements and content within (non-security) system requirements, software specifications, and detailed design documentation.
Although traceability is included in the above deliverables, comprehensive traceability is included in the final report, known as the Security Risk Management Report. Justifications and arguments for residual risks must be included in this report as well, usually focused on a Benefit Risk Assessment per ISO 14971. Ideally, if the above process is implemented early and correctly, then risks can be identified and designed out of the system through robust and state-of-the-art controls and implementations. Together, these deliverables prove compliance with global standards and frameworks. The overall process described above can be easily adopted to fit within most development lifecycles to maximize value ensure patient safety while reducing business risk for medical device manufacturers.
7.0 Best Practices for Manufacturers
8.0 Conclusion
Design-time risk management is the foundation of secure medical device development. By embedding threat modeling, risk assessment, and control definition into design, manufacturers ensure compliance with global regulations and protect patient safety. Velentium Medical’s approach, refined through hundreds of projects since 2017 and backed by a 100% regulatory submission success rate, provides a proven pathway to designing secure, compliant, and resilient medical devices.
9.0 Next Steps
Velentium Medical can help you implement cybersecurity governance within your organization, develop secure products, generate submission-ready artifacts, maintain and sustain medical devices during postmarket, and train your personnel, all based on the latest, state of the art standards and best practices for medical device cybersecurity. We can offer templates and be your guide, we can be your outsourced testing partner, or we can do everything for you with in-house experts and engineers.
Contact us and learn more at http://www.velentiummedical.com/Cybersecurity. Additional Security Guides and other helpful resources are available, and more are forthcoming on related topics.
10.0 References and Resources
ANSI/AAMI SW96:2023 – Standard for medical device security - Security risk management for device manufacturers
EU MDCG 2019-16 – Guidance on Cybersecurity for medical devices
FDA Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (2025)
IEC 60601-4-5 – Medical electrical equipment – Part 4-5: Guidance and interpretation – Safety-related technical security specifications
IEC 62304 – Medical device software – Software life cycle processes
IEC 81001-5-1 – Health software and health IT systems safety, effectiveness and security – Part 5-1: Security – Activities in the product life cycle
Kohnfelder, L., & Garg, P. (1999). The threats to our products. Microsoft Interface, Microsoft Corporation, 33, 1-8.
MDIC Playbook for Threat Modeling Medical Devices (https://mdic.org/resources/playbook-for-threat-modeling-medical-devices/#)
OpenSSF S2C2F (https://openssf.org/projects/s2c2f/)
SLSA Framework (https://slsa.dev/)
The MITRE EMB3D™ Threat Model (https://emb3d.mitre.org/)
Threat Modeling Manifesto (https://www.threatmodelingmanifesto.org/)
Download SEC-GUIDE-10: Design-Time Risk Management for Medical Devices
