Threat Modeling – An Introduction

Threat modeling is a “mandatory” topic for all manufacturers of medical devices that contain or are software. This is because threat modeling is a structured process for the systematic analysis of IT security risks that auditors consider to be the “state of the art.”

1. Why should you use threat modeling?

Reason 1: To develop secure devices

Threat modeling helps you systematically find and eliminate cybersecurity risks and, therefore, enables you to guarantee the IT security of your devices.

As a result, you fulfill your ethical duties and ensure the security and safety of users, patients and third parties. 

Reason 2: To fulfill legal requirements

You are not only ethically, but also legally obligated to ensure the IT security of your devices.

Additional information

This article on regulatory requirements regarding the IT security of medical devices will provide you with an overview of laws, directives, standards and other requirements that you have to follow.

Learn more on the regulatory requirements specific to threat modeling below.

Because threat modeling is a systematic process, using it in your submissions to authorities and notified bodies will help you convince them you have not overlooked any vulnerabilities.

Reason 3: To speed up development and reduce costs

IT security costs money. But it becomes even more expensive when vulnerabilities are identified too late and have to be fixed. In this case, there are additional costs for:

  • The subsequent analysis of the vulnerabilities
  • Eliminating the vulnerabilities (in the worst case, this involves a re-design of the device)
  • Compensating any injured persons
  • The legal consequences
  • Restoring your own reputation

The sooner manufacturers discover vulnerabilities, the easier, quicker and more economic it is to fix them. This means manufacturers should be using threat modeling even during the development phase of a device.

Reason 4: Transparency and “Peace of Mind”

Threat modeling’s traceable and visual methodology creates transparency with regard to the security of your own device. This systematic approach allows you to be sure that you have fully identified and eliminated any risks. And that gives you “Peace of Mind”.

2. What notation elements are used?

As the name suggests, threat modeling works with models.

These models use few notation elements that are easy to learn:

Notation element




External entity

People (e.g., users), systems (e.g., other devices), cloud services, browsers



DDL, exe(D)COM, web service, virtual machine, threat


Data store

File, database, registry, cache, cookie


Data flow

http request or response, remote procedure call, UDP communication


Trust boundary (inside you trust the processes and data stores, outside you don't)

Device boundary, process boundary

3. How does threat modeling work?

Stage 1: Establishing the scope and target

First of all, you have to define the scope and object of the threat modeling. Are you trying to model the vulnerabilities of a web service or those of the whole server? Is the threat modeling intended to demonstrate the security of a device or to help you design a secure system architecture?

Stage 2: Creating the model

Manufacturers need to put together all the elements to create the model. Specifically, these are:

  • System processes
  • System data stores
  • Intended and all undesired external entities (e.g., attackers)
  • Possible, i.e., intended and undesired, data flows between entities, processes and data stores

Manufacturers should then use trust boundaries to separate the system elements (processes, data stores) from the other elements they consider trustworthy. For a physical medical device, all the elements within the device are generally considered trustworthy.

This step will result in a model like the one shown in Figure 1.

Stage 3: Identifying potential threats

Once you have created the model, you can use it to automatically work out the potential threats using a tool like Microsoft's Threat Modeling Tool.

Otherwise, manufacturers have to identify the threats themselves manually. The threats can then be assigned to the following classes following the STRIDE model:


Attack class





Pretending to be someone else

A hacker pretends to be an authorized user



Modifying data or code

Malware encrypts data



Denying having done something

A user denies that they treated the patient with the device using certain parameters


Information disclosure

Confidential information is displayed to unauthorized people

A nurse can see the diagnosis of a VIP patient whose treatment she is not involved in and whose data she should not be able to see


Denial of service

DoS attack

A bot network floods a web server with http requests


Elevation of privilege

A person or system obtains privileges they/it should not have

A user manages to make themselves an administrator of a system

This step will result in a list of threats.

Stage 4: Evaluating threats

Not every potential threat has to result in measures being taken. However, as a manufacturer, you have to be able to provide a justification if you decide not to define any measures for a potential threat.

A possible justification could be that a compromised system cannot result in harm to a patient or third party. The probability of a device actually being compromised being negligible could also be used as a justification.

Stage 5: Defining and implementing countermeasures

If the risks are not acceptable, you need to define countermeasures. There are standard actions for each threat class (according to STRIDE):

Attack class

Examples of actions


Authentication, e.g., with Kerberos


Digital signatures


Secure audit logs

Information disclosure


Denial of service

Request filtering

Elevation of privilege

Access control lists (ACLs)

It is the responsibility of the manufacturer to define these measures, for example, as system or component requirements. This will ensure:

  1. These measures are actually implemented
  2. This implementation as well as the effectiveness of the measure is verified


You can find not only a comprehensive introduction to medical device IT security but also a series of videos on threat modeling, including a comprehensive list of measures for each threat type, in the training videos on Auditgarant.

Stage 6: Reviewing full implementation

Before releasing your medical device at least, you should ensure that all the defined measures have been implemented and their effectiveness demonstrated.

This does not mean checking the IT security of your device again, but rather checking the conformity of your IT security process (also known as the secure development lifecycle).

You should reflect on your approach at this point. If necessary, adapt your process, procedure and work instructions and tools, and/or improve your team's training. The seminar on IT security (German) may be helpful for ensuring that your employees’ skills meet the legal requirements.

4. What do you need to take into account when threat modeling?

Tip 1: IT security is a continuous process

Threat modeling is not a one-off activity. It should be repeated regularly, especially if you modify your device or data (e.g. from post-market surveillance) suggest it.


You can largely outsource post-market surveillance to the Johner Institute. Our Post-Market Radar continuously checks IT security databases and alerts you if there is an entry relevant to you among the thousands of notifications per month.

Tip 2: Don’t forget analytical quality assurance

Threat modeling is part of constructive quality assurance. This is the part of quality assurance (QA) that focuses on preventing errors. Constructive QA must be complemented by analytical QA, which focuses on finding errors. This includes, for example, penetration testing of devices.


Ask the Johner Institute's IT security experts if you need assistance with penetration testing. You can contact us easily using the web form.

Tip 3: Use tools

Tools, such as Microsoft's Threat Modeling Tool, help you systematically find potential threats to your devices and systems. They also make it easier for you to document and track your decisions regarding countermeasures.

We recommend using ALM tools, e.g. the tool of Medsoto to track and verify defined countermeasures.

5. What are the regulatory requirements for threat modeling?

Neither the MDR nor the IVDR nor the Food Drug and Cosmetic Act in the USA require manufacturers to perform threat modeling. However, they do require manufacturers to minimize IT security risks.

For devices that incorporate software or for software that are devices in themselves, the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation.

MDR Annex I paragraph 17.1

This “state of the art” is described in standards and guidelines such as:

All these documents mention threat modeling. This means manufacturers will have a hard time justifying not using threat modeling.

6. Conclusion

The fundamentals of threat modeling can be learned quickly, in part because there are good tools and the modeling language only involves few notational elements.

The system provides manufacturers, as well as notified bodies and regulatory authorities, with the necessary confidence in the IT security of the medical device.

Therefore, threat modeling should be an indispensable part of the secure development life cycle for all medical devices that are or contain software.


Prof. Dr. Christian Johner

Find out what Johner Institute can do for you

A quick overview: Our


Learn More Pfeil_weiß

Always up to date: Our


Learn More Pfeil_grau

Privacy settings

We use cookies on our website. Some of them are essential, while others help us improve this website and your experience.