Introduction 🔗

FDA’s medical-device cybersecurity expectations changed materially when Congress added section 524B to the FD&C Act in 2022, followed by FDA’s 2023 final guidance, its June 2025 update, and a February 2026 revision aligning the guidance with the Quality Management System Regulation. Cybersecurity is now a core submission workstream for most connected medical devices, not an appendix that can be assembled at the end.

For groups who are less experienced with cybersecurity, the guidance and standards can feel overwhelming. When we translate them into concrete design, documentation, and testing activities, the work is much more manageable; this article collects the practical questions, examples, and recommendations we use with medical-device teams.

If you like this article, you may also be interested in our other “FAQ, Best Practices, and Examples” style articles:

• Medical-Device Software Regulations: Best Practices, FAQs, and Examples
• Design Inputs: Best Practices, FAQs, and Examples
• SBOMs: Best Practices, FAQs, and Examples

If you have medical-device cybersecurity questions that aren’t answered here, feel free to reach out to us in the website chat and we’ll get back to you.

We are a software development and regulatory consulting firm that specializes in SaMD. We help manufacturers with cybersecurity, regulatory strategy and submissions, and provide end-to-end SaMD development.

About the Author 🔗

FAQs 🔗

Basics 🔗

What is cybersecurity? 🔗

With regards to medical devices, the FDA defines cybersecurity as the process of preventing

• unauthorized access,
• modification,
• misuse or denial of use, or
• the unauthorized use of information that is stored, accessed, or transferred from a medical device to an external recipient.

Do all medical devices need to comply with the FDA’s cybersecurity guidance? 🔗

No, but most devices containing software still need a documented applicability assessment. Start by deciding whether the product is a “cyber device”; if it is, section 524B and FDA’s cybersecurity submission expectations apply.

Is our device a “cyber device”? 🔗

Likely yes, if it contains software.

The FD&C Act defines a cyber device as a device that includes sponsor-authorized software, can connect to the internet, and contains technological characteristics that could be vulnerable to cybersecurity threats. FDA’s eSTAR prompts indicate cybersecurity is relevant when a device is cloud-hosted; has an active or inactive network connection; uses wireless communication; has USB, serial, or removable-media interfaces; or supports software updates, including patches.

FDA reads “has the ability to connect to the internet” broadly:

• A USB-only device may still be a cyber device because malicious software could be introduced through the port.
• An offline Docker image may still qualify when it is intended to run in an internet-capable environment.

Our device is genuinely offline—what does a proportionate cybersecurity package look like? 🔗

An air-gapped console or local-only desktop application usually has a smaller attack surface, not a free pass. We still document the device boundary, assets, physical and removable-media interfaces, update path, threat model, SBOM, vulnerability assessment, controls, and testing, but we keep each artifact proportional to the actual risks. The package should explain why cloud, remote-access, and network threats are not applicable and then focus on realistic risks such as malicious media, local privilege escalation, tampered updates, unauthorized physical access, and recovery.

Can we design our device so it isn’t a cyber device? 🔗

Sometimes. You generally must remove—not merely disable—features that make internet connectivity possible, including update, service, removable-media, and deployment pathways that can bridge to connected systems. That can increase installation and maintenance costs, slow security updates, and reduce supportability, so we rarely recommend redesigning solely to avoid the label.

Do we need penetration testing if the device has no network components? 🔗

Usually some independent security testing is still appropriate, although the scope may be much smaller. Testers can assess removable media, file parsers, local privilege boundaries, update packages, malformed inputs, and physical or service interfaces even when there is no network stack. See the Penetration Testing section for how we scope the work.

What cybersecurity documents are required for a 510(k), De Novo, or PMA? 🔗

The same core cybersecurity package is expected for 510(k), De Novo, and PMA submissions, although the depth should scale with the device’s security risk. The list below reflects the current nIVD and IVD eSTAR v7.0 templates as of August 2026. Since v5.5, FDA has updated the templates to align with the June 2025 cybersecurity guidance, the February 2026 QMSR-aligned revision, and current submission structure; the major document categories remain substantially the same.

What cybersecurity activities must be done when creating a medical device? 🔗

The guidance suggests incorporating security into the full development life-cycle. The FDA guidance is written in a somewhat abstract way. Here, I’ll list the key activities as they fall within a typical software development lifecycle process:

• Planning
  • Identify the personnel responsible for security activities
  • Define how the exploitability, severity, and acceptability of security risks will be assessed
  • Identify the methods that will be used to identifying security risks, including at least threat modeling
  • Identify the threat-modeling methodology that will be used
  • Identify any secure coding standards or static code analysis tools that will be used during development
  • Plan for how the development environment will be kept secure (e.g., requiring two-factor authentication in GitHub)
  • Plan for how software updates will be delivered in a timely fashion to the device
• Architecture
  • Document key security views (these will be used in threat modeling)
  • Security risk assessment - given the initial architecture, analyze likely security risks
• Development
  • Implement the security controls that are identified through the security risk assessment
• Labeling
  • Generate an SBOM to be shared with customers (and used to monitor for vulnerabilities)
  • Cybersecurity documentation in labeling
• Design Verification
  • Penetration Testing
  • Vulnerability Testing
  • Verification of all security controls
• Design Validation
  • If applicable, validate that customer IT Staff have sufficient information in labeling to understand their security responsibilities
• Maintenance
  • Reporting security vulnerabilities that are identified
  • Monitoring your SBOM for vulnerabilities
  • On-going vulnerability testing
  • On-going penetration testing
  • Security updates

Drawing the Device Boundary 🔗

Where does the “device” end for cybersecurity purposes? 🔗

This is a complex question, and the answer can have big implications for the effort required for your FDA submission.

Cybersecurity is an area where FDA will look beyond the device boundary to “other functions”. However, our clients often have a core diagnostic AI model surrounded by integrations and other software that can be considered MDDS. If you have this situation, reach out to us and we’d be happy to explore how you can reduce your cybersecurity burden using appropriate strategy here.

