Medical Device Cybersecurity: Best Practices, FAQs, and Examples

 January 22, 2024


Introduction 🔗

The FDA has become increasingly focused on medical device cybersecurity, as can been seen by the frequency and length of their guidance (2014, 2016, 2018, 2022, 2023, and 2024). This has only accelerated when, in 2023, congress gave FDA additional authority to regulate the cybersecurity of medical devices.

We’ve also seen a large up-tick in the FDA’s requests for additional information in medical-device submissions.

For groups who are less experienced with cybersecurity, reading the FDA guidance and the various standards can be overwhelming. Fortunately, when you boil down these abstract documents into the concrete actions you need to take, it’s actually much simpler. In this article, we collect a variety of best practices, questions, and examples related to cybersecurity. Our goal is to be as concrete and specific as we can.

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

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.

FAQs 🔗

Please note that threat modeling is used in many industries. This article discusses threat modeling medical devices and focuses on the US regulations.

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? 🔗

Per FDA’s eSTAR PDF template, you need to handle cybersecurity if your device

  • Is hosted in the cloud
  • Has a network connection (active or not)
  • Has wireless communication of any form
  • USB, serial ports, or removable media
  • Support software upgrades (including patches).

If you meet any of these conditions, FDA will require you to provide cybersecurity documentation in your 510(k) submissions and have a plan for monitoring, assessing, fixing, and reporting vulnerabilities after your device is on the market.

Technically, here’s the regulatory definition of a “cyber device”:

A ‘cyber device’ means a device that—(1) includes software validated, installed, or authorized by the sponsor as a device or in a device; (2) has the ability to connect to the internet; and (3) contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats.

In our experience interacting with the FDA, they interpret “has the ability to connect to the internet” broadly and if you meet any of the conditions in the eSTAR template, you’ll have a hard time arguing you’re not a cyber device. For example, devices that only have a USB port are still considered cyber devices. So are docker images which do not connect to the internet but are expected to be run in an environment where they can connect. For example, here’s a response from the FDA when we had tried to argue a device with just a USB port is not a cyber device:

Though the USB interface may only be intended for transferring images, the capability for someone to use it outside of its intended purpose remains (i.e., loading malicious software, etc.). While medical device systems with network and/or cloud access would be expected to have more cybersecurity safety requirements than a medical device system that has only a USB interface, a device with a USB interface is still by definition a cyber device.

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 likelihood, 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

Security Risk Management 🔗

What is security risk management? 🔗

Security risk management is similar to safety risk management. Both attempt to identify “bad things” that could happen, assess how likely or severe they would be if they did happen, and then mitigate them from happening. They differ in a few key ways. First, the types of “bad things” are different. Thus, the severity level definitions and acceptance criteria are different. Second, in the case of cybersecurity, there may be a malicious actor attempting to make the bad things happen for some motive. Thus, probabilistic analysis of failure is less relevant.

Safety risk management focuses on harm to patients and device users. Security risk management considers harm to assets due to cybersecurity breaches more generally, including business reputations, PHI, and other assets not accounted for in safety risk management. (As an aside, risk management is useful to model anytime you’re trying to anticipate harm more broadly, including harm to business profitability, regulatory submission risk, and so on.)

Security risks are sometimes, but not always, related to patient safety risks.

Safety risk management is clearly defined in the widely-adopted ISO-14971 standard.

Security risk management for medical devices is described in the AAMI TIR57 “Principles for medical device security—Risk Management” Technical Information Report, which the FDA has recognized as a consensus standard.

Venn diagram showing the relationship between security risk and safety risk. The FD&C Act, effective March 29, 2023, gave FDA jurisdiction to consider non-safety security risks.

There is a very useful diagram, which I’ve copied from TIR57, that shows the relationship between the processes:

Figure showing the relationship between a TIR57-compliant security risk-management process and an ISO 14971-compliant safety risk management process.

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:

