Update Notice (May 23, 2025)
This article is based on AAMI TIR57:2016, an important guideline for cybersecurity risk management in medical devices. Since 2023, TIR57 has been supplemented by the new standard ANSI/AAMI SW96:2023, which formalizes and expands its content.
The most important innovations:
- SW96 defines mandatory requirements for cybersecurity risk management for medical devices
- TIR 57 remains valid as a supporting document
- At the same time, IEC 81001-5-1 is becoming a central cybersecurity standard in the EU (recognized by the FDA).
AAMI TIR 57 is a Technical Information Report (TIR). It is designed to help medical device manufacturers identify and address cybersecurity risks in their medical devices to ensure confidentiality, availability, and integrity. To achieve this goal, the guidance document provides some suggestions for implementing a cybersecurity risk management process within your organization. AAAMI TIR 57 is not mandatory. However, the MDR, for example, requires manufacturers to identify risks in accordance with the state of the art, which is why it's worth reviewing. Cybersecurity is becoming an increasingly important topic (not only) in medical technology, as medical devices are becoming increasingly interconnected and their life cycles can extend over a decade.
AAMI TIR 57 has the same basic structure as the already familiar ISO 14971 standard and proposes its own process for security risks, which is strongly aligned with the (safety) risk management process. Whenever security is mentioned in this blog post in connection with AAMI TIR 57, it always refers to Cybersecurity Unfortunately, the German language is not precise enough here and, unlike English, does not distinguish between "safety" and "security."
If one compares the two chapter structures of AAMI TIR 57 with ISO 14971, the analogy is clearly noticeable.
The definitions of AAMI TIR 57 are also almost identical to ISO 14971. An example of this is the definition of “harm”.
Definition of “harm” in ISO 14971:
physical injury or damage to the health of people, or damage to property or the environment
Definition of “harm” in AAMI TIR 57:
physical injury or damage to the health of people, or damage to property or the environment, or reduction in
effectiveness, or breach of data and systems security
AAMI TIR 57 adds two important points to the definition:
- the reduction of the effectiveness of the medical device and
- the violation of data and system security.
In the following chapters, I would like to briefly show you how the recommended security risk management file is structured and which contents require special attention.
Security risk management file
The security risk management file is structured analogously to the risk management file of ISO 14971. The contents include at least:
- the security risk management plan
- the security risk analysis (including security measures)
- the security risk management report
The individual points are described in more detail in the next chapters.
Security risk management plan
Security risk management must be part of the medical device manufacturer's risk management process. The security risk management process can be integrated into the overall risk management process or managed as a supporting process. AAMI TIR 57 recommends outsourcing the process. It should also be noted that cybersecurity risks that impact safety must also be considered in safety risk management.
The security risk management plan must define the scope of security risk management activities. To define these activities, the general description of the medical device—that is, the context (operating environment) in which the medical device operates, the system architecture, and the intended use—must be known. Define these or reference the created documents.
Cybersecurity is a never-ending process. Threats can change and new vulnerabilities can be discovered during the system's lifetime. This can be due to proprietary software components or the SOUP (Source of Unknown Provenance) used. SOUP refers to software that was not developed for use in medical devices but is freely available. This could be, for example, the Hardware Abstraction Layer (HAL) from a microcontroller manufacturer. Therefore, define in your plan how you will monitor, report, analyze, and remediate new threats and vulnerabilities after the medical device is released into the market. One of the most important points, therefore, is to have a secure update process to be able to close vulnerabilities in the field.
Furthermore, you must document criteria for risk assessment, impact analysis and acceptance of residual risk.
The plan must also describe methods used during development, methods used for security risk verification, and how information will be collected after the product is released to identify threats and vulnerabilities.
Examples of methods used during development to reduce the likelihood of unintended features in software include code reviews, static code analysis, unit tests, and continuous integration.
Examples of methods for security risk verification include fuzzing, penetration testing or verification testing of cybersecurity control measures.
Information can be collected in various ways after the product has been placed on the market. You can obtain information from vulnerability databases, such as the National Vulnerability Database (NVD, "https://nvd.nist.gov/") or implement a so-called intrusion detection system in your medical device that collects attacks and stores them in log files. The information can then be communicated to users or to you.
Security risk analysis
Security risk analysis is a highly complex, iterative process that requires a great deal of expertise. It's important to think like an attacker. What motivates an attacker to hack a medical device? Is it to gain profit? Is it just for fun? Is it to harm the company or the patient? Always remember that you need a cybersecurity expert for the analysis to detect and properly assess all risks.
Before you can begin the risk analysis, some input is required. In addition to the general information you have already gathered in the risk management plan, it is important to check whether there are already security risks associated with comparable medical devices. For example, if you are developing an insulin pump, you will relatively quickly encounter a vulnerability in a well-known device that can administer high doses of medication. Analyze why this vulnerability occurred and how it can be avoided. You should then reflect the findings on your medical device and check whether this vulnerability could also occur. Also analyze whether there are specific configurations that the user must make to ensure the device is secure. Which SOUP do you use in your software? To do this, create a Cybersecurity Bill of Material (CBOM) and analyze potential vulnerabilities using the NVD mentioned above.
A threat model can help you identify threats effectively. This is also a good starting point. Microsoft's STRIDE model (https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling), which is very interesting and helpful.
This preparatory work allows you to record the threats, vulnerabilities, assets and adverse impacts in the security risk analysis document.
The next step is the risk assessment. This determines the level of risk and whether security measures are necessary. Also analyze whether the implemented security measures lead to new safety risks. The risk assessment is similar to ISO 14971.
Also record who was involved in the risk analysis, when it was carried out and which system components were analyzed.
The security measures identified must now be fed back into your requirements management and the resulting changes must be implemented, verified and validated.
Security risk management report
Finally, I would like to show what is contained in the security risk management report.
Summarize the findings of the risk analysis and describe the intended use and system context. The findings of the risk analysis include the vulnerabilities identified, the assets to be protected, and the damage that could result from a successful attack (compromise). You must also determine which measures need to be implemented. Traceability between risk, requirement, measure, and verification is particularly important here.
The report must also determine whether the overall residual risk of the system is acceptable and whether the measures taken are therefore sufficient. "Sufficient" means that the state of the art has been taken into account.
Finally, you need to describe how you can ensure that your medical device is delivered free of malware and how updates can be performed securely in the field. Can updates be performed by the user independently, or is a service technician required? Can the update file be downloaded online? How quickly are patches released?
Conclusion
AAMI TIR 57 can help you establish a cybersecurity risk management process within your organization. The appendices can be particularly helpful here. However, it doesn't show how to identify threats, vulnerabilities, and assets, and how to remediate them. I hope this blog has given you a brief insight into AAMI TIR 57 and the creation of a security risk management file. Analyzing the security risks of your medical device is very important. If you have any further questions on this topic, please feel free to contact us or leave a comment.
Another interesting article on cybersecurity can be found here: https://medtech-ingenieur.de/fda-cybersecurity-leitfaden-fuer-die-zulassung/.