Does each component need its own cybersecurity package? 🔗

No. Usually one integrated package can cover a platform and multiple algorithms when they share architecture, controls, deployment, and lifecycle processes. We use common platform documentation plus clear algorithm- or configuration-specific deltas, risks, SBOMs, and verification evidence. Separate packages are cleaner when components have materially different boundaries, intended environments, update mechanisms, or security risk profiles.

Cloud, Deployment, and Change 🔗

How do cloud-hosted and on-premise requirements differ? 🔗

The deliverables are similar, but control ownership changes. In the cloud, the manufacturer usually controls patching and must document the cloud provider’s shared-responsibility model; on premise, hospital IT may control the host OS, network, backups, certificates, and deployment timing, so labeling and customer responsibilities matter more. The threat model and updatability view should show who detects, approves, distributes, installs, and verifies each security update in the actual deployment model.

What changes if we add connectivity later? 🔗

Treat added network or cloud connectivity as a major cybersecurity delta, not a small feature. Revisit cyber-device applicability, the device boundary, architecture and connection inventories, threat model, risk assessment, controls, SBOM, labeling, update plan, and testing scope. If the new connectivity changes safety or effectiveness or introduces significant new risks, also evaluate whether a new premarket submission is required.

Leveraging Existing Security Work 🔗

Does SOC 2, ISO 27001, or HIPAA satisfy FDA requirements? 🔗

No. These frameworks can provide useful evidence, but FDA is focused on product security, while these standards are focused at the organizational level. There’s relatively little overlap in our experience.

Can a vendor’s certification or clearance cover our documentation? 🔗

No, this isn’t possible.

Do older cybersecurity documents need to be redone for a new submission? 🔗

Yes, this is typically required as FDA’s expectations have changed significantly and cybersecurity is continually evolving.

Can we reuse documentation from a previous 510(k) or CE mark? 🔗

Yes. If the 510(k) was after 2023, it will likely cover a lot of what you need. If it is for a CE mark, often there’s still a lot of work left; FDA is stricter when it comes to cybersecurity.

Vulnerability Remediation Before Submission 🔗

Do we have to fix every known vulnerability before submitting? 🔗

No, but every applicable vulnerability needs disposition. We generally expect Critical and uncontrolled High vulnerabilities to be remediated before release; lower-severity findings may remain when exploitability, device impact, compensating controls, and residual risk are documented and acceptable. The medical-device SBOM article explains the supporting vulnerability workflow.

What about vulnerabilities on CISA’s KEV list? 🔗

“Design out” does not mean you can never use a component that has ever appeared in the Known Exploited Vulnerabilities catalog. It means the released device should not contain an applicable, exploitable KEV vulnerability: use a fixed version, remove the vulnerable function, or implement and verify controls that make the vulnerability inapplicable or unexploitable. Because KEV entries are known to be exploited in the wild, we treat unresolved applicability as a release blocker unless there is unusually strong evidence and risk justification.

What if we cannot patch a legacy component? 🔗

Document why replacement is infeasible, then use compensating controls such as isolation, allowlists, disabling services, least privilege, monitoring, authenticated updates, and restricted physical access. Verify those controls and provide a realistic support, communication, and migration plan. Legacy technology can sink a submission when it creates an uncontrolled risk, lacks a credible maintenance path, or depends on assumptions that the intended environment cannot reliably enforce.

Timing and FDA Interactions 🔗

How much work is needed before a clinical study or IDE? 🔗

The cybersecurity package may be less polished than at marketing submission, but the study device still needs controls proportionate to participant and data risk. Before an IDE or significant clinical deployment, we want a defined boundary and architecture, an initial threat and risk assessment, implemented critical controls, a current SBOM, a vulnerability review, secure update and incident-response plans, and testing of the study configuration. Do not postpone a safety-relevant security issue merely because the product is investigational.

How do we respond to cybersecurity deficiencies in an Additional Information letter? 🔗

First identify the concern behind each question—often missing evidence, weak traceability, an uncontrolled risk, or reviewer doubt about a design assumption—then respond to that concern rather than only the literal wording. Use the 180-day window to prioritize architecture and risk decisions, ask FDA focused clarification questions early when expectations are subjective, implement the minimum defensible remediation, and produce consistent revised documents and evidence. Avoid promising a broad redesign before determining whether better analysis, testing, labeling, or a narrower verified control resolves the issue.

Security Risk Management 🔗

What is security risk management? 🔗

Security risk management is the process of identifying cybersecurity threats and vulnerabilities, estimating their exploitability and impact, implementing controls, and deciding whether the residual risk is acceptable. Unlike ordinary reliability analysis, it assumes an intelligent threat actor may deliberately create the sequence of events, so we assess exploitability rather than probability of random failure. The output should trace threats and vulnerabilities through risks, controls, verification, and residual-risk decisions across the product lifecycle.

How is security risk management related to safety risk management? 🔗

Safety risk management focuses on harm to patients and users, while security risk management also considers harm to data, operations, privacy, and other assets. Security risks sometimes lead to safety risks, but many do not. We keep the processes separate, parallel, and interconnected so cybersecurity threats that could create patient harm trace into the ISO 14971 safety risk-management file.

Is it okay to incorporate security risk management into safety risk management? 🔗

No. Previously, FDA had been more open to combining the two processes and we’d suggested (for simple devices) that our clients keep them combined. FDA has been clear in their 2023 guidance and in their newest eSTAR templates that the two processes need to be separate:

How should security risks be assessed? 🔗

We generally do not use CVSS out of the box: it is useful for characterizing technical vulnerabilities, but it is too complicated and not sufficiently device-specific to serve as the entire security risk method. Instead, we define an exploitability scale—not a probability-of-failure scale—and combine it with security-impact severity in a documented acceptability matrix. The definitions and thresholds should fit the device, intended environment, assets, and potential safety impacts, and every pre- and post-control rating should be justified. A complete example appears with the worked threat model below.