Please attach your security risk management report detailing a separate, parallel,
and interconnected security risk management process. This is different from your
safety risk management process.

How should security risks be assessed? 🔗

This is a complicated question. We’ve seen some companies use the Common Vulnerability Scoring System (CVSS). For most devices, we don’t

What is multi-patient harm? 🔗

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

A device can cause “multi-patient harm” if a cybersecurity incident could result in multiple patients being harmed “simultaneously or in rapid succession”.

It’s not entirely clear what “rapid succession” means, however, here are some examples showing casing how I interpret

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.

Threat Modeling 🔗

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.)

A key output of the threat modeling process is a threat model.

What is a threat model? 🔗

A threat model is an approximate representation of your software system and the surrounding environment with regards to security.

Depending on your preference, we usually will either create a stand-alone threat model document or we will include the threat model as a section within a large security risk assessment document.

Regardless of whether the threat model is a section in another document, or is its own document, it typically contains the following items:

  • Assumptions about the system and environment of use
  • Your security assets
  • An analysis of expected threat actors
  • Architectural diagrams showing
    • The key components 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.

In our opinion, 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.

Not everyone would agree, but in our opinion, there’s not a clear distinction to be made between threat modeling and security risk management.

If we were forced 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.

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.

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.

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.
    • Examples: Backend Django App, AWS S3 Bucket, PACS, PostgreSQL Database, etc.
  2. Create a system diagram, including connections
    • These diagrams should show all the connections to external systems or networks.
    • Example (from )
  3. Identify all major cybersecurity assets
    • Assets can include data, user accounts, security keys, configuration files, the source code, and more.
    • We generally will indicate which system items the assets are stored within (sometimes the system items are themselves the assets)
    • Examples: AWS credentials, Configuration files, PostgreSQL Database
  4. Create threat lists for each system item using STRIDE
    • Iterate through each system item, reviewing the system diagrams as you go, and consider threat types according to STRIDE (Spoofing, Tampering, Repudiation, Info Disclosure, DDoS, Elevation of Privileges).
    • See and for more examples.
    • Spoofing: Pretending to be something or someone you’re not
      • 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)
      • Example:
        • Threat: Malicious actor modifies PostgreSQL Database via SQL injection.
        • Mitigation: Implement input validation on frontend and backend.
    • Repudiation: Doing something bad and claiming to not have done it
      • Example:
        • Threat: Malicious actor denies that a certain treatment has been prescribed.
        • Mitigation: Track all prescription actions in centralized logging system.
    • Information Disclosure: Having sensitive data leaked.
      • Example:
        • Threat: Malicious actor performs man-in-the-middle attack and steals data.
        • Mitigation: Use encryption in transit (HTTPS).
    • DDoS: Denial of service
      • Example:
        • Threat: Malicious actor overwhelms backend with abnormal traffic.
        • Mitigation: Configure AWS Web Application Firewall for common exploits.
    • Elevation of Privileges: Gaining unauthorized access
      • Example:
        • Threat: Malicious user changes their role to admin via API.
        • Mitigation: Only allow admins to change user roles and enforce this.
  5. Eliminate or refine threats that are highly improbable or impossible to verify.
    • Rule of thumb when pruning threat lists:
      • If a threat is likely to impact patient safety, keep it even if it’s hard to verify.
      • If a threat is unlikely to impact patient safety, and is difficult to verify, consider removing it.
      • If you have already implemented the mitigation for a threat and it is relatively 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
        • RSK-025: Brute Force Attack

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

Who should create the threat model? 🔗

Software engineers who are familiar with the system should be able to perform the threat modeling.

Unlike with penetration testing, where we do suggest using an external firm, we don’t typically suggest having an outside firm 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.

What is the difference between a threat-oriented, asset/impact-oriented, and vulnerability oriented risk analysis approach? 🔗

Security Architecture Views 🔗

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? 🔗