Security Architecture Views 🔗

What are security architecture views? 🔗

These are diagrams that show the components of the medical device system and the interfaces between these elements.

We use these diagrams as an input to the threat modeling, along with an asset inventory and connection inventory.

What is an asset in this context? 🔗

FDA defines an “asset” as “anything that has value to an individual or an organization.” This is a very broad definition. In the context of threat modeling, we primarily consider the assets called out in Appendix B of the FDA Guidance:

• Device hardware itself (including assessments for any commercial platforms)
• Applications, hardware, and/or other supporting assets that directly interact with the targeted device, such as configuration, installation/upgrade, and data transfer applications
• Healthcare facility-operated assets
• Communications/networking assets, and
• Manufacturer-controlled assets, including any servers that interact with external entities (e.g., a service that collects and redistributes device data, or a firmware update server).

More broadly speaking assets could include things like reports, images, PHI, databases, user account information, log files, security keys, backups, source code, configuration files, update files, network communication, intellectual property, or company reputation.

What is an asset inventory? 🔗

An asset inventory is a table or list of all of the assets, or system items, that make up your medical device system, along with relevant properties of those assets. It is important to have an asset inventory because there is too much information to show it all in the diagrams. We thus put most of the information in the asset inventory and include a unique ID for each asset. We then refer to these IDs within the diagrams.

What is a connection inventory? 🔗

A connection inventory is similar to the asset inventory, but its for the connections between the assets. Just as with assets, we use IDs for each connection.

Note that the uses the term “electronic interface”, while in the cybersecurity guidance uses the term “communication pathway.” The two terms are very similar, we therefore attempt to capture the required information for both in a single table.

What information do you need to capture regarding connections? 🔗

The information captured here is meant to cover the requirements in Appendix 2 (B) of the FDA Guidance as well as the interoperability questions for “electronic interfaces” in the eSTAR.

The list is quite long, and many items don’t apply in all cases. Furthermore, FDA does not typically require all of this detail, thus, we focus on including the information that we feel is useful for threat modeling.

Here’s how we like to organize the requirements from the FDA guidance into multiple properties:

• ID
  • This is a unique ID for the connection.
  • It’s used to precisely link diagram elements (or explanatory text), associated hazards and controls, and testing;
• Inactive?
  • Yes/No. This is for the Interoperability eSTAR questions.
  • Is the electronic interface inactive (i.e. not meant to connect, exchange, or use data with or
    from other medical devices, products, technologies, or systems)?
• Support?
  • Yes/No. This is for the Interoperability eSTAR questions.
  • Are the interfaces only meant for service or maintenance?
• MDDS?
  • Yes/No. This is for the Interoperability eSTAR questions.
  • Is the data flow only meant for transferring, storing, converting formats, or displaying clinical
    laboratory test and not intended to interpret or analyze clinical laboratory test or other device
    data, results, and findings?
• Description
  • An indication of whether the path is used for data, code, and/or commands, and type of data/information/code being transferred;
  • Detailed descriptions of the primary and all available functionality for each medical device system asset, including assessment of any functionality that is built in but not currently used or enabled (e.g., dormant application functionality or ports), including assurance that this functionality cannot be activated and/or misused;
  • Explanations of intended behavior in unusual/erroneous/unexpected circumstances (e.g., termination of a connection in the middle of a data transfer);
  • (Rare) Explanations or links to the evidence that may be used to justify security claims and any assumptions; and
• Authentication
  • Authentication mechanism (if any), including the algorithm name/version (if available), “strength” indicators (e.g., key bit length, number of computational rounds) and mode of operation (if applicable);
  • Descriptions of the cryptographic method used and the type and level of cryptographic key usage and their style of use throughout the medical device system (e.g., one-time use, key length, the standard employed, symmetric or otherwise). Descriptions should also include details of cryptographic protection for firmware and software updates;
  • For each authenticator created, a list of where it is verified, and how verification credentials (e.g., certificates, asymmetric keys, or shared keys) are distributed to both endpoints;
  • A precise, detailed list of how each type of credential (e.g., password, key) is generated, stored, configured, transferred, and maintained, including both manufacturer- and healthcare facility-controlled assets (e.g., key management and public key infrastructure (PKI));
• Authorization
  • Access control models or features (if any) for every asset (such as privileges, user accounts/groups, passwords);
  • Users’ roles and levels of responsibility if they interact with the assets and communication channels;
  • Identity management (if any), including how identities are managed/transferred and configured (e.g., from manufacturer to programmer and from programmer to device);
  • (Rare) Include any security configuration settings and their default values;
  • (Rare) Detailed analyses by cryptography experts if a cryptography algorithm is proprietary, or a proprietary modification of a standard algorithm;
• Communication Protocol
  • Protocol name(s), version number(s), and ports/channels/frequencies;
  • Any “handoff” sequences from one communication path to another (e.g., from asset to asset, network to network, or Bluetooth to Wi-Fi), and how the data, code, and/or commands are secured/protected during handoff (i.e., how is their integrity/authenticity assured);
  • If communication sessions are used or supported, a detailed explanation of how sessions are established, maintained, and broken down, including but not limited to assurances of security properties such as uniqueness, unpredictability, time-stamping, and verification of session identifiers;

The examples section shows a filled in table.

Should you include all internal connections in your connection inventory? 🔗

We don’t always show internal communication if it doesn’t feel useful for the threat model.

What is a global system view? 🔗

A global system view should describe the overall medical device system, including the device itself and all internal and external connections. For interconnected and networked devices, this view should identify all interconnected elements, including any software update infrastructure(s), healthcare facility network impacts, intermediary connections or devices, cloud connections, patient home network impact.

What is a multi-patient harm view? 🔗

The concept of “multi-patient harm” is introduced in the 2023 FDA Cybersecurity Guidance.

When devices are capable of connecting (wired or wirelessly) to another medical or non-medical product, to a network, or to the Internet, there is the possibility that multiple devices can be compromised simultaneously. Because of that connectivity, if a device is compromised, the device may introduce a safety risk to patients through security risk.

We’ve generally restricted “multi-patient harm” to mean a cybersecurity incident where multiple patients are harmed “simultaneously or in rapid succession”.

A multi-patient harm view demonstrates what security controls are in place to protect against multi-patient harm. E.g., it could be a sequence diagram showing the relevant connections and the location of controls.

What are some examples of multi-patient harm? 🔗

These examples are somewhat simplified, so they don’t provide all the details needed to make a firm conclusion either way. Still, I hope they’re helpful:

Cloud-Based Semi-Automated Diagnostic Radiology SaMD - This software is unlikely to cause multi-patient harm. The software does not directly interact with patients in anyway. It also isn’t on a network with other devices that directly interact with patients. Radiologists interact with the software to produce its outputs in a semi-automated way. This human-in-the loop slows down the effects of most exploits. Even if the software were fully automated or an exploit could modify the reports, there are still other clinicians downstream from the radiology report who introduce checks and delays. Thus, there wouldn’t be feasible for patients to be harmed simultaneous or in rapid succession.

Multiparameter Bedside Monitors - This example is taken from the FDA guidance. Multiparameter bedside monitors would be capable of causing multi-patient harm. They aren’t able to directly harm the patient, however, a cybersecurity attack could restart all of the monitors at once. This would leave all monitors connected to the same network no longer monitoring patient vitals and it is quite possible there wouldn’t be enough staff to monitor all patient vitals.

What is an updatability and patchability view? 🔗

An updatability and patchability view is a diagram that shows how software updates are delivered to the various parts of the system.

We usually use sequence diagrams.

What are security use case views? 🔗

Security use case views demonstrate the behavior of your system in sequence diagrams. Here are some examples of possible use cases:

• Typical clinical workflows
• Various installations or configurations (e.g., if you support on-prem or cloud installations)
• Different authentication schemes (e.g., if you support SSO for some clients)

The number and detail of your use case views depends on the security risk of your device.

Here is an example security use case view:

sequenceDiagram
autoNumber
participant si-1 as DICOM Router (SI-1)
participant si-2 as Local Node (SI-2)
participant si-3 as Database (SI-3)
participant si-4 as Processing Module (SI-4)
participant si-5 as AWS S3 Storage (SI-5)
participant si-6 as Logs (SI-6)
si-1->>si-2: Transfers DICOM MRI Sequence to [INT-1]
si-2->>si-2: Anonymizes data
si-2->>si-3: Saves task information in [INT-3]
si-2->>si-4: Transfers anonymized data to [INT-2]
si-4->>si-6: Logs job start in [INT-5]
si-4->>si-5: Saves copy of data in [INT-4]
si-4->>si-4: Runs AI model
si-4->>si-6: Logs job finish in [INT-5]
si-4->>si-2: Sends results back to [INT-2]
si-2->>si-3: Retrieves patient identifiers from [INT-3]
si-2->>si-2: Re-identifies data and generate report
si-2->>si-1: Sends report to PACS [INT-1]

What are best practices for creating use-case views? 🔗

• Use IDs (e.g., SI-2) to unambiguously identify your system items with other diagrams documentation.
• Use connection Ids (e.g., INT-2).
• Write each arrow’s label so that it reads like a sentence when combined with the origin and destination. E.g., the first arrow can be read as “DICOM Router Transfers DICOM MRI Sequence to Local Node”.
• Don’t try to include every possible detail; only include details that are useful for helping with the threat model.
• If you exclude certain details consistently (e.g., only showing HTTP requests but not responses) note this in the document.
• Split up diagrams if there is a lot of repeat steps across different diagrams.

Threat Modeling 🔗

Do I need to create a threat model? 🔗

Yes, if your device is a cyber device, you will need to create a threat model for your FDA submission. See the threat modeling section of the 2023 cybersecurity guidance.

What is a threat? 🔗

The FDA defines a threat as follows:

“A threat is any circumstance or event with the potential to adversely impact the device, organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, or other organizations through an information system via

• unauthorized access,
• destruction,
• disclosure,
• modification of information,
• and/or denial of service.”

What is threat modeling? 🔗

The FDA’s 2023 cybersecurity guidance defines threat modeling as follows:

“Threat modeling is a methodology for optimizing system, product, network, application, and connection security by identifying objectives and vulnerabilities, and then defining countermeasures to prevent, or mitigate the effects of, threats to the system.”

(Note that the 2016 post-market guidance has a slightly different definition.)

The output of the threat modeling process is a threat model.

What is typically included in a threat model? 🔗

There are many different ways of organizing and structuring threat models. Many of the approaches come from other industries. Here is the content we typically in include in our threat models which standardizes on the terminology found in the FDA guidance:

• Scope of the threat model
  • Rationale for the approach used
  • Who was involved in the threat modeling
  • Assumptions about the system and environment of use
• An inventory of security assets
• An inventory of connections
• An inventory of expected threat sources
• Architectural diagrams including
  • The key modules and layers of your device
  • All external systems
  • Their connections
  • The process by which software updates go from source code to deployment
• An analysis of the main threats (often enumerated following a few methodologies, such as STRIDE)
• A listing of the implemented mitigations

There’s not a standard format for threat models. We will provide examples of how we format our threat models below.

What should be the scope of the threat model? 🔗

The FDA emphasizes that threat modeling must account for the entire operating environment of the device. This raises a critical question: How extensively should we consider the surroundings of the medical device? It is not always an easy question:

• For devices sold to multiple institutions, the potential scenarios are only limited by your imagination.
• For devices used within a specific lab or institution, you may wonder how far into the surrounding IT infrastructure you need to go.

We haven’t found any heuristics to offer to answer this question, but in general we are guided by the exploitability and severity of the security risks.