FDA recommends that it be considered for submission. If you don’t include it, you will need to have a good justification. We’ve not yet seen FDA allow our clients to justify not including vulnerability testing.

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:

Abuse or misuse cases, malformed and unexpected inputs
Robustness testing
Fuzz testing
Attack surface analysis
Vulnerability chaining
Closed box testing of known vulnerability scanning
Software composition analysis of binary executable files

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 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:

If generational malformed input testing is applied for a protocol on an interface, at least 1,000,000 unique and independent test cases or a minimum of 8 hours of test case execution shall be carried out, whichever comes first.

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? 🔗

A penetration test (pen test) is an authorized simulated attack performed on a medical-device system to evaluate its security. Penetration testers act as if they were attackers to find and demonstrate the business impacts of weaknesses in a device. Penetration tests usually simulate a variety of attacks that could threaten a device, using the same tools, techniques, and processes that real hackers use.

What is pentesting? 🔗

Pentesting is shorthand for penetration testing. We usually use the longer form because this is what the FDA uses in their guidance and in our documentation we generally try to follow the FDA’s lingo to make it easier on reviewers to follow our submissions.

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? 🔗

No. Unlike, e.g., including an SBOM, FDA doesn’t strictly require penetration testing. They suggest considering it.

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.

In most cases, we suggest including 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.

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

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? 🔗

If you need help with threat modeling or security risk management, it can be helpful to have a pen-tester who knows the FDA regulations. In general though, we don’t believe it is necessary to work with pen-testers who focus just on medical-devices. We’ve had several submissions with pen-testers who do not focus on the medical device sector.

Who are some good vendors to consider? 🔗

We’ve had clients use the following vendors:

Vendor Comments
Cobalt Quick Startup Time
MedSec Focused on medical devices
Blue Goat Focused on medical devices

How much does penetration testing cost? 🔗

It varies from vendor to vendor and based on the scope of the testing, but you can expect between $7k and $22k. We’ve even see as high as $200k in one instance.

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. It’s never happened to us, but it’s possible that FDA could reject results that were done too long ago.

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:

After release, cybersecurity testing should be performed at regular intervals commensurate with the risk (e.g., annually) to ensure that potential vulnerabilities are identified and able to be addressed prior to their ability to be exploited.

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 apply to medical-device cybersecurity? 🔗

There are two essential FDA guidance documents that apply to medical devices:

  1. 2023 FDA Guidance - Cybersecurity in Medical Guidance: Quality System Considerations and Content of Premarket Submissions This guidance is a good place to start.
  2. 2016 FDA Guidance - Postmarket Management of Cybersecurity in Medical Devices This guidance goes into more detail about post-market surveillance, but there is overlap between the two.

There is also a short, older guidance about cybersecurity of OTS software.

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). The two we feel are the most relevant are:

  1. ANSI/AAMI SW96:2023 Standard for medical device security—Security risk management for device manufacturers It describes how to create a security risk management process that’s similar to ISO 14971 and interacts with the safety risk management process. This builds on the AAMI TIR57 and AAMI TIR97, which are both technical reports.
  2. 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 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.

What other resources exist for threat models? 🔗

Examples 🔗

I’m hoping to add some examples some time soon, but I haven’t had a chance yet.

Security Architecture Views 🔗

Security Risk Assessment 🔗

Security Risk Management Plan 🔗

Threat Model 🔗

Revision History 🔗

Date Summary of Change
4 August 2023 Initial Version; It’s still rough around the edges, but useful enough to publish.
19 December 2023 Add more details about vulnerability testing and penetration testing, taking into account ideas from IEC 81001-5-1:2001
22 January 2023 Add a section about fuzz testing

Get To Market Faster

Monthly Medtech Insider Insights

Our monthly Medtech tips will help you get safe and effective Medtech software on the market faster. We cover regulatory process, AI/ML, software, cybersecurity, interoperability and more.