Which threat modeling methodologies do you suggest using? 🔗

The FDA says the “rationale for the methodology(ies) selected should be provided with the threat modeling documentation.”

We suggest following the STRIDE or STRIDE and Attack Trees method for doing threat modeling. This is because the FDA-sponsored Threat Modeling Handbook mentions these methodologies, and thus, when justifying the threat-modeling methodology in your security management plan (which the FDA requires you to do), you can say that these were the methods suggested in the FDA's Threat Modeling Handbook.

How do you create a threat model? 🔗

Here is an example procedure to follow to create a threat model for an FDA submission using the STRIDE methodology.

1. Identify all major system items
   • Unless your system is very simple, you often need to make judgement calls regarding what level of detail to decompose your system into. Too much detail isn’t useful.
   • Threat models should encompass the full end-to-end system the device operates within, not just the device itself.
   • We recommend labeling each system item (e.g., SI-1, SI-2).
   • Examples: Backend Django App, AWS S3 Bucket, PACS, PostgreSQL Database, etc.
2. Create a system diagram, including connection
   • These diagrams should show all the connections to external systems or networks.
   • We recommend labeling each system item and connection within these diagrams.
   • Create the security architecture diagrams described in the FDA guidance:
     • Global System Views
     • Multi-Patient Harm View (when applicable)
     • Updatability and Patchability View
     • Security Use Case Views (often multiple)
3. Identify and assess cybersecurity assets
   • Assets can be concrete or intangible; examples include PHI, databases, logs, credentials, configuration files, source code, access to connected systems, and business reputation.
   • We generally will indicate which system items the assets are stored within (sometimes the system items are themselves the assets).
   • Once the assets are identified, we analyze the impact of the loss of confidentiality, integrity, and availability of these assets.
4. List threats for each system item using STRIDE
   • Iterate through each system item and connection, reviewing the system diagrams as you go, and consider threat types according to STRIDE (Spoofing, Tampering, Repudiation, Info Disclosure, DDoS, Elevation of Privileges).
   • We follow STRIDE-per-element as described in Adam Shostack’s book
   • Write down these threats.
   • See and for more examples.
5. Eliminate or refine threats that are highly improbable or impossible to verify
   • If it is likely to impact patient safety, keep it.
   • If it is unlikely to impact patient safety and is difficult to verify, consider removing it.
   • If you’ve already mitigated it and it is easy to verify, keep it.
6. Trace threats to security risks and their mitigations
   • Example:
     • For the threat/mitigation pair
       • Threat: Malicious actor brute forces the clinician’s username and password.
       • Mitigation: Temporarily block login after 5 incorrect attempts.
     • You might have to create a new requirement to implement the threat mitigation
       • REQ-035: Throttle User Authentication
     • And add a new risk to cover the threat
       • SRSK-025: Brute Force Attack

Can you give examples of threats for each STRIDE category? 🔗

• Spoofing: Pretending to be something or someone you’re not.
  • Heuristic: What could a threat actor do if they pretended to be this element of the system?
  • Example:
    • Threat: Malicious actor brute forces the clinician’s username and password.
    • Mitigation: Temporarily block login after 5 incorrect attempts.
• Tampering: Changing something in a malicious way (on the disk, db)
  • Heuristic: What ways could a threat actor tamper with code or data in this element?
  • Example:
    • Threat: Malicious actor modifies PostgreSQL Database via SQL injection.
    • Mitigation: Implement input validation on frontend and backend.
  • Real Insulin Pump Example:
    • Background: This example is taken from the first FDA recall due to cybersecurity.
    • Threat: Due to a software vulnerability, threat actors could remotely tamper with the insulin pump’s configuration via wifi.
    • Mitigation: Ensure all connections to the software are properly authenticated.
• Repudiation: Doing something bad and claiming to not have done it
  • Heuristic: What actions could this element do that we want to be sure we log?
  • Example:
    • Threat: Malicious actor denies that a certain treatment has been prescribed.
    • Mitigation: Track all prescription actions in centralized logging system.
  • Drug Dispenser Example:
    • Threat: A IT-person steals an opioid from a drug dispenser and modifies the logs to remove a trail of them having done so.
    • Mitigation: Log important events and secure and back up the logs.
  • Malpractice Example:
    • Threat: A clinician makes a medical mistake; they’re worried about a lawsuit and try to cover up the mistake.
    • Mitigation: Log important events and secure and back up the logs.
• Information Disclosure: Having sensitive data leaked
  • Heuristic: What are mechanisms through which data in this element could be leaked?
  • Example:
    • Threat: Malicious actor performs man-in-the-middle attack and steals data.
    • Mitigation: Use encryption in transit (HTTPS).
• Denial of Service: Removing availability of the system
  • Heuristic: What could a threat actor do to make this element no longer available?
  • Example:
    • Threat: Malicious actor overwhelms backend with abnormal traffic.
    • Mitigation: Configure AWS Web Application Firewall for common exploits.
  • Malware Example:
    • Background: This is one of the most common and pervasive threats to the HDOs.
• Elevation of Privileges: Gaining unauthorized access
  • Heuristic: What levels of authorization exist on this device? If multiple, how could an actor elevate their level?
  • Example:
    • Threat: Malicious user changes their role to admin via API.
    • Mitigation: Only allow admins to change user roles and enforce this.

Why do you need to trace the threats to security risks? 🔗

The main benefit of threat modeling is that it is a structured process. For example, if you’re following STRIDE, you’d analyze all six types of threats to each component of the system. By systematically analyzing each component, you can be sure you didn’t miss anything. Also, by recording this analysis, engineers working on future updates to the project will understand the thought process that was used.

The security risks, on the other hand, are typically higher level. You’ll have more entries in a STRIDE threat model table than you will in your security risks. (This is similar to how an FMEA will analyze each component of the system for failure modes, and will often have more detail than the corresponding safety risks.) That said, FDA says clearly in their guidance that the threat model must “identify medical device system risks and mitigations as well as inform the pre- and post-mitigation risks considered as part of the cybersecurity risk assessment.” We take this to mean the identified threats should trace to the higher level risks, their pre- and post-mitigation impacts and likelihood levels.

When should threat modeling be done? 🔗

We create the first threat model as soon as the architecture and external interfaces are stable enough to analyze, while there is still time to change the design. We revisit it before design verification, before submission, and whenever a release changes the architecture, data flows, deployment, interfaces, or security assumptions. Postmarket review should also be triggered by new vulnerabilities and incidents rather than occurring only on a calendar.

Who should create the threat model? 🔗

Software engineers who are familiar with the system should be able to perform the threat modeling, although having a cybersecurity SME involved in the process is very helpful.

Unlike with penetration testing, where we do suggest using an external firm, we don’t typically suggest having an outside firm independently put together a threat model. This is because the security risks are tightly integrated with design controls and safety risk management, and thus an external group will typically have a hard time incorporating their findings into the rest of the documentation unless they’re working closely with your team.

Having a security expert who knows the current threat landscape for your intended use environment is also helpful.

How is threat modeling related to security risk management? 🔗

The distinction between threat modeling and security risk management is vague. We suspect this is because threat modeling was developed outside the medical device industry and had its own terminology developed apart from of ISO 14971. In any event, it is straightforward to map the components of the Threat Modeling Manifesto to the AAMI TIR57 security risk management activities, as shown in the following diagram.

If we were to make a distinction, we would say that “threat modeling is a loose collection of methodologies used to systematically identify, mitigate, and document security risks.”

According to this distinction, threat modeling is to security risk management as FMEA is to safety risk management. FMEA is a structured way of identifying safety risks related to parts of your system breaking down. Unlike FMEA, which is rarely sufficient to identify all of the safety risks for a device because it misses process- and usability-related risks, threat modeling is in theory sufficient on its own. Thus, even this attempt at a distinction isn’t very useful.

What other resources exist for threat models? 🔗

Here are several articles:

• Promenade’s guide to their hybrid asset and vulnerability based threat modeling
• Adam Shostack’s Threat Modeling Book
• Threat Modeling Manifesto
• OWASP Threat Modeling Cheat Sheet
• The Ultimate List of STRIDE Threat Examples
• MITRE’s “Playbook for Threat Modeling Medical Devices”
  • This 2021 playbook predates section 524B and FDA’s 2023–2026 premarket guidance, so it does not cover the current statutory submission elements, eSTAR structure, or newer expectations for architecture views, SBOM support, vulnerability management, and total-product-lifecycle documentation. Its threat-modeling techniques remain useful, but use current FDA guidance for regulatory completeness.

Here are a few tools that are widely used:

• Microsoft Threat Modeling Tool (uses STRIDE per Element; Windows Only)
• OWASP Threat Dragon (more flexible; doesn’t generate threats; multi-platform)

Cybersecurity Testing Overview 🔗

What types of cybersecurity testing does FDA require? 🔗

FDA suggests considering the following four types of cybersecurity testing:

Vulnerability Testing 🔗

What is Vulnerability Testing? 🔗

Vulnerability testing is a type of cybersecurity testing that focuses on identifying and characterizing security vulnerabilities. A vulnerability is a “a weakness in an information system, system security procedure(s), internal control(s), human behavior, or implementation that could be exploited.”

Do all cyber devices need vulnerability testing? 🔗

Yes! Unlike some of the other cybersecurity testing activities, the need for vulnerability testing is actually included in the legal statute itself, which says cyber devices must:

What are some specific types of vulnerability testing we should do? 🔗

In the 2023 FDA guidance, the following types of testing are suggested for consideration:

How should we document the results of our Vulnerability Testing? 🔗

Per the FDA guidance, for any testing tools or software used, the details provided may include, but may not be limited to, the name of the tool, version information as applicable, and any settings or configuration options for the tools used.

Fuzz Testing 🔗

What is fuzz testing? 🔗

Fuzz testing, also sometimes called fuzzing, is a particular type of vulnerability testing technique. Simply put, it involves feeding randomized inputs to the software and seeing if anything breaks.

Do we have to do fuzz testing? 🔗

FDA recommends that “fuzz testing” be considered for submission in their 2023 FDA Guidance. We’ve had mixed luck pushing back on the need for fuzz testing with FDA. In several submissions, FDA has accepted that fuzz testing was not suitable. On others, FDA has held their ground.

Traditionally, fuzz testing has focused on languages like C or C++ which are compiled and prone to memory errors, however, fuzzing can be applied to software built with interpreted languages such as JavaScript and Python too.

What attack surface should we use for our fuzz testing? 🔗

There are several different “attack surfaces” that could be fuzz-tested. At the lowest level, you can fuzz test your individual functions or classes. With regards to cybersecurity fuzz testing, the external interface of your device is most appropriate.

See Part 1 section 15 of UL-2900 Software Cybersecurity for Network-Connectable Products for some more structured details about “malformed input testing” (of which fuzz testing is a type). It says “The product shall continue to operate as intended when subject to invalid or unexpected inputs on its external interfaces.”

How much fuzz testing is enough? 🔗

Since fuzz testing involves feeding random inputs into an interface or API, there is always the question of “how much is enough”? There’s no clear answer here, but this is something your test reports that will be in your 510(k) submission would ideally address.

The UL-2900 standard says:

This may be a good starting place.

Can we rely on the fuzzing our pen tester did? 🔗

External pen testers may perform fuzz testing as part of their pen testing suite. If they do, you may be able to “take credit” for the fuzz testing they already did. If you plan ahead for this, it would be good to have information about the interfaces they tested, how long they fuzzed, and how many inputs they fed into the tests in the final report they produce.

Where can I learn more about Fuzzing? 🔗

Here are some good resources:

• Section 15 of the UL-2900-1 standard (costs money to purchase) has some requirements that may help build out a structure for a fuzz testing procedure.
• This Synopsys article has a great technical intro to fuzz testing.
• This OWASP page is semi-useful and has some links.

Penetration Testing 🔗

What is penetration testing? 🔗

Penetration testing, often shortened to “pentesting,” is an authorized simulated attack on the medical-device system. Testers use attacker techniques to discover and exploit weaknesses and demonstrate their practical impact. We use the longer term in submission documents because it matches FDA’s terminology.

Innolitics performs penetration testing for medical-device software. We define an FDA-appropriate scope, conduct the testing, document the findings, support remediation, retest the fixes, and produce a submission-ready report. For specialized hardware, radio, or on-site testing, we can coordinate with a qualified partner lab while remaining responsible for integrating the results into the cybersecurity package.

How is penetration testing different from vulnerability testing? 🔗

Vulnerability testing focuses on identifying and characterizing vulnerabilities. Penetration testing involves trying to discover and exploit vulnerabilities and other weaknesses in the system. Thus, vulnerability testing will stop once the vulnerabilities are identified. Penetration testing will take the next step and will try to actually exploit the vulnerability.

Thus, penetration testing has fewer false positives than vulnerability testing, which often finds many vulnerabilities that can’t actually be exploited in practice.

Do all cyber devices need penetration testing? 🔗

Most, but not all. Unlike other regulatory requirements, such as including an SBOM, FDA doesn’t require penetration testing in every case.

In most cases we strongly suggest doing pen-testing.

We usually include pen testing in our submissions, but we have had a couple of devices with very limited threat surfaces get FDA-cleared without pen testing.

Can we do the penetration testing ourselves? 🔗

FDA suggests that the penetration testing have a level of independence from the team that developed the software. The best way to accomplish this is to use a separate firm.

We have had a few clients successfully use someone else on their team to do pen-testing, however it is important that:

1. The person was not involved in the development of the application
2. The person has credentials and certifications for doing pen-testing

FDA will almost certainly not allow an engineer who helped develop the device do the testing. They also won’t be content with someone who just picked up some pen-testing tools online and ran them against the software.

How do you scope penetration testing? 🔗

Here are some questions to ask yourself about this:

• What connections are being tested? E.g., will you be testing blue-tooth connections, USB ports, cloud infrastructure, your servers, etc.
• Will you pen-test the device’s update process?
• For SiMD, will you need to ship the device to the client or will the pen-testers need to fly on site?
• How much information about the device will you share with the pen-testers? Will it be black-box, gray-box, or white-box testing?
• Will you want the vendor to re-run the pen-tests after your team has had a chance to address issues?

How should we evaluate vendors to do our penetration testing? 🔗

Once you’ve identified the scope of your pen testing, you can share this with vendors to see if they’re a good fit and if they’ll provide you a quote.

Here are some questions you may want to ask:

• If you have SaMD, make sure they do application penetration testing (and not network IT infrastructure pen testing).
• If you have a physical device, make sure they do device penetration testing.
• How much lead time do you need before you can do pen testing?
  • This is important, since ideally you’ll do pen testing just before your submission and you don’t want a big delay to be a bottleneck.
• Can you provide us a sample report?
  • You will want to check that the testing report will include the following elements required by FDA:
    • Independence and technical expertise of testers;
    • Scope of testing;
    • Duration of testing;
    • Testing methods employed; and
    • Test results, findings, and observations.
• Do you have discounts for doing repeated tests?
  • Keep in mind you’ll likely be repeating the penetrating testing (e.g., annually), so it’s often helpful to have a single vendor you use.

Should I select pen-testers that focus on medical devices? 🔗

Medical-device experience is helpful when the tester must understand clinical workflows, device hardware, or FDA reporting expectations, but it is not mandatory for every engagement. We care more about relevant technical depth, independence, a defensible methodology, and a report that clearly documents scope, duration, methods, findings, and retesting.

What is the penetration-testing process? 🔗

We define the production-representative target, test accounts, interfaces, exclusions, rules of engagement, and reporting requirements before testing begins. The tester performs reconnaissance, vulnerability discovery, controlled exploitation, impact analysis, and reporting; the manufacturer then feeds applicable findings into risk management and remediation. Plan for access troubleshooting and a retest window instead of treating the report date as the finish line.

How should we retest findings? 🔗

Retest the same production-representative configuration after fixes are implemented, and give the tester enough evidence to reproduce the original issue. The final record should identify each finding as fixed, partially fixed, accepted, or not reproducible and should describe any material scope limitations. If remediation changes architecture or introduces new attack surface, targeted regression testing may be insufficient and a broader test may be warranted.

Do all penetration-test findings need to be fixed? 🔗

No, but every finding must be assessed and dispositioned. We remediate findings that create unacceptable risk and may accept lower-risk findings when exploitability, impact, compensating controls, and residual risk are justified. “Informational” does not automatically mean irrelevant, and an accepted finding still belongs in the traceability and unresolved-anomaly records when applicable.

How much does penetration testing cost? 🔗

As of 2026, a focused web-application penetration test commonly costs about $5,000–$30,000, with API, mobile, cloud, hardware, radio, and on-site components increasing the price. Complex multi-component medical-device engagements can exceed $100,000, especially when they include travel, specialized equipment, source review, multiple roles or tenants, and retesting. Scope and tester quality matter more than the headline quote; very low bids are often automated vulnerability scans rather than true penetration tests.

How long does penetration testing take? 🔗

The actual pen testing process is typically two weeks. For simple systems, some vendors can shorten the process to a week.

Also be sure to account for lead times. Some vendors, especially more specialized ones, can have long lead times.

When should we do our penetration testing for a premarket submission? 🔗

Ideally, your penetrating testing will be done on the final version of the software that you’re submitting to FDA. This is because FDA recognizes that the results of penetration testing degrade over time. FDA will likely accept pen-tests that have been completed within a year of the submission, however, older than that likely will not be acceptable. Furthermore, you’ll need to justify why any changes that have been made to the software between the pen test and the submission don’t affect the cybersecurity. E.g., if you change how authentication is processed or add new user roles, you would likely need to do another round of pen-testing.

How often should we do penetrating testing? 🔗

We suggest documenting in your Security Management Plan when and how often you plan to do penetration testing. In the FDA guidance, they suggest repeating it periodically:

We generally suggest that if you need penetrating testing that you repeat it annually. That said, this would most likely be a finding in an audit, and wouldn’t affect your pre-market submissions.

How to Learn More 🔗

What FDA guidance applies to medical-device cybersecurity? 🔗

Start with FDA’s current Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. FDA issued the major section 524B update in June 2025—what many teams call “the 2025 guidance”—and revised it in February 2026 to align terminology with the QMSR; the 2026 version supersedes the 2025 and 2023 versions.

The 2016 Postmarket Management of Cybersecurity in Medical Devices guidance remains useful for postmarket vulnerability assessment and coordinated disclosure. The older 2005 OTS cybersecurity guidance is largely historical and has been overtaken by newer premarket and postmarket recommendations, so we do not use it as a primary planning document.

What standards apply to medical-device cybersecurity? 🔗

The FDA has recognized several standards (search the FDA database using the “security” keyword and you can see most of them). Of all of these, we feel that IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security — Part 5-1: Security — Activities in the product life cycle is the most important. It defines the activities you need to follow to build a secure device, similar to how IEC 62304 defines the activities you need to follow to build a safe device. The FDA suggests following a standard such as this in their 2023 guidance.

Examples 🔗

Threat Model of a Common Radiology AI Deployment 🔗

Overview 🔗

This example is of a common architecture we see with our AI-enabled radiology software clients. It involves two primary software components. One sits within the hospitals network and is responsible for receiving medical images, anonymizing them, and forwarding them along to the cloud for processing. The cloud component processes the data, stores a copy online for the company to review and assess, and sends the results back to the local node. There, the local node generates a report

Asset Inventory 🔗

Connection Inventory 🔗

Global System View 🔗

Note that we show the IDs for the System Items (i.e., Assets) in the diagram as well as the connection IDs. These IDs can then be traced to documentation that contains more information that could fit on the diagram. We like to show a high-level description of the assets in each node. We also like to display the protocol of each connection.

Security Use Case View 🔗

sequenceDiagram
autoNumber
participant si-1 as DICOM Router (SI-1)
participant si-2 as Local Node (SI-2)
participant si-3 as Processing Module (SI-3)
participant si-4 as AWS S3 Storage (SI-4)
participant si-5 as Logs (SI-5)
participant si-6 as Destination PACS (SI-6)
si-1->>si-2: Transfers DICOM CT Study to [INT-1]
si-2->>si-2: Anonymizes data
si-2->>si-2: Saves task information to database
si-2->>si-3: Transfers anonymized data to [INT-2]
si-3->>si-5: Logs job start in [INT-4]
si-3->>si-4: Saves copy of data in [INT-3]
si-3->>si-3: Runs AI model
si-3->>si-5: Logs job finish in [INT-4]
si-3->>si-2: Sends results back to [INT-2]
si-2->>si-2: Re-identifies data and generate report
si-2->>si-6: Sends report to PACS [INT-5]

To create these sequence diagrams, I like to use mermaid. Our Medtech OS platform supports this out of the box, but you can also use their online tool tool. Here is the mermaid text that created the above diagram:

sequenceDiagram
autoNumber
participant si-1 as DICOM Router (SI-1)
participant si-2 as Local Node (SI-2)
participant si-3 as Processing Module (SI-3)
participant si-4 as AWS S3 Storage (SI-4)
participant si-5 as Logs (SI-5)
participant si-6 as Destination PACS (SI-6)
si-1->>si-2: Transfers DICOM CT Study to [INT-1]
si-2->>si-2: Anonymizes data
si-2->>si-2: Saves task information to database
si-2->>si-3: Transfers anonymized data to [INT-2]
si-3->>si-5: Logs job start in [INT-4]
si-3->>si-4: Saves copy of data in [INT-3]
si-3->>si-3: Runs AI model
si-3->>si-5: Logs job finish in [INT-4]
si-3->>si-2: Sends results back to [INT-2]
si-2->>si-2: Re-identifies data and generate report
si-2->>si-6: Sends report to PACS [INT-5]

Patchability and Updatability View 🔗

NOTE: The patchability and updatedability view is a WIP. I’d usually show system items for these as well and would display them on the global system view.

sequenceDiagram
autonumber
participant R as Code Repository
participant BS as Build Server
participant S as Product Server

R->>+BS: notifies when to start a new System Image build [https]
BS->>+R: retrieves source code from [https]
R->>+BS: sends source code to [https]
BS->>+BS: builds the new system image
BS->>+S: pushes updated system image to product server [https]

Threat Modeling - STRIDE 🔗

STRIDE Threat Modeling was completed on 2025-07-03 by the following individuals:

The following scope and assumptions applied to the threat modeling:

• The security architecture views are accurate and complete.
• The scope of the STRIDE threat modeling only includes the top-level System Items and Connections.
• It includes the system items that are part of the build process.
• It assumes the healthcare facilities network is inherently hostile.
• The STRIDE-per-Element methodology was used, where specific STRIDE threats are considered for each of four types of items, as shown in the table below:

Here are the results of the STRIDE-per-element threat modeling, along with links to the related security risks (if any).

Example Security Risk Scales 🔗

The following example uses proximity of access and ease of exploitation to assign exploitability. The overall exploitability level is the mean of the two factors, rounded up; manufacturers should tailor these definitions to their device and use environment.

The security-impact severity scale considers effects on device and business operations, data, people, and connected organizations.

Security Risk Assessment 🔗

Security Controls 🔗

Revision History 🔗