AAMI+TIR97-2019+(R2023)

Technical
Information
Report
AAMI TIR97:
2019/(R)2023
Principles for medical
device security—
Postmarket risk
management for device
manufacturers
Advancing Safety in Health Technology
Copyright by AAMI. Reproduced by ANSI with permission of and under license from AAMI. Licensed to Iulian Borza. Downloaded 08/22/2023. Not for additional sale or distribution.
AAMI Technical Information Report AAMI TIR97:2019/(R)2023
Principles for medical device security—Postmarket

risk management for device manufacturers
Approved 27 September 2019 and reaffirmed 31 January 2023 by

AAMI
Abstract: Provides guidance on methods to perform postmarket security risk management for a medical
device in the context of the Safety Risk Management process required by ISO 14971. This TIR is
intended to be used in conjunction with AAMI TIR57:2016.
Keywords: medical device, information security, risk management, postmarket
AAMI Technical Information Report
A technical information report (TIR) is a publication of the Association for the Advancement of Medical
Instrumentation (AAMI) Standards Board that addresses a particular aspect of medical technology.
Although the material presented in a TIR may need further evaluation by experts, releasing the information is
valuable because the industry and the professions have an immediate need for it.
A TIR differs markedly from a standard or recommended practice, and readers should understand the differences
between these documents.
Standards and recommended practices are subject to a formal process of committee approval, public review, and
resolution of all comments. This process of consensus is supervised by the AAMI Standards Board and, in the case
of American National Standards, by the American National Standards Institute.
A TIR is not subject to the same formal approval process as a standard. However, a TIR is approved for distribution
by a technical committee and the AAMI Standards Board.
Another difference is that, although both standards and TIRs are periodically reviewed, a standard must be acted
on—reaffirmed, revised, or withdrawn—and the action formally approved usually every five years but at least every
10 years. A TIR must be acted on and the action formally approved usually every three years.
A TIR may be developed because it is more responsive to underlying safety or performance issues than a standard
or recommended practice, or because achieving consensus is extremely difficult or unlikely. Unlike a standard, a TIR
permits the inclusion of differing viewpoints on technical issues.
CAUTION NOTICE: This AAMI TIR may be revised or withdrawn at any time. Because it addresses a rapidly
evolving field or technology, readers are cautioned to ensure that they have also considered information that may be
more recent than this document.
All standards, recommended practices, technical information reports, and other types of technical documents
developed by AAMI are voluntary, and their application is solely within the discretion and professional judgment of the
user of the document. Occasionally, voluntary technical documents are adopted by government regulatory agencies
or procurement authorities, in which case the adopting agency is responsible for enforcement of its rules and
regulations.
Comments on this technical information report are invited and should be sent to AAMI, Attn: Standards Department,
901 N. Glebe Road, Suite 300, Arlington, VA 22203.
Published by
AAMI
901 N. Glebe Road, Suite 300
Arlington, VA 22203
www.aami.org
© 2019 by the Association for the Advancement of Medical Instrumentation
All Rights Reserved
This publication is subject to copyright claims of AAMI. No part of this publication may be reproduced or distributed in
any form, including an electronic retrieval system, without the prior written permission of AAMI. All requests pertaining
to this document should be submitted to AAMI. It is illegal under federal law (17 U.S.C. § 101, et seq.) to make copies
of all or any part of this document (whether internally or externally) without the prior written permission of the
Association for the Advancement of Medical Instrumentation. Violators risk legal action, including civil and criminal
penalties, and damages of $100,000 per offense. For permission regarding the use of all or any part of
this document, contact the Copyright Clearance Center.
Printed in the United States of America
ISBN 978-1-57020-725-9
Contents Page
Committee representation ............................................................................................................................................. iv
Foreword ....................................................................................................................................................................... vi
Introduction .................................................................................................................................................................. vii
1 Scope............................................................................................................................................................... 1
2 Terms and definitions....................................................................................................................................... 1
3 Postmarket considerations for security policies and security program administration...................................... 4
4 Design features for postmarket security risk management .............................................................................. 5
5 Installation and configuration ........................................................................................................................... 5
6 Postmarket management of fielded devices .................................................................................................... 6
7 Retirement/obsolescence .............................................................................................................................. 19
Annex A (informative) Sample medical device security policy statements ................................................................... 22
Annex B (informative) Security risk management for healthcare networks .................................................................. 25
Annex C (informative) Establishing a coordinated vulnerability disclosure process ..................................................... 32
Annex D (informative) Mapping of defined terms included in Guidance for Industry and Food and Drug Administration
Staff, Postmarket Management of Cybersecurity in Medical Devices ............................................................ 35
Annex E (informative) Security incident handling and response .................................................................................. 40
Bibliography ................................................................................................................................................................. 46
Committee representation
Association for the Advancement of Medical Instrumentation

AAMI Medical Device Security Working Group
This technical information report (TIR) was developed and approved by the AAMI Medical Device Security Working
Group.
At the time this document was published, the AAMI Medical Device Security Working Group had the following
members:
Cochairs: Geoffrey Pascoe

Brian Fitzgerald
Members: AJ Aspinwall, Norton Healthcare

Daniel Black, ResMed Inc.
William Brodbeck, STERIS Corporation| Healthcare
Richard Brooks, Battelle Memorial Institute
Bill Brown, Spacelabs Healthcare
Ryan Burke, AJW Technology Consultants Inc
Nick Chozos, Adelard LLP
Martin Crnkovich, Fresenius Medical Care
David Deaven, GE Healthcare
Margaret DePuydt, 3M Healthcare
Stephanie Domas, MedSec
Sherman Eagles, SoftwareCPR
Plamena Entcheva-Dimitrov, Preferred Regulatory Consulting Inc
Charles Farlow, Medtronic Inc Campus
Philip Fasano, Onclave Network Inc
Brian Fitzgerald, FDA/CDRH
Phil Fisk, Baxter Healthcare Corporation
Jill French
Alan Fryer, Micro Systems Engineering Inc
Kerry Griffin, Stryker Instruments Division
Stephen Grimes, ABM Healthcare Services
David Guffrey, Partners Healthcare
Michael Jaffe, Cardiorespiratory Consulting LLC
Michelle Jump, Nova Leah Ltd
Joshua Kim, Hill-Rom Holdings
Matthew Kirkwood, Smiths Medical
Tara Larson, Eli Lilly and Company
Joseph Lashway, Oregon Biomedical Association
Juuso Leinonen, ECRI Institute
Yimin Li, Abbott Laboratories
Joern Lubadel, B Braun of America Inc
Dan Lyon, Synopsys Inc
Matthew McMahon, Siemens Healthineers
Michael McNeil, Philips
Vidya Murthy, MedCrypt
Susumu Nozawa, Siemens Healthineers
Sagar Patel, Battelle Memorial Institute
Geoffrey Pascoe
Brodie Pedersen, Borderless Compliance LLC
Mike Powers, Christiana Care Health Srvcs
Chad Quistad, Regulatory and Quality Solutions LLC
Andrea Ruth, ALR Consulting LLC
Michael Seeberger, Boston Scientific Corporation
Nick Sikorski, Deloitte Advisory
Sandra Stuart, Kaiser Foundation Health Plan/Hospitals
iv © 2019 Association for the Advancement of Medical Instrumentation ■ AAMI TIR97:2019
David Vershum, Cantel Inc
Fubin Wu, GessNet
Susan Yang, Amgen Inc
Daidi Zhong, Chongqing University
Alternates: Robert L. Banta, Eli Lilly and Company
Justin Bushko, AJW Technology Consultants Inc
John Dwyier, Onclave Network Inc
Phillip Englert, Deloitte Advisory
Dawn Flakne, Micro Systems Engineering Inc
Karoll Gonzalez, Stryker Instruments Division
Edwin Heierman, Abbott Laboratories
Curtice Huntington, Smiths Medical
William Hagestad, Medtronic Inc Campus
Gregory Land, STERIS Corporation| Healthcare
Dale Nordenberg, MDISS—Medical Device Innovation, Safety and Security Consortium
Jyothsna Nunna, Regulatory and Quality Solutions LLC
Beth Pumo, Kaiser Foundation Health Plan/Hospitals
Mark Rohlwing, ICU Medical Inc
Lisa Simone, FDA/CDRH
Robert Smigielski, B Braun of America Inc
Ryan Wick, Deloitte Advisory
Grace Wiechman, Boston Scientific Corporation
Ashley Woyak, Baxter Healthcare Corporation
Jaime Zappa, Cantel Inc
Nicole Zuk, Siemens Healthineers
Varun Verma, Philips
NOTE—Participation by federal agency representatives in the development of this document does not constitute
endorsement by the federal government or any of its agencies.
© 2019 Association for the Advancement of Medical Instrumentation ■ AAMI TIR97:2019 v
Foreword
This technical information report (TIR) was developed by the AAMI Device Security Working Group.
The challenge of managing security risks for deployed devices is becoming more complex. To develop devices and
systems cost effectively, the use of a larger set of commercial third-party components during the development of a
medical device is becoming more common, particularly for devices that are intended to be connected to networks.
The result is that the security risk for a device evolves over time even if the device does not change. Knowledge of
new vulnerabilities and threats can originate from multiple sources. Manufacturers need to be prepared to receive
vulnerability information, actively seek information on new threats, assess risk, and take the appropriate action.
The objective of this TIR is to provide guidance on how medical device manufacturers should manage security risk in
the production and post-production phases of the life-cycle of a medical device within the risk management
framework defined by ANSI/AAMI/ISO 14971:2007. TIR97 is intended to be used in conjunction with AAMI
TIR57:2016.
Suggestions for improving this recommended practice are invited. Comments and suggested revisions should be sent
to Technical Programs, AAMI, 901 N. Glebe Road, Suite 300, Arlington, VA 22203.
NOTE This foreword does not contain provisions of AAMI TIR97, Principles for medical device security—Postmarket risk
management for device manufacturers (AAMI TIR97:201x), but it does provide important information about the development and
intended use of the document.
vi © 2019 Association for the Advancement of Medical Instrumentation ■ AAMI TIR97:2019
Introduction
ANSI/AAMI/ISO 14971:2007(R)2010 is an integral part of the safety risk management processes required by many
regulatory authorities. ANSI/AAMI/ISO 14971 specifies a process for a manufacturer to identify the hazards
associated with medical devices, including in vitro diagnostic (IVD) medical devices, to estimate and evaluate the
associated risks, to control these risks, and to monitor the effectiveness of the controls (see Clause 1 of
ANSI/AAMI/ISO 14971:2007).
AAMI TIR57:2016—Principles for medical device security—Risk management provides guidance for addressing
security within the risk management framework defined by ANSI/AAMI/ISO 14971. This report augments AAMI TIR57
by providing detailed guidance for the management of security risks in the production and post-production phases of
the life-cycle of a medical device.
Following the approach developed in AAMI TIR57:2016, the definition of harm is considered from the perspective of
ANSI/AAMI/ISO 14971, as well as from healthcare information technology (IT) standards, such as the
ANSI/AAMI/IEC 80001 family. Because a security risk management process that narrowly focuses on the traditional
“physical injury or damage” definition can limit the scope of security risk mitigation, this document incorporates the
broader considerations that risks include effects outside the traditional scope of patient physical harm and can include
“reduction of effectiveness” and “breach of data and systems security” as extended in the ANSI/AAMI/IEC 80001
family of standards. The relationship illustrated in AAMI TIR57:2016, Figure 2, “A Venn diagram showing the
relationship between security and safety risks” is equally applicable to concepts presented in this report.
ANSI/AAMI/ISO TIR24971:2013/(R)2016 Medical devices—Guidance on the application of ISO 14971 describes a

“production and post-production feedback loop” that consists of three processes:
 observation and transmission (Subclause 4.2);
 assessment (Subclause 4.3); and
 action (Subclause 4.4).
This report expands upon each of these processes to address the unique challenges associated with maintaining the
security of a medical device.
Supporting annexes contain the following:
 Annex A: Sample medical device security policy statements—Provides a non-exhaustive list of sample
statements that can be incorporated in a manufacturer’s medical device security policy;
 Annex B: Security risk management for healthcare networks—An overview of risk control measures that can
be implemented by a healthcare delivery organization and in the home networking environment;
 Annex C: Establishing a coordinated vulnerability disclosure process—Reviews manufacturer-specific
considerations for establishing a coordinated vulnerability disclosure process based on published
vulnerability disclosure and vulnerability handling consensus standards; and
 Annex D: Mapping of defined terms included in Guidance for Industry and Food and Drug Administration
Staff, Postmarket Management of Cybersecurity in Medical Devices—A comparison of terms defined in FDA
guidance with those defined in ANSI/AAMI/ISO 14971:2007 and this report.
© 2019 Association for the Advancement of Medical Instrumentation ■ AAMI TIR97:2019 vii
AAMI Technical Information Report AAMI TIR97:2019/(R)2023
Principles for medical device security—Postmarket

risk management for device manufacturers
1 Scope
This TIR provides guidance for addressing postmarket security risk management within the risk management
framework defined by ANSI/AAMI/ISO 14971. While it is based on the ANSI/AAMI/ISO 14971 framework for medical
device risk management, most concepts are applicable to any healthcare product that requires postmarket
management of security.
This guidance is intended to assist manufacturers and other users of the standard with the following:
 establishing an enterprise-wide process to manage security postmarket interactions with users and other
stakeholders;
 creating design features that enable postmarket management of security risk and effective integration with
healthcare delivery organization (HDO) network security policies and technologies, or other operational
contexts;
 understanding and communicating the security expectations from manufacturers to those who deploy
medical devices in a user environment;
 implementing processes to monitor fielded devices for newly discovered security vulnerabilities both from
the devices themselves and from other sources;
 implementing processes to assess both safety and security risk to decide when action is required;
 developing a coordinated vulnerability disclosure process;
 implementing processes to manage device security patching; and
 planning for device retirement.
The guidance provided by this document is applicable to the production and post-production phases of the life-cycle
of a medical device (hereinafter referred to as the “postmarket” phase).
This TIR expands the information provided in Clause 4 “Production and post-production feedback loop” of
ANSI/AAMI/ISO TIR24971:2013 by highlighting the need for proactive monitoring to assess threats and detect
vulnerabilities. It references the coordinated safety/security risk assessment approach that was presented in Clause 9
of AAMI TIR57:2016, Production and post-production information.
2 Terms and definitions

For the purposes of this document, the terms and definitions given in AAMI TIR57:2016 and the following apply.
2.1
accompanying document
document accompanying a medical device and containing information for those accountable for the
installation, use, and maintenance of the medical device, the operator, or the user, particularly regarding
safety
NOTE Adapted from IEC 60601-1:2005, definition 3.4.
[SOURCE: ISO 14971:2007, 2.1]
© 2019 Association for the Advancement of Medical Instrumentation ■ AAMI TIR97:2019 1
2.2
compensating risk control measure
compensating control
specific type of risk control measure deployed in lieu of, or in the absence of, risk control measures implemented as
part of the device’s design
Note 1 to entry: A compensating risk control measure could be permanent or temporary (e.g., until the manufacturer can provide an
update that incorporates additional risk control measures).
[SOURCE: Guidance for Industry and Food and Drug Administration Staff, Postmarket Management of Cybersecurity
in Medical Devices (2016), modified—The first sentence of definition IV.A has been incorporated with changes to
clarify that this type of risk control measure is not part of the device’s design. Note 1 to entry has been added to
delineate different types of measures.]
2.3
coordinated vulnerability disclosure
CVD
process through which researchers and other interested parties work cooperatively with a manufacturer in finding
solutions that reduce the risks associated with disclosure of vulnerabilities
Note 1 to entry: This process encompasses actions such as reporting, coordinating, and publishing information about a vulnerability
and its resolution.
[SOURCE: ISO 29147:2014, modified—Adapted from text contained within the introduction clause.]
2.4
cybersecurity signal
information that indicates the potential for, or confirmation of, a vulnerability, exploit, threat, or threat event that
affects, or could affect, a medical device.
[SOURCE: Guidance for Industry and Food and Drug Administration Staff, Postmarket Management of Cybersecurity
in Medical Devices (2016), modified—The first sentence of definition IV.D has been incorporated with changes to add
threat and threat event.]
2.5
end of guaranteed support
EOGS
point at after which the manufacturer no longer guarantees full support.
Note 1 to entry: During this life-cycle stage, there can be some level of support available by the manufacturer, but without a
guarantee that the medical device can be maintained to its original specification and performance.
2.6
end of support
EOS
point after which the manufacturer terminates all service support activities
Note 1 to entry: Service support does not extend beyond this point.
2.7
exploit
instance where a vulnerability or vulnerabilities have been exercised (accidently or intentionally) by a threat
SOURCE: Guidance for Industry and Food and Drug Administration Staff, Postmarket Management of Cybersecurity
in Medical Devices (2016), modified—Definition IV.E has been changed to remove language pertaining to potential
impacts.]
Note 1 to entry: “Exploit” can also be a technique that exercises a security vulnerability.
2.8
guaranteed support
life-cycle stage of a product starting with customer availability in the post-production phase and ending when the
product reaches the point at which the manufacturer no longer guarantees full support
2 © 2019 Association for the Advancement of Medical Instrumentation ■ AAMI TIR97:2019
Note 1 to entry: Limited support can be available once a medical device reaches the end of guaranteed support depending upon the
manufacturer, medical device, and other factors.
2.9
information sharing and analysis center
ISAC
operational entities formed by critical infrastructure owners and operators to gather, analyze, appropriately sanitize,
and disseminate intelligence and information related to critical infrastructure
Note 1 to entry: ISACs provide 24/7 threat warning and incident reporting capabilities and have the ability to reach and share
information within their sectors, between sectors, and among government and private sector stakeholders.
Note 2 to entry: ISACs are the original ISAOs for the critical infrastructure sectors.
Note 3 to entry: Although ISACs are recognized as operational entities in the United States, similar organizations exist in other
countries.
[SOURCE: U.S. Department of Homeland Security, National Infrastructure Protection Plan 2013, modified—The
second sentence has been moved to a note (Note 1 to entry). Note 2 to entry and Note 3 to entry have been added to
clarify applicability. The source for Note 2 to entry is https://nhisac.org/nhisac-faq/.]
2.10
information sharing and analysis organization
ISAO
any formal or informal entity or collaboration created or employed by public or private sector organizations, for
purposes of gathering, analyzing, communicating, disclosing, or voluntarily disseminating information in order to
better understand security problems and interdependencies related to critical infrastructure and protected systems, so
as to ensure the availability, integrity, and reliability thereof
Note 1 to entry: An ISAO communicates or discloses critical infrastructure information to help prevent, detect, mitigate, or recover
from the effects of an interference, compromise, or an incapacitation problem related to critical infrastructure or protected systems.
Note 2 to entry: An ISAO voluntarily disseminates critical infrastructure information to its members, local and Federal Governments,
or any other entities that may be of assistance. Similar organizations exist in other countries.
[SOURCE: 6 U.S.C § 131 (5), modified—The definition has been developed from subparagraph (a) modified to
include progressive verbs of subparagraphs (b) and (c). Note 1 to entry and Note 2 to entry have been added to
summarize subparagraphs (b) and (c), respectively, and to clarify applicability.]
2.11
intended use
intended purpose
use for which a product, process or service is intended according to the specifications, instructions, and information
provided by the manufacturer
[SOURCE: ANSI/AAMI/ISO 14971:2007, definition 2.5]
2.12
life-cycle
all phases in the life of a medical device, from the initial conception to final decommissioning and disposal
[SOURCE: ANSI/AAMI/ISO 14971:2007, definition 2.7]
2.13
post-production
part of the life-cycle of the product after the design has been completed and the medical device has been
manufactured
EXAMPLES transportation, storage, installation, product use, maintenance, repair, product changes,
decommissioning and disposal.
Note 1 to entry: The post-production phase includes devices manufactured and placed in inventory as well as those devices that
have been shipped to customers and are subject to postmarket surveillance.
[SOURCE: ANSI/AAMI/ISO 14971:2007, definition 2.11, modified—Note 1 to entry has been added.]
2.14
security capability
The broad category of technical, administrative or organizational controls to manage risks of
confidentiality, integrity, and availability and accountability of data and systems.
[SOURCE: ISO/IEC 80001-2-2: XXXXXXXXX]
2.15
security incident
a violation or imminent threat of violation of security policies, acceptable use policies, or standard security practices
[SOURCE: NIST SP 800-61 Rev. 2 (2012), modified—The term “computer” has been removed from the definition
included in section 2.1.]
3 Postmarket considerations for security policies and security program

administration
3.1 Medical device security policy
AAMI TIR57:2016 provides guidance on developing a medical device security policy in Subclause 3.2, Management
responsibilities. The medical device security policy should define management’s intent to secure the organization’s
medical devices throughout their lifecycle. The policy should address postmarket regulatory requirements and be
supported by standards, procedures, work instructions, and other artifacts that address security risk management,
threat event handling, incident handling, coordinated vulnerability disclosure, and security education and training. In
addition, the policy should facilitate consistent and effective external communications, as well as allow for monitoring
and improvement of the processes required by the policy.
Postmarket information in the policy should include, but not be limited to, threat intelligence, patch and vulnerability
management, threat event and incident handling, security risk assessment, and third-party risk management. The
policy should also include requirements for security maintenance across the entire device life-cycle.
Annex A provides a non-exhaustive list of sample statements that can be incorporated in a manufacturer’s medical
device security policy.
3.2 Coordinated vulnerability disclosure

Manufacturers should develop a coordinated vulnerability disclosure process to provide security researchers and
others with a means to communicate device vulnerabilities to appropriate parties, including regulatory authorities.
Subclause 6.1.2 and Annex C provide additional information about establishing a coordinated vulnerability disclosure
process.
NOTE The customer communication channel for handling complaints can typically be used for handling reports of potential
vulnerabilities with minor modifications and appropriate training. However, this is separate from the coordinated vulnerability
disclosure process which requires agreements to be in place prior to discussion of vulnerabilities.
3.3 Information sharing

Information about medical device vulnerabilities and potential threats to these devices should be communicated in a
consistent manner to existing customers. Depending on the nature of the vulnerability or threat, it may also be
important, such as when the vulnerability or threat could apply to the broader industry, to share the information with
an information sharing and analysis organization (ISAO).
To prevent threat actors from exploiting a vulnerability in a device and potentially causing harm, a process should be
established to communicate details on vulnerabilities, compensating controls, and risk controls to customers. How
quickly this communication will occur should be established and be dependent on risk level of the vulnerability/threat.
In the case of a moderate to high-risk vulnerability, communication to the customer should be done expediently even
if vendor-recommended compensating controls or remediation steps are not yet available (see Subclause 6.2.2). This
communication may include posting known vulnerabilities to a publicly accessible or password protected space (i.e.,
company website) together with the corresponding patches, when applicable. Information provided may also be
staged as it becomes available. Information shared should also include details about the risk ranking of the
vulnerability (e.g., its Common Vulnerability Scoring System(CVSS) scoring) and whether it has been exploited. For
higher-risk vulnerabilities, the first stage will typically suggest compensating controls (e.g., removing the medical
device from the network) that can be implemented by the end user while the manufacturer develops a more
comprehensive risk control measure (e.g., patch). For a high-profile vulnerability which affects the overall medical
and IT industries (e.g., WannaCry), even if the manufacturer confirms that the vulnerability is not exploitable on their
product(s), the manufacturer should promptly communicate this information in order to assist HDOs in concentrating
their efforts on other medical devices potentially affected. Reporting vulnerabilities to an ISAO allows critical cyber
information to be shared with other stakeholders, which can prevent similar vulnerabilities in other medical devices
from being exploited or additional cyber-attacks from occurring. This relationship is mutual, and in return for sharing
information, manufacturers should be given information and intelligence on vulnerabilities and threats across multiple
sectors.
3.4 Communication of security capabilities

Potential customers often send inquiries to manufacturers requesting the security capabilities of products under
consideration. The manufacturer should establish and maintain a process for providing potential, and existing,
customers with current and accurate security capability documentation. The format and content of this documentation
should be consistent. An accurate software bill of materials (SBOM) is a key component for creating a product
security risk assessment, performing technical security testing, monitoring of threats and vulnerabilities, and
responding effectively to threat events. An SBOM also supports HDOs in establishing an inventory of medical
devices, including software.
NOTE A Security Bill of Materials (CBOM) would include hardware sub-components in addition to the SBOM. In this
document we will continue to use the term SBOM because it is well understood.
A common way to communicate the security capabilities of medical devices is the Manufacturer Disclosure Statement
for Medical Device Security (MDS2) form [6]. The value of the MDS2 form depends on the level of detail provided in
the “notes” sections for each security capability. In many cases, customers request detailed information about
security capabilities of medical devices in their own format. The manufacturer should be prepared to respond to these
requests in a timely manner. Some requests could necessitate the development of contractual provisions to protect
the intellectual property of the manufacturer.
To facilitate timely responses to detailed customer inquiries, manufacturers should describe the security capabilities
of a device in a standardized format, in a template with consistent language between product teams, during the
product generation/creation process. This information supports the preparation of MDS2 forms for the product and
can form the basis of standard responses to customer inquiries. MDS2 forms should be made available to customers
upon request, and updated forms should be released whenever security capabilities are modified due to new product
or version releases.
4 Design features for postmarket security risk management

As defined in ISO 14971, risk management includes “activities related to collection and review of relevant production
and post-production information.” The device should include features that enable the collection of information relevant
to management of post-production security risk or otherwise enable oversight and protection. While HDO networks
share characteristics of IT networks, it is incumbent on the manufacturer to understand, where possible, the
operational context.
Annex B provides an overview of risk control measures that can be implemented by a manufacturer to support HDOs
and home healthcare users. This annex is intended to complement standards such as IEC/TR 80001-2-2 Application
of risk management for IT-networks incorporating medical devices—Part 2-2: Guidance for the communication of
medical device security needs, risks and controls and IEC/TR 80001-2-8 Application of risk management for IT-
networks incorporating medical devices—Part 2-8: Application guidance—Guidance on standards for establishing the
security capabilities identified in IEC 80001-2-2.
NIST Special Publication 800-160 Volume 1 Systems Security Engineering provides information on how to
incorporate security-specific design features into the device during its development life-cycle. AAMI TIR57:2016
provides manufacturer-focused guidance in Annex C, Generating cybersecurity requirements.
5 Installation and configuration

AAMI TIR57:2016, Subclause 4.2, states that the manufacturer should document characteristics of the system that
rely on user configuration to ensure the security of the device. Annex D of AAMI TIR57:2016 includes checklist items
that address the secure installation and configuration of medical devices.
5.1 Device security configuration
Device security configurations can apply to a variety of device components, such as access control mechanisms
(e.g., file permissions), cryptography modules, network devices (e.g., firewalls), malicious code protection (e.g., anti-
virus or application whitelisting), and third-party software (e.g., operating system). A medical device should be
designed with a baseline configuration which should be used to periodically check against the device’s current
configuration to determine if the configuration has been altered. The device's design should include features to allow
a configuration difference to be determined. Policies, standards, and procedures should be developed to establish
minimum hardening requirements and processes for the development, management, and ongoing monitoring of
device component configurations. Device component configurations need to be managed and maintained per
contract and service level agreements (e.g., the secure use and storage of a configuration).
Improper configuration of devices can introduce vulnerabilities that degrade confidentiality, integrity, or availability.
Each device component configuration should be considered for hardening, including assessing whether hardening
could affect critical functionality and/or performance of the component. If the component is hardened, industry
practices should be leveraged whenever possible, such as security technical implementation guides (STIGs). Tools
such as STIGs provide a robust mechanism for hardening third-party software. In addition, the device manufacturer
should provide a hardened configuration for each device component (by default) and allow the customer to add or
increase security settings of each configuration. Removing or decreasing security settings from the default, secure
configuration should be discouraged. Customers should be cautioned against making changes to medical devices
that result in higher security risk. Use both customer device documentation and/or warnings in the medical device.
For example, a medical device could provide a warning if the changes to the configuration would result in higher
security risk.
5.2 Security utility updating

Updates to security utilities such as network devices (e.g., firewalls) or malicious code protection mechanisms (e.g.,
anti-virus) need to be controlled. An improperly configured or malformed update can introduce vulnerabilities (e.g.,
accidentally opening firewall ports) or render a security utility unavailable. Updates should be tested in a staging
environment, which mirrors a production environment, to determine if the update has any unintended consequences
or impact to clinical functionality and capability of the device. After the update is tested, the manufacturer should
distribute the update to all fielded devices that use the security utility. Updates should be deployed in alignment with
service level agreements between the manufacturer and the HDO. If an update is not able to be deployed for any
reason, an explicit business reason should be provided, and compensating security controls should be identified,
documented, and communicated to the customer.
5.3 Other considerations for security maintenance in the clinical environment

Security maintenance provided in the clinical environment by the manufacturer should be logged and monitored using
automated tools (e.g., security information and event monitoring (SIEM)). These automated tools should include
functionality to allow for output to the end user, including a detailed log of changes that have been made to the
device’s security configuration. Security settings should not be changed without the explicit and documented
authorization of the operator of the medical device. Security maintenance activities should be authenticated and be
restricted from accessing unauthorized device functionality or data.
6 Postmarket management of fielded devices

When a medical device is in use, there are several sources of information through which a manufacturer can learn of
vulnerabilities in, and threats to, fielded devices. It is important to understand that vulnerabilities exist in practically
any software-controlled device. They can be present in the third-party code that is used in the device (e.g., operating
system, networking libraries, frameworks) or in the code developed by the manufacturer. Discovery can come from
both outside the manufacturer (e.g., researchers, suppliers, national databases) or from internally driven activities
(e.g., failure analysis, engineering work, contracted device analysis, various testing activities).
After a vulnerability or threat is identified, it should be assessed for the risk to which it can expose the device, either in
terms of safety and to the security of the device or to other systems on the network to which the device is connected.
Figure 1 extends Figure 4 from AAMI TIR57:2016 to add the postmarket decision-making that can trigger a
reassessment of either safety or security risk (or both) and the decision whether a vulnerability requires correction,
new threats are significant, and additional safety or security controls are required.
Figure 1—Postmarket decision-making flow diagram
This subclause covers the processes and decision steps a manufacturer should consider in creating their postmarket
security response procedures. It is organized along the steps identified in Clause 4 of ANSI/AAMI/ISO
TIR24971:2013:
 observation and transmission;
 assessment; and
 action.
Cybersecurity signals, as defined in Subclause 2.3, are a subset of “security production and post-production
information” as illustrated in Figure 1. Cybersecurity signals can impact security risk assessments for multiple
products. For each product-specific security risk assessment, a single cybersecurity signal can impact assessments
for multiple threat events.
Before categorizing a signal as a security incident, triaging should occur to validate that there has been an attempt to
access and/or adversely affect device data, systems, services, or networks in the context of data availability,
disclosure of proprietary information, illegal access, misuse, or escalation of authorized access. Security incidents are
discussed later in this document.
Cybersecurity signal handling starts with monitoring many sources for potential threat events: customer feedback,
complaints, vendor reports, news items, etc. At its core, cybersecurity signal monitoring is about actively seeking
information on the entire security landscape of a product, while providing valuable insight needed to make risk
mitigation decisions. Various cybersecurity signals can occur at any given time. Signals that can impact security risk
assessments include, but are not limited to
 a report of a security vulnerability from a third party,
 new threats and vulnerabilities detected through threat intelligence,
 customer questions regarding the security of the device, and
 vulnerabilities detected internally by the manufacturer or product team.
An overview of the cybersecurity signal handling process recommended in this document is illustrated in Figure 2.
Figure 2—Cybersecurity signal handling process
The cybersecurity signal handling process should capture relevant information and provide traceability from intake
through resolution. Information about a cybersecurity signal should be captured and documented at each phase
including;
 the origin, date, time of the signal,
 technical information about the details of the event,
 a preliminary determination of priority and applicability to different products, and
 a product-specific assessment of the risk represented by the signal, whether the signal requires a
modification to the product, and if modification is required, what action was taken and linkage to the
elements that provide objective evidence that the action was taken.
After the preliminary cybersecurity signal risk assessment is completed, each impacted product team should perform
a product-specific threat event risk assessment.
NOTE The product-specific threat event risk assessment is a component of the overall security risk assessment for a product—
typically, security risk assessments include the consideration of multiple threat events.
6.1 Observation and transmission
Security monitoring
Once a device is marketed, the manufacturer is responsible for monitoring its on-going security status. Information on
potential sources of insecurity can come from several sources. As a best practice, manufacturers should link newly
identified vulnerabilities from national databases directly into change requests in the associated product’s tracking
system to ensure they are assessed for risk.
6.1.1.1 Supplier monitoring

An essential part of monitoring the security status of a device is the monitoring of software of unknown provenance
(SOUP), commercial off-the-shelf software (COTS), and hardware vendors for reported defects, vulnerabilities, and
patches. The manufacturer should create an SBOM containing SOUP and COTS as well as the manufacturer-created
software. (See Subclause 3.4). The manufacturer should develop a process for monitoring its suppliers for the
availability of software updates and for disclosure of vulnerabilities and defects. This process should include the
following elements:
 examining release notes for new versions of the product to determine which defects in earlier versions have
been corrected in the new version;
 registering with the supplier to get updates on specific products and versions, when available; or
 reviewing trade publications and product-related bulletin boards for information.
Self-support can be necessary when the licensing for software explicitly excludes support, and this results in the
manufacturer becoming responsible for issue resolution and maintenance of the software. On receiving notice of end
of support for any SOUP or COTS component, the manufacturer should review the usage of the software and
develop a plan to either replace the software or take over its maintenance. A maintenance plan should address
support of SOUP and COTS components that are known to end support before EOGS.
6.1.1.2 Vulnerability monitoring

Vulnerabilities in SOUP and COTS components and in the device manufacturer’s software can be reported by parties
other than the supplier. The manufacturer should, at a minimum, monitor these sources:
 researchers that investigate and report vulnerabilities in health software and medical devices;
NOTE A coordinated vulnerability disclosure policy (see Subclause 3.2) is essential in managing interactions with
researchers.
 vulnerability databases such as National Cybersecurity Communications Integration Center Industrial

Control Systems (NCCIC ICS) and US-CERT (general);
 security information from subcontractors; and
 incident response reporting from customers/end users. Customers are an essential and useful source of
information on vulnerabilities observed or detected in the device.
6.1.1.3 Third-party monitoring services
If the manufacturer chooses to use an outside service to perform vulnerability monitoring, an agreement should
incorporate a clear description of what services are included. As appropriate, the agreement should include details of
the following:
 list of the affected products with specific version numbers;
 list of COTS and SOUP components with specific version numbers;
 list of the external sources other than the suppliers to be monitored;

 service level agreement on notifications (e.g., how promptly after the posting of a vulnerability will the
manufacturer be notified); and
 whether the agreement includes testing of patches to COTS and SOUP components, agreements on what
testing is performed and how soon after notification (e.g., hotfixes to Windows, Adobe, Linux).
6.1.1.4 Product return and servicing

When the manufacturer receives a product for service, it should analyze the product’s event logs for signs of intrusion
and check the product for the presence of malware. This can be a valuable source of information on vulnerabilities in
the device and help with revisions of the risk analysis for the product and with risk mitigation.
Care should be taken with returned product to ensure that any malware present does not infect other devices or the
environment in which it is being serviced. See Subclause 7.2, Secure disposal, for additional information about end of
service returns.
6.1.1.5 Changes in operational context

A manufacturer should be familiar with the operational context and workflow of the device in its use environment. If
the security posture is dependent on specifics of the operational context (e.g., the device is designed to be deployed
on a private network with specific firewall protections), this can require changes to theaccompanying documents.
Assessment of a new vulnerability by the manufacturer should include potential impact on the operational context.
For example, there might be little likelihood of a vulnerability being exploited on a hospital network, but a higher
likelihood of it being exploited in a home care environment. This is an important part of the assessment of a
vulnerability.
6.1.1.6 Active monitoring

Another form of security monitoring is to actively monitor a device when it is in operation. To perform this active
monitoring a medical device’s design must support the ability to perform security logging with the device capturing an
electronic record of any security-related activity. How and by whom that log information is processed should be
determined by the manufacturer. It should be noted that if the security log is stored on the device itself, it can be
subject to tampering by a sophisticated attacker who wants to cover their tracks. Most security logging systems have
the ability to securely transmit log data to a separate server, which can be used to support active monitoring and
SIEM integration if desired. Which party (e.g., manufacturer, HDO) is responsible for the active monitoring of security
logs should be indicated by the manufacturer in the r accompanying documentation.
Logs can be stored for later forensic analysis or may be used as part of an active monitoring system, looking for
evidence of intrusion in real-time. The capabilities of large HDOs can be different than those of smaller HDOs, so the
design of the device may need to be flexible in terms of what is logged and whether it is sent off-device.
Manufacturers may also desire to have access to this log data to allow for post-processing and to perform pattern
analysis which may indicate the need for additional controls. Again, flexibility is recommended as the policies for
allowing remote transmission of data out of an HDO’s network may vary by HDO. Where logs are sent outside the
device, security controls should be implemented to protect sensitive information (e.g., PII, PHI, configuration data) in
the logs—best practice is to avoid unnecessary sensitive data in logs and encrypt logs when they are at rest and are
transmitted. At a minimum, manufacturers should provide the capability to protect sensitive information that is
transferred from the device.
Security logging is addressed in more detail in Annex B.
Coordinated vulnerability disclosure

As noted in Subclause 3.2, the manufacturer should establish a coordinated vulnerability disclosure (CVD) program
to support the communication of vulnerabilities from researchers and other parties. A means to receive vulnerability
reports should be published publicly so that external parties can report vulnerabilities and understand the
manufacturer’s CVD process. As part of this process, a manufacturer should outline the expected responsibilities on
both sides of the process (i.e., the reporting entity and the receiving entity) so that each can manage those
expectations and ensure proper communication. The bibliography lists resources available to guide CVD
development processes. At a minimum, the process should define the scope of products and services,
responsibilities, reporting mechanisms (e.g., form or website), expected timelines, and legal considerations.
It is important to define the scope of products and services that will be part of the CVD program. The manufacturer
should include a list of exclusions that explicitly defines out-of-scope products and services such as products and
services (e.g., a third-party website) owned or hosted by third parties. Responsibilities for the CVD program should be
well defined before launch of the program to assist with the efficiency of vulnerability intake and processing.
Assignment of responsibilities should include, at a minimum, executive sponsorship, program management, and
vulnerability analysts/validators. Executive sponsorship is advisable so that the program has support and funding
from the manufacturer’s leaders. Program management should be responsible for overseeing vulnerability analysis
and validating that vulnerability intake and validation is performed in accordance with the manufacturer’s procedures
and policies. Vulnerability analysts and validators are responsible for day-to-day operations such as vulnerability
intake, communications with the reporter of the vulnerability, vulnerability validation, and communications with
product or service stakeholders (e.g. developers of compensating controls, customer communication channel
owners) that are affected by the identified and validated vulnerability.
A publicly accessible and secure intake medium such as an online form, website, or email address should be
provided for the reporting of vulnerabilities. CVD program stakeholders should develop an initial list of frequently
asked questions and answers to inform the public of program rules and procedures. As the CVD program matures,
the list should be periodically updated with frequently asked questions and answers to reduce the strain on the
manufacturer’s customer service department. The CVD program should also be properly coordinated and connected
to the intake mechanism for complaints applicable to other of the manufacturer’s medical device. Many customers are
familiar with this established communication channel for identifying security-related complaints so that they can be
routed to the appropriate experts that are tied into the vulnerability analysis and correction process that addresses
those vulnerabilities received from the CVD program. Medical device manufacturers should use secure techniques
(e.g., Open Pretty Good Privacy (OpenPGP)) for exchanging vulnerability disclosure information with independent
security researchers.
Bug bounty program

A growing issue for software developers, including potentially medical device manufacturers, is the sale of
vulnerabilities on black market websites for monetary gain. One way to reduce the risk of vulnerability exploitation is
to establish a bug bounty program. A bug bounty program pays the reporter of a vulnerability a financial sum
dependent on the product or service that the vulnerability affects and the severity of the vulnerability. The program
should define qualifying vulnerabilities and provide a list of submission requirements (e.g., product identification, date
of vulnerability discovery, estimated CVSS score).
If the manufacturer does not have a secure software development life-cycle (SDLC) program, then a bug bounty
program could create an excessive volume of reports for vulnerabilities which would otherwise have been identified
during a software development life-cycle.
A bug bounty program is one option for manufacturers that believe they have achieved an acceptable level of security
maturity. Applicable due diligence should be conducted to establish funding and resources before offering a bug
bounty program.
Other sources of security performance information

Tracking security performance information for medical devices is a large undertaking. Manufacturers may have
thousands of fielded devices across differing HDOs and home networks. As part of the manufacturer's vulnerability
management program, key performance indicators should be captured to provide insight into the operations of the
program. A few key performance indicators that should be considered for collection and reporting include, but are not
limited to:
 percentage of the organization’s fielded products that are currently undergoing active vulnerability
monitoring;
 quantity of high and medium risk vulnerabilities for each product, grouped by business unit;
 the time it takes to create, verify, and validate a fix (or patch) for a vulnerability and the time it takes to install
the patch in fielded devices, including statistics on devices patched or needing patching;
 the incident response time from initial identification to incident close out.
Many sources of security performance information exist from technical information to managerial information (e.g.,
cost). The manufacturer should conduct exercises with applicable stakeholders to identify security performance
metrics that meet business needs.
6.2 Assessment
Any revision to the security risk assessment based on new information should be subject to the same level of control
and review as the initial assessment. This would include any subsequent identification of risk control measures, if
required. Such controls should include review and approval by individuals in the same functions or departments as
those who signed-off originally. Any new security-related observations are to be assessed using the current criteria
for risk acceptability.
Figure 1 shows the basic flow for risk assessment when a new observation has been noted. If the observation is
related to either safety or security, then it should be assessed against the current risk management file to determine if
an update is required. ISO 14971 discusses the criteria for risk management file updates for new safety observations.
For security observations, the risk management file will need updating if
 a new vulnerability has been identified, the estimation of the severity of a previously known vulnerability
changes, a new threat is identified, or the estimation of the severity (e.g., capability, motivation, opportunity)
of a previously identified threat has changed, resulting in a change to the likelihood of device attack,
 the observation includes direct evidence that a vulnerability in the device has been successfully exploited,
 a new or modified risk control measure is required,
 a new or modified compensating risk control measure is required,
 sensitive information from the device has been exposed outside the operational context (e.g., HDO or
home), or
 a vulnerability has been shown that causes the device to become a pivot for attacking other connected
devices and/or computing systems on a shared network.
The new residual risk level should be evaluated against the current risk acceptability criteria to determine if follow-up
action is required. This action can take the form of
 a new safety risk control measure being required,
 a new security control being required, or
 only a security patch being required—a security patch has no adverse effect on the device’s safety and
performance requirements, intended use, or discernable change in the user interface requiring labeling
updates.
In the two cases where new controls are to be introduced, they should be assessed to determine if they introduce
new risks (e.g., new safety control impacts security or vice versa). If so, they should be assessed for necessary
updates to the risk management file.
Preliminary cybersecurity signal risk assessment

Qualified security personnel should evaluate cybersecurity signals to assess their priority and potential applicability to
fielded products. The cybersecurity signal may affect more than one product depending on the components used in
the software and hardware. The performance of a preliminary cybersecurity signal risk assessment will inform the
urgency and subsequent post-release security risk analysis. Potential impact and categorization of the signal are
defined in Table 1.
Table 1—Prioritization of cybersecurity signals
Priority Explanation
Those signals that

 have the potential of a direct and serious potential to cause patient harm including
• death
• an injury or serious deterioration to a patient, user, or other person, including
 a life-threatening illness or injury,
 permanent impairment of a body function,
 permanent damage to a body structure, or
 a condition necessitating medical or surgical intervention to prevent permanent
High
impairment of a body function or permanent damage to a body structure.
 have the potential for simultaneously affecting many devices
 have the potential to affect a large number of sensitive or confidential records within or
across institutions
 represent an actual breach of the security of a medical device that causes
• malfunction or unavailability of the device
• compromise of confidentiality of information managed by the device or
• compromise of security of the institution.
Those signals that have the potential to compromise the integrity or function of a medical
device, thereby leading to
Medium  malfunction or unavailability of the device unlikely to lead to harm,
 compromise of information managed by the device, or
 compromise of security of the institution.
Signals not classified as one of the above two categories should be treated as minor. Such
signals have limited or no impact with a non-significant potential to affect many users. These
signals can result from
Low  false triggers in the associated medical devices or infrastructure,
 investigation or examination of the device or the information supplied with the device or
literature indicating factors that could lead to a non-significant impact, or
 a report of “concern” about the security of a medical device.
Product-specific threat event risk assessment

A product-specific threat event risk assessment involves a determination of risk with respect to a specific product and
any appropriate action to take based on that risk. The assessment the product team performs can result in a change
to the product or potentially no change. If the threat event is assessed as medium or high risk, based on review of the
preliminary cybersecurity signal risk assessment, then a field change or customer communication should occur. If it is
determined that the threat event is low risk, then no immediate action is typically required. The assessment process is
illustrated in Figure 3.
Figure 3—Product-specific threat event risk assessment
When a cybersecurity signal is reviewed within the context of a pre-release product-specific threat event risk
assessment (conducted prior to the fielding of the device), a determination is made as to whether the risk represented
by the signal has been considered and included in the assessment.
Assessing related products (variant analysis)

When a new cybersecurity signal is identified for a device, the manufacturer should consider other devices, either
fielded or in development, that might share the same new security risk because they are variants of similar products
or use the same, or similar, components, including software. If a new class of threats has been identified, or a new
class of attacks is being used, this can also impact other devices that are exposed in a similar way. Those devices
should also be evaluated.
Accurate product SBOMs will make it easier to discover other affected devices with components with potential
security vulnerabilities (see Subclause 3.4) if code is obtained from a third-party code (e.g., operating systems,
common libraries).
If the affected software is developed by the manufacturer, or by organizations contracted by the manufacturer to
produce software, the manufacturer should also consider whether the vulnerability is due to a common design or
coding error that may be repeated in other device software not directly shared with the initial device being assessed.
In such cases, the manufacturer should consider training to increase developer awareness of the impact of that
coding error on device security and incorporate methods to examine for that type of coding error in future software
review procedures. This can include coding standards, training, and the use of code checkers to look for coding
errors.
6.3 Action
As described in ANSI/AAMI/ISO TIR24971:2013, further risk control is required if the assessment phase determines
that the residual risk is unacceptable, and the risk/benefit analysis shows the benefit does not outweigh the risk. For
additional information on the application of risk/benefit analysis see Subclause 6.5 of AAMI TIR57:2016.
If a determination is made that the cybersecurity signal represents a risk that was not previously considered, or the
frequency of this and similar signals indicates that the likelihood was mischaracterized, then the security risk
assessment should be revised. Figure 4 illustrates the overall process for a field change, showing that, over time, the
security risk assessment is modified to reflect the dynamic nature of threats and vulnerabilities.
Figure 4—Field change and security risk assessment revision due to a new cybersecurity
signal
Speed of response
The overall assessment of risk (both safety and security) from the initial observation should be used to drive decision-
making about the speed of the response. Manufacturers that produce devices using commercial operating systems or
code libraries, that require regular security patching from the sources of those components, should consider creating
a regular release schedule. Therefore, the decision between whether the update can wait and be part of the next
scheduled release or if an off-cycle release is required.
Other issues that can impact the response speed decision include
 whether there compensating controls that can be implemented by the user while waiting for the patch to be
released,
 how quickly could the communication of the compensating controls can be communicated,
 how effective the communication is,
 how quickly a patch can be deployed,

 whether the vulnerability increases the likelihood of a compromised device becoming a pivot to attack other
devices in the user’s environment,
 whether the update requires regulatory pre-approval, or
 whether the update requires working with parties outside of the manufacturer (e.g., HDOs, device operator)
for patch implementation.
Software maintenance
Medical devices can require software updates to address potential defects or to add new functionality. The process of
updating medical device software raises a number of security considerations which need to be addressed when
developing and deploying these updates.
6.3.2.1 Patch generation and distribution
Manufacturers should follow software maintenance processes to create and test security software updates. These
controls are generally additional steps in the build cycle.
The method for patch distribution can vary, but distribution should be automated to the greatest extent possible.
Commonly used software update mechanisms include, but are not limited to the following:
 Manufacturer-hosted: Performed through the internet, where a software update is hosted on a manufacturer-
controlled webserver which the device connects to in order to download the update. The medical device’s
connection to the webserver could be partially accomplished via cellular or other wireless technology which
removes any dependence on an HDO network;
 HDO-hosted: An HDO obtains a medical device update from the manufacturer, and then maintains control of
the installation of the approved update via an HDO hosted update server; or
 Local: Delivered physically via storage media (e.g., CD-ROM, DVD, universal serial bus (USB) stick) The
dissemination of the storage media should be controlled strictly and utilize a dedicated removable storage
media to ensure that the media is malware-free
Regardless of the delivery mechanism used, the following important security aspects should always be considered in
the distribution of software updates.
a) Software update mechanisms should verify the authenticity and integrity of a software patch prior to
application.
Integrity verification guards against improper information modification or destruction, and normally includes
ensuring information non-repudiation and authenticity 16. In practice, this means that any software patches
are authorized patches that came from the manufacturer and that they have not been altered. Unauthorized
patches or patches that have been modified can compromise the efficacy of the device and render it unsafe.
They can also result in the unintentional compromise of the security of the medical device through the
introduction of new, unknown vulnerabilities or the intentional compromise of the security of the medical
device with malware. Integrity can normally be addressed with the use of cryptographic techniques such as
code signing and hashed message authentication codes (HMACs). However, HMACs are difficult to secure
because they require a shared secret by the party creating the hash and the party verifying the hash. If the
shared secret resides on the device then it can be compromised by an attacker, allowing the attacker to
create patches that appear to be authentic and unmodified. Therefore, public key cryptographic techniques
such as certificate-based digital signatures are preferred. Use of integrity checks like cyclical redundancy
codes and simple hashes are insufficient to protect against malicious modification.
b) Software update mechanisms should maintain the confidentiality of the software update contents.
Contents of a software update could reveal sensitive information (e.g. details on a third-party database
software used) about the medical device and its design. This information can potentially be used to an
attacker’s advantage. To protect the confidentiality of the software update, cryptographic solutions such as
encrypting the software update during transit or encrypting the software update in storage, prior to when the
update is applied.
c) Software update mechanisms should enforce atomicity.
If the medical device contains multiple software components, then an all-or-nothing updating mechanism
(i.e., atomicity) is recommended. This would require a user to install all portions of an update. For example,
if a manufacturer released an update package that contained an update to the main medical device
application and to a third-party library, then the atomicity property would require that both updates be
installed, or neither, and not allow a user to install only one. This addresses potential compatibility issues
that could arise due to partial updates.
d) Software update mechanisms should enforce monotonicity.
In this context, monotonicity means the prevention of a rollback (i.e. installation) to an older version of a
system software component. Rollbacks can result in malicious actors or uninformed users installing older,
potentially more vulnerable versions of software.
e) Software update mechanism should report back to the manufacturer verification of a successful installation.
Having insight into what version of software updates a fielded system is running can provide a manufacturer
with valuable information around software update adoption.
Based on the device’s communication capabilities, there can be several ways to track delivery and
installation of the updates. If the network configuration and/or security policies at the HDO allows this
connectivity, the update mechanism should pass this information back to the manufacturer. If the device can
wirelessly communicate to the manufacturer, then monitoring can be performed remotely with user’s consent
6.3.2.2 Healthcare delivery organization control variations

Certain aspects of the HDO ecosystem might need to be taken into consideration while dispatching the updates.
Such aspects include but are not limited to: risk management policy of the HDO, support for various update delivery
mechanisms, and HDO policy regarding software updates.
There are several ways for delivering and coordinating updates:

a) For manufacturer-hosted updates, the updates can be distributed in a push or pull mechanism. A push approach
would force updates onto a medical device without any HDO involvement. This is not recommended due to the
potential disruption of patient care it could cause. A pull approach would allow an HDO to update individual devices at
a desired time.
b) For HDO-hosted updates, an HDO would need to operate and maintain a server and update distribution software.
This additional software would provide the HDO control over distribution of the update within their network and a
location to have visibility on the current version of software on each system. Such a framework could, at the HDO’s
tasking, push the update to the medical devices when safe to do so.
c) Physical media installation would require the HDO to use physical means (e.g., CD-ROM, DVD, or USB stick) to
update devices one at a time.
d) Take into consideration the HDO's patient schedules and the time it may take if the medical device is offline.
External communication
Several types of communication paths should be outlined in a manufacturer’s process when a new vulnerability is
identified by a manufacturer. A process should be put in place to guide the types of communication that might be
necessary, depending on the potential (or realized) severity and scope of impact.
Table 2—Types of external communication
Entity Communication content Purpose
Customer Notifications of product field Communication with customers

actions, recall activities, and other about security-related issues
formal communication about should be coordinated with
impacts to products and related existing regulated communication
action expectations and process. Some
regional jurisdictions have
security-specific guidelines (e.g.,
the United States). Specific
considerations should be made
regarding the routing of security-
related notifications to customers
since the recipients who require
these types of notifications are
often different than those receiving
other recall and safety
notifications.
Entity Communication content Purpose
ISAO such as H-ISAC Information about vulnerability Vulnerability information should be

disseminated so that impacted
Affected products stakeholders can be notified. Also,
for vulnerabilities identified in
Impact third-party software, sharing this
Vulnerability characterization (e.g., information can help other
exploitability, existence of exploit, manufacturers identify potential
difficulty) threats to products utilizing similar
software in their products.
Mitigation
Contact details
Government Cyber Emergency Information about vulnerability Vulnerability information should be

Response Organizations, such as disseminated so that impacted
NCCIC ICS in the U.S.A. Affected products stakeholders can be notified.
Impact
Vulnerability characterization (e.g.,

exploitability, existence of exploit,
difficulty)
Mitigation
Contact details
Company website It is recommended manufacturers The company website should

publish detailed security serve as a specific point of contact
advisories with content like that and company position on certain
contained in NCCIC ICS security events as well as
advisories. providing an efficient means of
contact to appropriate staff within
Press releases regarding larger- a manufacturer.
scale global event responses and
updates
Government civil investigation Information on vulnerability Government can assist in

entities such as FBI and DHS in forensic evidence (if requested) responding to global events with
U.S. and impact of suspected criminal malicious intent, particularly if
aspects of incident initiated by nation state.
Assistance is also important if
there is a need for criminal
investigation.
Regulatory agencies Manufactures should follow Regulatory compliance

regulatory guidelines.
Interacting with healthcare delivery organizations

When a medical device system (e.g., medical devices, medical device servers, network infrastructure) security
vulnerability is discovered, HDOs may have multiple personnel and/or entities that need to be notified depending on
the HDO's organizational structure (e.g. single vs. multiple hospitals, top-down vs. federation). There may be
personnel dedicated to medical device security as well. The HDO is responsible for identifying primary point(s) of
contact for communications with manufacturers. When a manufacturer has learned that a vulnerability has caused a
release of patient information or other sensitive organizational data, the privacy officer or other officers within the
HDO may need to be notified as well. Similar to the HDO defining the central point(s) of contact for the manufacturer,
it is highly recommended that the medical device manufacturer provides a central point of contact for the HDO to
reach out to for security specific concerns. These defined communication structures will facilitate expedient and
consistent communication as well as minimize potential miscommunication errors.
Once the HDO point(s) of contact have been notified of a medical device system security vulnerability by the
manufacturer, there may be significant internal coordination by the HDO to fully evaluate and remediate the
vulnerability (in coordination with the manufacturer). This coordination may include departments and personnel within
multiple hospitals and/or enterprise wide including patient care (e.g., physicians or other healthcare delivery staff),
biomedical engineering, radiology, laboratory equipment, connected health, network engineering, network security,
information security, security engineering, database, storage and application development, data center, and server
support teams.
Inventory management
When action needs to be taken to respond to vulnerabilities and threats to deployed medical devices, it is important
that HDOs be able to locate devices in their infrastructure and identify characteristics of such devices such as
software version, patch level, and network configuration. Inventory management systems or asset tracking systems
within the HDO can facilitate determining which medical devices are impacted by the vulnerability and help prioritize
the devices that need immediate attention. Capital equipment inventory can be another source within the HDO for
assisting in locating impacted medical devices. Some vulnerabilities can necessitate coordination between the HDO
biomedical engineering departments, outsourced vendors, IT department, and/or the medical device manufacturer
providing updates or remediation for the vulnerability.
In order to facilitate the use of inventory management, asset tracking, and capital inventory systems in HDOs,
medical device manufacturers should build features into their products that facilitate interoperability with such
systems. It is also prudent for manufacturers to maintain their own inventory of medical devices deployed at HDO
sites. Not all HDOs have the human and technological resources available to track medical device inventory with the
granularity necessary to evaluate and remediate medical device infrastructure vulnerabilities in a timely manner.
Manufacturers can facilitate an expedient remediation by supporting HDOs in the inventory assessment process.
7 Retirement/obsolescence
Figure 5 illustrates phases of the product life-cycle and associated support milestones including end of guaranteed
support (EOGS) and end of support (EOS).
Figure 5—Product life-cycle and support milestones
7.1 General considerations

Maintaining and supporting medical devices is a crucial function of a medical device manufacturer. Maintenance and
support of hardware and software is dependent on several factors, including but not limited to
 hardware availability and driver support,
 third-party software support, including operating systems,
 compatibility issues between hardware and software components over time, and
 technological advances in hardware and software.
Medical device manufacturers should take into consideration the support life-cycle of hardware and software
components that comprise the medical device. To provide comprehensive support for a medical device, the
manufacturer should be able to obtain support from the corresponding hardware and software vendors, by means of
software/firmware updates and patches that address quality, performance, and security concerns.
Given the limited and finite life-cycle of hardware and software, manufacturers should define a support life-cycle that
customers can reference that identifies how long the medical device will be supported and maintained with hardware,
software, and application software updates and patches. Support includes planned and unplanned maintenance
activities in response to changes in the cyber threat landscape that could increase risk to the device.
As illustrated in Figure 5, support should be available until the product reaches the end of guaranteed support
(EOGS) milestone. Support cannot be guaranteed beyond this milestone. Manufacturers may be able to offer limited
support or best effort support, depending upon the medical device, until the end of support (EOS) date is reached. No
support should be expected for any medical device past the established EOS milestone.
Manufacturers should communicate to customers and make public key dates that include how long to expect
guaranteed support, when the device will reach end of guaranteed support and EOS. Proactive communication is
necessary to help customers plan for upgrades to supported devices. Communication should include the following:
a) Direct customer notification should be sent to the persons/distribution lists as identified by the customer and
noted within their service record. Communication of approaching EOGS and EOS dates should take place at
least 18 months prior to these milestones, consistent with the expected end of guaranteed support and EOS
of the device. This notification should be sufficient to allow customers to plan for necessary updates and
upgrades of medical devices prior to EOGS and EOS.
b) Processes should be defined for updating customer contact information, customer records, and medical
device inventory status at least annually. This process should be documented in the sales terms and
conditions. Accurate customer information and install base information are necessary to ensure the timely
and accurate dissemination of information.
c) Public notifications should take place on the manufacturer’s website and identify EOGS and EOS milestones
for each product as they are established and made available to customers.
7.2 Secure disposal

Secure disposal is part of the security lifecycle for medical devices. Medical devices may need different processes for
secure disposal depending on the type of device, manufacturer recommendations, and manufacturer requirements
for end of medical device life processing. In addition, when the medical device requires service, the manufacturer
should establish processes for handling when parts are obsoleted or on replacing parts containing information that
needs secure disposal (e.g., hard drives and other non-volatile memory).
The security risk management plan should describe plans for secure disposal, and the device should be designed
specifically to enable secure disposal. Service instructions should include a procedure for secure disposal and media
sanitization. Manufacturers should provide recommendations or processes for removing patient and organization data
where storage media cannot be removed.
Secure disposal methods are specific to the type of storage media. Secure disposal of media includes shredding in-
house, degaussing, or data removal by vendors specializing in secure disposal. See NIST 800-88 Guideline for
Media Sanitization for additional information. Users of fixed location medical devices such as radiology equipment or
other large medical devices, which can contain hazardous materials, should follow manufacturer recommendations
for disposal. Medical devices may require return to the manufacturer or other contracted vendor for disposal.
Manufacturer instructions should describe how the HDO should securely remove data from the medical device (e.g.,
hard drives or other storage device) before return. In addition, the manufacturer should not assume the HDO properly
followed any sanitization instructions and therefore should treat any media as not sanitized until the absence of
sensitive data can be verified.
Equipment sent back to the manufacturer for disposal should be shipped using trusted carriers. Shipment should
include tracking mechanisms to confirm where the device is located during the shipment process, and when it is
received by the manufacturer. The service contact should contain language on carrier responsibilities for securing the
device during shipment including requirements to notify the HDO if there are issues during shipping such as the
device is lost or stolen.
Freestanding and mobile medical devices (e.g., pumps, monitors, and portable radiology devices) may be serviced by
the HDO biomedical or contract service technicians when the devices are not returned to the manufacturer for
disposal. As in the case of fixed location medical devices, manufacturer instructions should specify the procedure for
securely removing data from the device.
When a storage media part is removed and not intended to be re-used, the HDO should securely destroy the storage
media part, and where destruction is not feasible, securely remove any patient and organizational data residing on
the storage media prior to disposal.
When a medical device is decommissioned and disassembled so parts can be reused within the HDO, special care
should be given to storage media (e.g., hard drives and other non-volatile memory). Storage media parts should be
securely disposed or have patient and organizational data securely removed from the media prior to reuse. If the
storage part is being inventoried by the HDO for reuse in another similar medical device, or will leave the HDO, the
storage part should have any patient or organizational data securely removed from the device prior to inventory or
reuse.
Annex A
(informative)
Sample medical device security policy statements

This annex provides a non-exhaustive list of sample statements that can be incorporated in a manufacturer’s medical
device security policy.
NOTE Since these statements are not intended for use in the context of a standard or technical report, they do not follow the
format prescribed by ISO Directives.
A.1 Medical device security (top-level)

a) The organization has established and will maintain this Medical Device Security Policy to
 protect medical device associated information assets and supporting infrastructure from potential
internal and external threats and hazards,
 protect against reasonably anticipated unauthorized disclosures and uses of the medical device’s
sensitive information (e.g., patient health information, customer information, intellectual property),
 protect against reasonably anticipated internal and external threats and hazards that may result in an
impact to patient and user of the medical device safety, and
 maintain the confidentiality, integrity and availability of sensitive information stored, handled, or
transmitted by the medical device.
b) The organization will establish, document, distribute, and periodically review/update the Medical Device
Security Policy and associated standards, and procedures to support maturity development and comply with
applicable laws, statutory, regulatory, or contractual obligations, industry leading practices, organizational
policies, and audit procedures.
c) The organization will implement medical device security roles, responsibilities, resources, tools,
technologies, and processes needed for the successful implementation of this medical device security
policy.
d) A Medical Device Security leader shall be appointed with the mission and resources to coordinate, develop,
implement, and maintain the medical device security program that implements this policy.
e) The Medical Device Security Policy will be approved by company management, maintained, and made
available by management in accordance with business requirements and relevant laws and regulations.
f) Procedures will be established to review the Medical Device Security Policy at least annually, update it as
needed, and make it available to all colleagues and individuals working on behalf of the organization.
g) A process for managing requests for policy exceptions will be established, documented, and made available.
h) Ad-hoc, supplemental medical device security requirements/guidance will be developed, approved, and
communicated, as needed, between regular policy review/update cycles.
A.2 Medical device security operations
a) Develop and implement a security risk management process that
 identifies medical device security requirements to be built into the design of new devices,
 protects against all reasonably anticipated threats or hazards to the confidentiality, integrity, and
availability of the medical device and sensitive information, and
 manages security risk assessments and technical security testing, mitigation, acceptance, and reporting
and
 controls security risks in third-party components.
b) Develop and implement a threat event and incident handling process that
 monitors industry sources for threat events, including third-party components, and incidents and has
processes in place to triage security.
c) Develop and implement a security education and training process that
 establishes and maintains a medical device security awareness program that communicates security
requirements, industry trends, and other security-related topics to personnel responsible for managing
the security of the organization’s medical devices,
 ensures that security personnel and individuals working on behalf of the organization are informed of
their responsibilities to protect the confidentiality, integrity, and availability of medical devices and
sensitive information,
 directs that security personnel and individuals working on behalf of the organization complete training
within 90 days of hire and at least annually after hire, and
 ensures that supplemental role-based training be provided to security personnel and individuals working
on behalf of the organization who have a specific business need or whose duties involve designing,
developing, or maintaining the organization’s medical devices.
A.3 Supporting security controls and implementation (by organizational function)
a) Access Control shall
 protect the confidentiality, integrity, and availability of the organization's processes, intellectual property,
and other resources used to create and manufacture medical device,
 establish, maintain, document and review/update sufficient controls to restrict physical and logical
access to sensitive information based on a need to know or least privilege basis (i.e., role-based
access), and
 implement physical, technical, and administrative safeguards to protect all forms of electronic media
(e.g., laptops, CD-ROMs, USB drives, disks, tapes) containing sensitive information (e.g., patient data)
from unauthorized access.
b) Human Resources shall
 work with the appropriate organization offices to establish controls that ensure security personnel and
individuals working on behalf of the organization are suitable for the roles for which they are placed and
are trained on their information security responsibilities,
 work within the organization to, define, document, and enforce security roles and responsibilities of
security personnel and individuals working on behalf of the organization, and
 establish, document, review/update, and enforce a formal disciplinary process for colleagues and
individuals working on behalf of the organization who have violated information security policies and
procedures.
c) Contracting and Outsourcing shall
 protect medical devices and information that is generated, accessed, stored, transmitted, processed, or
otherwise handled by external third parties,
 establish and maintain a formal process for engaging and assessing the security practices (i.e., vendor
risk) and security design and implementation (i.e., device risk) that is associated with third parties who
provide services and or medical devices that the organization procures,
 require contractual obligations for reporting and mitigating security vulnerabilities in products (e.g.,
software) or services, and
 terminate business with external third parties who collect, access, store, transmit, process or otherwise
handle organization medical devices and information unless
• the third-party security requirements are reviewed and approved by security staff, or
• a contract is in place stating that the third party has implemented all appropriate administrative,
physical, and technical safeguards.
d) Compliance shall
 ensure that the design, operation, use, and management of medical devices adheres to applicable laws,
statutory, regulatory or contractual obligations, and information security requirements,
 establish and maintain a policy, standards, procedures, and guidance to ensure compliance with
applicable laws, statutory, regulatory or contractual obligations, industry leading practices, and audit
procedures,
 establish processes to address failure to comply with the Medical Device Security Policy and
subsequent standards which can result in disciplinary actions up to and including termination of
employment for colleagues or terminations of contracts for contractors, partners, consultants, and other
entities, and
 verify that technical security requirements, appropriate to the nature of the device level or hazard and
security risk, have been established.
e) Field Service shall
 establish and maintain a program to track medical device sold or leased to HDOs,
 monitor the state of deployed devices through remote services where feasible,
 establish and maintain formal media sanitation policy for secure erasure of sensitive information, and
 ensure that technical security requirements are enforced.
f) Business Continuity shall
 ensure that strategies and plans are in place to counteract interruptions to device operations and to
protect critical device operational processes from the effects of major failures of system components or
disasters and to ensure their timely resumption, and
 establish and maintain a business continuity program to quickly resume device operational activities
and recover information in the event of system failure or other disaster.
g) Systems Engineering shall
 establish and maintain a secure life-cycle design program that incorporates security into the device at
the initial design and requirements stage,
 assign responsibilities for monitoring threat and vulnerability information, and
 conduct risk assessments for legacy devices not beyond EOS and implement extra security controls
(e.g., segmentation) for devices that have reached EOGS and are no longer supported.
Annex B
(informative)
Security risk management for healthcare networks

B.1 Healthcare network monitoring and device identification
Although much can be learned from monitoring traditional IT networks for security risks, clinical networks’ risks are
different from IT risks because of the need to ensure safety. The IT security industry has extensive experience at
creating enterprise tools, but that industry is less familiar with safety critical networks. For this reason, HDOs
traditionally use a risk-based approach to security monitoring because of incidents where clinical engineers have
accidentally impaired hospital operations with security tools designed for enterprise environments rather than clinical
networks. Two-factor authentication as prescribed by the IT department can delay the application of timely care;
automatic application of patches to operating systems or devices, without clinical evaluation of changes, can cause
the device to operate differently than expected in a clinical environment.
In security monitoring, HDOs commonly use both passive and active techniques to measure and assess populations
of medical devices. Passive techniques include traffic flow analysis and device fingerprinting from broadcast/multicast
traffic. Active techniques include management protocols, port scanning, and vulnerability scanning.
The advent of home healthcare and of smaller service-specific clinics means that devices are not always deployed in
protected, IT-managed networks. The management model of remote devices and even devices inside the HDO or
clinic’s network can vary in that the devices may be owned and managed by a third party, or even by the
manufacturer.
B.1.1 Operational context
The manufacturer should also pay attention to the operational context into which the device is to be deployed. To
enumerate a few examples, a device can be deployed in any one of the following operating environments:
a) fixed asset on a private HDO subnetwork;
b) fixed asset on the HDO IT network;
c) mobile asset on a private HDO subnetwork;
d) mobile asset on the HDO IT network;
e) fixed asset in a small clinic, without significant IT security expertise;
f) mobile asset in a small clinic, without significant IT security expertise;
g) fixed or mobile asset in a rudimentary home healthcare environment, with no IT support (e.g., home dialysis,
personal infusion pumps);
h) asset without network connectivity in the normal course of events (e.g., an ambulance or simple Non-
invasive Blood Pressure (NIBP) device in doctor’s office); or
i) health software application running on a generic hardware and software platform.
B.1.2 Design techniques to assist HDOs with device identification
For devices to be properly managed and monitored they need to be identifiable. HDOs can struggle to identify all the
devices on the network, particularly in the day of bring your own device (BYOD). The following design considerations
for manufacturers enable more effective device management for HDOs:
a) When requesting an IP address via DHCP, include the Vendor Class option (option 60) in the DHCP request
and put an unambiguous identifier in the Vendor Class field.
b) Support Network Access Control (NAC) on the device by implementing 802.1x as a supplicant.
c) When offering services via HTTP, include identifying strings in HTTP headers. Similarly, when offering other
text-based services, include version numbers and make/model identifiers in header fields or text banners
(greetings).
d) Respond to SNMP queries on the standard SNMP port (161). Especially, publish the system.sysName.0 and
system.sysDescr.0 variables under the “public” community string.
e) Consider periodically sending beacons to announce the device’s identity. Such protocol options include the
Link Layer Discovery Protocol (LLDP), Cisco Discovery Protocol (CDP), and Simple Service Discovery
Protocol (SSDP).
f) Support TCP port scanning (e.g., Nmap) (both TCP SYN scanning and TCP connect scanning). Be aware
that port scanning has been known to crash medical devices; the device should be thoroughly robust against
this type of scanning. Test thoroughly with port scanners within the manufacturer's testing lab before
release.
g) Support a Universally Unique Identifier (UUID); The device identifies itself using a UUID at startup, and/or on
demand. IEEE 11073 SDC profile (OpenSDC) is based on Device Profile for Web Services (DPWS) which
requires a UUID.
h) Ensure that every product line has an unambiguous name and that each release of the product has a
version identifier. Version identification is essential to management of patches and updates. If the version of
the software cannot be reliably identified, and whether a patch has been applied or not, the patch process is
not in control, and vulnerabilities cannot be reliably mitigated. Product version identifiers also enables HDO
staff to determine if patches are needed.
i) Design network protocols such that endpoints exchange version information. This would include the
category of applications that authenticate using standard protocols (e.g., SSL/TLS).
j) Publish details about how to identify the version of a device by its network traffic.
Generic hardware platforms hosting health software applications should also identify themselves. In this case the
hardware platform and application should both be identifiable. For example, the hardware platform could use the
DHCP or NAC techniques, while the application identifies using HTTP strings or TLS. Ideally, there is a mechanism to
correlate the application identifier to the host hardware identifier so they can be seen as a pair.
Alternatively, if the IT network assumes responsibility for hardware registration and verification, only the application
may need to identify itself as a medical device.
The following table maps these techniques according to effort, applicability to operational context, and level of
security assurance provided by the technique. These techniques could be utilized in most of the operational contexts
listed assuming the technical resources exist—the mappings here are typical.
Table B.1—Identification techniques
Identification technique Manufacturer Operational Level of

effort to context assurance
implement (B.1.1)
1 DHCP low-medium a, b, c, d, e, f, g very low
2 NAC medium a, b, c, d high (if

credentialing)
medium otherwise
3 HTTP headers low (if web server a, b, c, d, e, f, g, i challenge

supported) resp./hash: medium
plaintext: low
4 SNMP low (if SNMP a, b, c, d high if authenticated

already supported)
low otherwise
5 LLDP medium a, b, c, d low
6 Port scan medium a, b, c, d low
7 UUID low a, b, c, d, e, f, g, h, i high if authenticated
Identification technique Manufacturer Operational Level of
effort to context assurance
implement (B.1.1)
low otherwise
8 Version identification low a, b, c, d, e, f, g, h, i low
9 SW BOM medium a, b, c, d, i medium
10 Network protocols medium a, b, c, d, e, f, g, i high if authenticated
low otherwise
11 Network traffic profile medium a, b, c, d, i medium
B.1.3 Asset identification
Whether the device security is managed as part of an HDO network, by the manufacturer, or as a standalone device,
the assets that are to be protected need to be identified. The manufacturer should provide a list of the components of
the medical device which are potentially useful to the HDO in monitoring the effectiveness of security measures. This
list of assets will help to determine the SIEM monitoring that needs to be performed and the Events of Interest (EOI)
that need to be detected and evaluated.
B.1.4 Authorization services
HDOs commonly use centralized authorization services such as Active Directory Domain Services. Tools such as
these allow a device to offload the administration of authorization and role management and to allow use of standard
IT tools for monitoring and logging authorization events.
B.1.5 Structure of healthcare delivery organization networks
HDOs typically divide their host populations into at least three separate networks: clinical networks, general-purpose
networks, and guest networks. Clinical networks typically include only those hosts on which clinical operations
depend, and these hosts are typically given highest priority in cases of congestion. Lowest priority goes to guest
networks, which are typically given access to the Internet but not to any other internal networks. Desktop workstations
and servers often appear on general-purpose networks. Any of these networks can be subdivided.
Clinical networks are often subdivided by modality, with functions such as surgical care and imaging using different
(often segregated) networks. Security teams generally filter incoming and outgoing traffic flows to, from, and between
these subnetworks to block all traffic not required for essential functions. Manufacturers should document their
devices’ typical network behavior so that HDOs can make appropriate changes to network configuration (e.g., firewall
filtering rules).
B.1.5.1 Small HDOs
Small HDOs typically do not have the resources that a large HDO’s IT department can deploy. It is unlikely that such
an organization will have a mature security risk management process, sophisticated network analysis tools, or
intrusion detection systems. They will often rely on the manufacturer to manage the security of the device and to
provide details of vulnerabilities and of updates that need to be applied.
B.1.5.2 Home healthcare environments

It is unreasonable to expect end users in home healthcare environments to perform any configuration or maintenance
tasks related to security. The device may not be remotely accessible, or it may be accessible through the end user’s
Wi-Fi connection with rudimentary or no security in place within the home environment. Monitoring and maintenance,
if performed at all, are typically performed remotely. Clear expectations should be communicated on how end users
may receive help through email or telephone support.
B.2 Security monitors and logging

NIST SP 800-160 stresses the need to continually monitor for security risks and the effectiveness implemented
security risk treatment plans HDOs should not only monitor for undesirable events but also monitor the effectiveness
of risk control measures (e.g., monitoring the state of the firewall, responses to denial of service (DoS) attacks, and
authentication events as a consequence of policies set.
A SANS Institute article “Successful SIEM and Log Management Strategies for Audit and Compliance” instructs “a
single common denominator for all regulations requires that one log all events and review them”. In order to log
events, the device needs to be monitoring assets and activities.
Design features that enable security monitoring and logging are essential to enabling security risk management on
deployed devices. There are also industry compliance expectations that require an audit trail.
Service-oriented Architectures (SOA) present a slightly different challenge as many of the traditional tools (e.g.,
scanners, intrusion detection systems) are not as suitable for evaluating the security posture of a SOA.
NIST SP 800-94 “Guide to Intrusion Detection and Prevention Systems” provides detailed information on types of and
uses for Intrusion detection systems. However, post-processing of security logs can be considered intrusion
detection. Sophisticated HDOs routinely apply machine intelligence to identify intrusions and exploits.
Data gathered as part of a monitoring effort can be used either real-time to generate security status information or as
part of a periodic analysis or audit. Either way, essential feedback is given on the risk management in place.
Manufacturers should take into consideration regional and global privacy regulations when collecting and processing
data. The nature of the data collected, and the processing thereof will be influenced by privacy regulations. Care
should be taken to de-identify or pseudo-anonymize collected data.
B.2.1 Passive monitoring
Passive device fingerprinting relies on identifiable device behaviors and often on correct use of remotely accessible
identifiers. Manufacturers should include appropriate unique identifiers in their devices. Device designers should
assign devices MAC addresses from company-owned MAC range allocations, and they should include appropriate
identifying strings when using network services such as mDNS or DHCP.
Once the assets of a device that require protection from security threats are identified, steps can be taken to monitor
some of these assets, including
 monitoring the performance of a device, which could be compromised by denial of service attacks or
malware, using device resources,
NOTE Flow analysis, or “netflow,” relies on special router features that announce network connections to a centralized
collection point. HDOs often look for characteristic flows when trying to identify networked assets. Device designers
should provide HDOs with documentation of the ports and external services the device expects to use.
 use of devices that can autonomously monitor CPU and memory usage and traffic patterns on interfaces,
and monitoring of the creation, storage, transmission, or removal of PII on the device,
 review of administrative records (e.g., such as user profiles, authentication services, service records),
 and review of monitoring logs, and

 other tools used can include anti-virus applications.
Policy violations should be monitored. Actions to take when a policy is violated will depend on the policy, the severity
of the violation, the intended use of the device, and the current state of the device. For example, lockdown of the
device may not be feasible if it is engaged in life-sustaining activities. All authentication events and data transfers
should be monitored. Monitoring or logging authentication events and data transfer should not impair or disrupt the
medical device’s essential performance.
Periodic archiving and removal of sensitive data on the device is recommended to conform with the HDO's data
retention policies. To facilitate the archiving and cleanup activity, the device should have the capability to log
archiving and cleanup events, whether manual or automated.
The scope of the assets and data to be monitored should be chosen carefully, weighing the overhead and
management of data against the usefulness of that data for predictive or post-event processing. Often it is not a
single monitoring information source but rather the correlation of monitored data that indicates a security issue, and
that facilitates locating the intrusion and the impacted assets. Further design considerations can include malware
monitoring (including anti-virus engines) and intrusion detection. Intrusion detection tools are generally deployed at a
network level rather than on the device itself.
It remains a design decision whether to include the correlation and interpretation of the data as an activity on the
device to facilitate notifications or whether to do it remotely using a SIEM system.
The scope of the monitoring performed and the analysis of the accumulated data will be heavily influenced by the
deployment model, since logging large amounts of data on a device that is rarely connected will not be feasible. An
architecture that supports prioritization of logged events, log rotation, and configurable logs is advisable when a
device is to be deployed in varied environments.
The design should ensure that sufficient storage and bandwidth resources are available for the maintenance and
transmission of the data that is generated from monitoring activities.
A well-formed device risk analysis will likely indicate what monitoring and logging features are required and desirable.
B.2.1.1 Technical recommendations for passive security logging
Essential to detecting threat events is a forensic, tamper-resistant security log. A potential way to achieve this is to
implement an append-only log with authenticated chain of custody. Logging options include
 a dedicated logging sink on the local network with device and system logs streaming to it in real time or
“often” (e.g., every few minutes),
NOTE This should include a built-in alert when logger cannot cope with load or is almost out of storage.
 an off-site logger with requirements similar to the local logging sink above, with a caching or contingency
plan if external connection is unavailable,
 encryption and authentication (e.g., using Merkle trees) for at-rest storage,
 tamper-evident and tamper-resistant hardware,
 meta-log for access to the logger and/or attempts to delete or alter information,
 authentication and authorization system for logger, and
 a change tracking system with attribution and ability to revert.
Device manufacturers should consider a log interface exposed for log collection as distinct from collecting the logs
(see NIST SP 800-92 Guide to Computer Security Log Management). A “standardized” interface for frequent log
export combined with a “black box”-type attachment for devices is recommended.
Log entries should have timestamps relative to the device rather than the network as the timing and sequence of
events has meaning. Other techniques to consider with logging include
 authoritative logger real-time clock,
 best practices (e.g., vector clocks or other strong sequence-preserving techniques), and
 independent timestamping of all messages by sender, preferably using an authoritative logger clock. If the
sender has no real-time clock capabilities, a sequence number can be used.
B.2.2 Active monitoring

Active monitoring entails injecting test data or instructions to the device to ascertain the effectiveness of security
controls. Consider it a controlled experiment where observed results can be compared to expected results. A
common version of this is an application that simulates user activity. The user can be an expected user with a defined
role (e.g., to determine if role-based security measures are operating as expected) or an adversarial user (e.g.,
attempting a brute force password hacking attack or a DoS attack). Other techniques used include port scanning,
vulnerability scanning, and penetration testing.
HDOs, like any enterprise, routinely use port scanning to check for changes in the set of services that networked
hosts are running. Manufacturers should port-scan their own devices under realistic network conditions to ensure that
doing so does not affect device operation. Manufacturers should test their network connected devices using network
scanners under a wide variety of settings to ensure network scanning does not impair the essential performance of
the device. At a minimum, network scanning settings should consider common network activities expected in the
operational context.
Vulnerability scanners are also in common use. These software tools run a barrage of tests for known vulnerabilities.
Device designers should already be using security scanners to test their own products during design phases, but
frequent scanning during all phases of product development should minimize the chance of postmarket problems
attributable to scanning.
These tools tend to be part of the IT network infrastructure and not usually included as a feature on the device.
B.2.3 Security logs
NIST SP 800-92 provides a rich background on security logging including the types of logs, the challenges, and
design and infrastructure issues associated with logging.
The SANS Consensus Policy Resource Community: Information Logging Standard document is a useful checklist for
a designer attempting to decide what needs to be logged.
The data generated from these monitoring activities, often described as security logs, should be protected from
tampering while at rest and during transmission. Other considerations include
a) handling uncertainty in the log data
 known unknowns
When analyzing logged activity, the manufacturer should not ignore events of uncertain or unclear
meaning. If there are log entries or events in the logs that cannot be identified or for which there is no
coinciding incident (e.g., an exploit) or medical event, there may still be an issue, e.g., early indications
of installation of malware that is not activated until months later. Retrieve and analyze the logs regularly
to assure the correct operation of logging and the effectiveness of the filtering.
 unknown unknowns
Periodically reevaluate what is being logged and what can be determined about your device or network
from those logs. Regularly re-evaluate your rules or filters for the logs; Ensure that the data extracted
from the logs matches explicit requirements for auditing or identification. Evaluate whether new rules or
patterns need to be added based on known vulnerabilities or exploits.
b) device-only versus system interaction data
Logs of systems or networks as well as individual device logs are a useful source of information for security
monitoring. Post-processing of device and system logs can be cross-correlated to generate information on
interactions and events that are not obvious at the device level (e.g., man-in-the middle attacks might be
detected in this fashion). Institutions increasingly use machine-learning based tools to obviate the need for
laborious manual correlation of all possible interactions.
c) security data retrieval and use environment
While access to the logs or analytics may be well defined for large HDOs, smaller organizations may have
fewer tools in place and fewer rules around access to logged data. Remote devices in a home healthcare
environment or satellite clinics will still need to be monitored. It is important that the service agreement for
the device includes provision for the security monitoring model. Post-processing may be the only option for
remote devices.
The design should consider the means of access to the data. The solution will differ based on the network
connectivity of the device, the model for processing the data, and the storage capabilities of the device. The device
security logs may be kept on the device, sent periodically to a collection point (log server), or streamed to a log
analyzer for real-time analysis.
Failsafes should exist for events that prevent the device from transmitting the logs upstream. For example, different
categories of threat events can be defined, and retention of higher priority event logs prioritized over logs of lower
category events.
Access to this data should be restricted to the appropriate roles. To facilitate this, and to comply with privacy rules, it
is advisable that security logs remain independent of system and clinical logs, although there may be some events
that fall into multiple logging categories. Logging features need to identify what logged data is for use by the end-
user, and what is for use by manufacturers. It is expected that the majority of security logs would be for the end-user,
and manufacturer’s logs would be limited to service or system logs. A feature that relies on the device “phoning
home” in order to deliver logs to a manufacturer may not satisfy privacy or HDO IT-network rules and should not be
relied upon.
Guides to security log management exist, albeit not specific to medical devices, for example:
a) NIST SP 800-92 Guide to Computer Security Log Management;
b) SANS Consensus Policy Resource Community: Information Logging Standard, 2014; and
c) UL2800-0 DATA LOGGER and DATA STORE Requirements.
B.3 Other Design Features to Support Postmarket Security Risk Management
FDA’s Content of Premarket Submissions for Management of Cybersecurity in Medical Devices [20] provides additional
examples of design features useful to managing security risk in deployed devices:
 Only allow installation of cryptographically verified firmware/software updates. Use cryptographically signed
updates to help prevent unauthorized reduction in the level of protection (downgrade or rollback attacks) by
ensuring that the new update is more recent than the currently installed version.
 Where feasible, ensure that the integrity of software is validated prior to execution, e.g., ‘whitelisting’ based
on digital signatures.
 Implement design features that allow for security compromises to be detected, recognized, logged, timed,
and acted upon during normal use.
 Devices should be designed to permit routine security and antivirus scanning such that the safety and
essential performance of the device is not impacted.
 Ensure the design enables forensic evidence capture. The design should include mechanisms to create and
store log files for security events. Documentation should include how and where the log file is located,
stored, recycled, archived, and how it could be consumed by automated analysis software (e.g. Intrusion
Detection System, IDS). Examples of security events include but are not limited to configuration changes,
network anomalies, login attempts, and anomalous traffic (e.g., sending requests to unknown entities).
B.4 Design pitfalls
Intrusion detection tools and the countermeasures deployed can have a detrimental effect on the intended use of the
device. Tools and countermeasures should be carefully vetted for side-effects.
Prioritizing logging and monitoring to the detriment of intended use is also to be avoided. Logging and monitoring
schemes should be designed such that they do not affect the intended use of the device and are generally not visible
to the user of the device.
In the pursuit of greater security, manufacturers and integrators may be tempted to add multi-factor, role-based
authorizations schemes. Authorization restrictions should not impair availability during intended use. The device
architecture should support varying levels of role-based access where on-demand services are immediately
accessible and others such as log retrieval are only accessible with the correct authorization.
Annex C
(informative)
Establishing a coordinated vulnerability disclosure process

C.1 Process establishment
Medical device manufacturers should develop a robust vulnerability handling and coordinated disclosure processes to
ensure that their products’ residual risk is maintained at an acceptable level throughout the postmarket phase.
Various procedural, communicative, and technical aspects of a well-designed process will assist in meeting this goal.
ISO/IEC 29147:2014 Information Technology—Security Techniques—Vulnerability Disclosure and ISO/IEC

30111:2013 Information Technology—Security Techniques—Vulnerability Handling Processes should be used by
manufacturers as the basis for establishing their own vulnerability handling and responsible disclosure processes.
Figure C.1, taken from ISO 29147:2014 provides a visual representation of how the two processes of vulnerability
disclosure and vulnerability handling are tightly coupled:
Figure C.1—A model of the interface between ISO/IEC 29147 and ISO/IEC 30111
There are two key aspects of a successful vulnerability and responsible disclosure policy:
 established internal process for accepting vulnerability information received from external sources; and
 established external and internal process for effectively communicating to the manufacturer’s customers and
users’ important information regarding recently disclosed vulnerabilities pertaining to the manufacturer’s
medical device products.
C.2 Accepting vulnerability information from external sources

In situations where an external source (e.g., independent security researcher) is attempting to establish contact with
an appropriate information security representative from a manufacturer, the manufacturer’s policy and external
presence (e.g., web site) should be clear and explicit. The appropriate communication channel (e.g., a dedicated
group e-mail and telephone number) should be indicated as the most expeditious manner for the external source to
contact the manufacturer and report the vulnerability. Relying on generic customer support telephone numbers or
email addresses is not optimal and may result in a possible excessive delay in receiving and responding to the
vulnerability. A vulnerability notification directed to an employee not versed in security, the request and source being
transferred between multiple employees, or the request being lost before reaching the correct information security
engineering representative could result in delays or other processing issues. In all of these examples, the external
source reporting the vulnerability could lose confidence in the manufacturer’s process and possibly defer, out of
frustration, to another method such as a pre-emptive public disclosure. In these examples, the manufacturer loses
credibility and forgoes the opportunity to proactively confirm, verify, and mitigate the potential security and/or potential
safety risk to patients
Additionally, by having a streamlined responsible disclosure and vulnerability reporting process, the security program
allows external reporting sources an opportunity to expeditiously provide information on potentially unknown. The
manufacturer should provide clear information to facilitate establishing a cooperative relationship with the vulnerability
reporting source always with the end goal of finding solutions that reduce the risks associated with a vulnerability.
Proactive and actionable activities should include
 direct communications channel to contact the manufacturer (with a secure option provided, such as PGP
enabled e-mail),
 responsible disclosure and vulnerability reporting scope statement providing guidance of the goal of the
disclosure process,
 details on the medical device information to be provided (e.g., product model, product serial number,
configuration details, scenario to reproduce vulnerability),
 request for contact information for the reporting source—including phone numbers, e-mail address and PGP
key,
 expected initial response time to the reporting source,
 specific steps the manufacturer is expected to perform with the information provided (e.g., attempt to
reproduce), and
 manufacturer’s expectations on reporting source’s actions (e.g., recommendation to never perform test on
medical devices in active or clinical use scenarios such as a hospital networked environment).
C.3 Process for communicating to users and reporting known vulnerabilities

When a vulnerability is reported by an external source, the manufacturer should ensure the source is kept informed
as appropriate on planned remediation efforts.
Once a remediation (e.g., compensating control, product update, software patch) is established and successfully
applied by the customers or the manufacturer, the final responsibility of a manufacturer’s vulnerability disclosure
process is to ensure that vulnerability remediation information is disseminated as widely as possible. Depending on
the vulnerability and the architected remediation, this process is divided into two main categories of actions; (1)
customers, and (2) other governmental agencies. With regard to category (1), the list of parties should include
physicians, HDO IT departments, biomedical departments, and patients, where appropriate.
Within category (2), the vulnerability details are written in the form of a vulnerability narrative. In the United States, the
narrative is then reviewed with the US-Computer Emergency Response Team (US-CERT). US-CERT as part of the
Department of Homeland Security (DHS) then will re-assign the proposed vulnerability narrative to the Industrial
Control System (ICS)-CERT. Once the approving authority, in the most general of cases, the NCCIC ICS, located
within the Idaho National Laboratory, approves the agreed upon vulnerability with the manufacturer, then the
vulnerability is released to the SECURE US-CERT Portal for secure access up to 30 days. After 30 days the US-
CERT will release to the general public with a courtesy notification to the FDA.
Additional sources who could potentially report security vulnerabilities to a manufacturer:
 threat information vendors;
 manufacturer's suppliers of software, firmware, hardware;
 US-CERT;
 CVE-Details.com;
 MITRE CWE;
 MITRE CVE;
 NIST NCCoE;
 DHS; and
 other governmental agencies.
C.4 Importance of third-party applications, firmware, and hardware

Another important aspect of a manufacturer’s full life-cycle security support for a product is to ensure that known
common vulnerabilities and exposures that affect third-party software/hardware components are monitored and risk
assessed. Some medical devices contain third-party components which are potentially vulnerable to compromise. It is
critically important that the vulnerabilities of these third-party applications, firmware, and hardware are also accounted
for, tracked, and identified. Whenever possible, vulnerabilities should be remediated via software patch, firmware
upgrade or appropriate compensating control.
Every manufacturer should have a robust process in place to identify the third-party components used in its products,
track vulnerabilities against those components, access the impact of those vulnerabilities to the medical device,
implement appropriate remediation(s), and communicate appropriate information on these details to customers. If
common third-party components are used (e.g., operating systems), it is expected that many vulnerabilities will be
reported to the larger IT community via platforms such as the National Vulnerability Database.
C.5 U.S. FDA recognition of consensus standards (country-specific)

Irrespective of the originating source, a clear, consistent, and reproducible process for intake and handling of
vulnerability information should be established and implemented by the manufacturer. The FDA has recognized
ISO/IEC 30111:2013 Information Technology—Security Techniques—Vulnerability Handling Processes that may be a
useful resource for manufacturers.
Manufacturers should also adopt a coordinated vulnerability disclosure policy. The FDA has recognized ISO/IEC
29147:2014 Information Technology—Security Techniques—Vulnerability Disclosure that may be a useful resource
for manufacturers.
Annex D
(informative)
Mapping of defined terms included in Guidance for Industry and

Food and Drug Administration Staff, Postmarket Management of
Cybersecurity in Medical Devices
Table D.1—Mapping of defined terms
Defined terms—Postmarket
Management of Cybersecurity in ANSI/AAMI/ISO 14971:2007 TIR97
Medical Devices
A. Compensating Controls The terms “compensating controls”, A compensating risk control

A cybersecurity compensating “safeguard”, and “countermeasure” measure is defined as a specific type
control is a safeguard or are neither defined nor used in the of risk control measure:
countermeasure deployed, in lieu of, document. Although “risk control
or in the absence of controls measure” is not defined in Clause 2, 2.1
designed in by a device the term is used throughout the compensating risk control
manufacturer. (additional standard and in the definition of measure
explanation follows) residual risk. compensating control
specific type of risk control measure
deployed in lieu of, or in the absence
of, risk control measures
implemented as part of the device’s
design
NOTE 1 to entry: A compensating risk

control measure could be permanent or
temporary (e.g., until the manufacturer
can provide an update that incorporates
additional risk control measures).
[SOURCE: Guidance for Industry

and Food and Drug Administration
Staff, Postmarket Management of
(2016), modified—The first sentence
of definition IV.A has been
incorporated with changes to clarify
that this type of risk control measure
is not part of the device’s design.
Note 1 to entry has been added to
delineate different types of
measures.]
Medical Devices
B. Controlled Risk The term “controlled risk” is not The term “controlled risk” is not
Controlled risk is present when there defined or used in the document. defined since it represents a state of
is sufficiently low (acceptable) Although “acceptable residual risk” is acceptable residual risk for one type
residual risk of patient harm due to a not defined in Clause 2, the term is of harm (“patient harm”) due to one
device’s particular cybersecurity used in Subclause A.2.6.2. The type of hazard (“security
vulnerability. standard defines residual risk as: vulnerability”).
2.15 The definition of residual risk is

residual risk identical to the one incorporated in
risk remaining after risk control ISO 14971:2007 and AAMI
measures have been taken TIR57:2016.
NOTE 1 Adapted from ISO/IEC Guide

51:1999, definition 3.9.
NOTE 2 ISO/IEC Guide 51:1999,

definition 3.9 uses the term “protective
measures” rather than “risk control
measures.” However, in the context of
this International Standard, “protective
measures” are only one option for
controlling risk as described in 6.2.
C. Cybersecurity Routine The term “cybersecurity routine The term “cybersecurity routine
Updates and Patches updates and patches” is not defined updates and patches” is not defined
Cybersecurity “routine updates and or used in the document. since it represents a specific type of
patches” are changes to a device to Additionally, there are no instances risk control measure applied to a
increase device security and/or of the terms “updates” and “patches” medical device that has acceptable
remediate only those vulnerabilities in the document. residual risk for one type of harm
associated with controlled risk of (“patient harm”).
patient harm. (additional explanation
follows) The definition of residual risk is
identical to the one incorporated in
ISO 14971:2007 and AAMI
TIR57:2016.
D. Cybersecurity Signal The terms “cybersecurity signal” and The definition of a cybersecurity
A cybersecurity signal is any “signal” are neither defined nor used signal is based on the FDA’s
information which indicates the in the document. postmarket guidance expanded to
potential for, or confirmation of, a include threats and threat events:
cybersecurity vulnerability or exploit Clause 9 discusses several sources
that affects, or could affect a medical of information that are available 2.3
device. during the production and post- cybersecurity signal
production phase. information that indicates the
potential for, or confirmation of, a
vulnerability, exploit, threat, or threat
event that affects, or could affect a
medical device
[SOURCE: Guidance for Industry

and Food and Drug Administration
Staff, Postmarket Management of
(2016), modified—The first sentence
of definition IV.D has been
incorporated with changes to add
threat and threat event.]
Medical Devices
E. Exploit The term “exploit” is not defined or The definition of an exploit is based
An exploit is an instance where a used in the document. Annex E on the FDA’s postmarket guidance
vulnerability or vulnerabilities have indicates “P2 is the probability of a but does not include the potential
been exercised (accidently or hazardous situation leading to impact on safety or essential
intentionally) by a threat and could harm.” Similarly, an exploit does not performance:
impact the safety or essential necessarily lead to harm as
performance of a medical device or recognized in the FDA’s definition 2.6
use a medical device as a vector to (i.e., “could impact”). exploit
compromise a connected device or instance where a vulnerability or
system. The standard defines a “hazardous vulnerabilities have been exercised
situation” as: (accidently or intentionally) by a
threat
2.4
hazardous situation [SOURCE: Guidance for Industry
circumstance in which people, and Food and Drug Administration
property, or the environment are Staff, Postmarket Management of
exposed to one or more hazard(s) Cybersecurity in Medical Devices
(2016), modified – Definition IV.E
[ISO/IEC Guide 51:1999, definition has been changed to remove
3.6] language pertaining to potential
impacts.]
NOTE See Annex E for an explanation of
the relationship between “hazard” and
“hazardous situation”.
F. Patient Harm The document includes several The definition of “harm” is identical to
Patient harm is defined as physical instances of “patient harm” but the the one used in AAMI TIR57:2016:
injury or damage to the health of term is not defined. The definition of
patients, including death. “harm” includes “damage to property 2.11
or environment”: harm
physical injury or damage to the
2.2 health of people, or damage to
harm property or the environment, or
physical injury or damage to the reduction in effectiveness, or breach
health of people, or damage to of data and systems security
property or the environment
[SOURCE: IEC 80001-1:2010,
[ISO/IEC Guide 51:1999, definition definition 2.8]
3.3]
G. Remediation The term “remediation” is not defined The term “remediation” is not defined
Remediation is any action(s) taken or used in the document. since it is the act of applying a risk
to reduce an uncontrolled risk of control measure to a medical device
patient harm posed by a device The standard does not distinguish that has unacceptable residual risk
cybersecurity vulnerability to an between action(s) taken when the for one type of harm (“patient harm”)
acceptable level. device is in an “acceptable residual due to one type of hazard (“security
risk” state vs. those applied when vulnerability”).
the device is in an “unacceptable
residual risk” state. In both cases, The definition of residual risk is
the term “risk control measure” is identical to the one incorporated in
used to describe the course of ISO 14971:2007 and AAMI
action. TIR57:2016.
Medical Devices
H. Threat The term “threat” is not defined or The definition of “threat” is identical
Threat is any circumstance or event used in the document. to the one incorporated in AAMI
with the potential to adversely impact TIR57:2016:
the device, organizational operations
(including mission, functions, image, 2.28
or reputation), organizational assets, threat
individuals, or other organizations any circumstance or event with the
through an information system via potential to adversely impact
unauthorized access, destruction, organizational operations (including
disclosure, modification of mission, functions, image, or
information, and/or denial of reputation), organizational assets,
service.18 individuals, or other organizations
through an information system via
unauthorized access, destruction,
disclosure, modification of
information, and/or denial of service
NOTE 1 to entry: Identical to NIST

definition (SP 800-53) with the phrase “or
the Nation” redacted.
[SOURCE: SP 800-53; SP 800-53A;

SP 800-27; SP 800-60; SP 800-37;
CNSSI-4009]
I. Threat modeling The term “threat modeling” is not Threat modeling is briefly discussed,
Threat modeling is a methodology defined or used in the document. but not defined, in TIR57 and should
for optimizing be initiated in the premarket phase.
Network/Application/Internet Security In the postmarket phase, a
by identifying objectives and manufacturer should revise
vulnerabilities, and then defining premarket threat models based on
countermeasures to prevent, or postmarket signals. This term is not
mitigate the effects of, threats to the defined in TIR97.
system.19
J. Uncontrolled Risk The term “uncontrolled risk” is not The term “uncontrolled risk” is not
Uncontrolled risk is present when defined or used in the document. defined since it represents a state of
there is unacceptable residual risk of The terms “mitigation” and unacceptable residual risk for one
patient harm due to inadequate “mitigations” are not used in the type of harm (“patient harm”) due to
compensating controls and risk document. two types of hazards (“inadequate
mitigations. compensating controls and risk
mitigations”).
The definition of residual risk is

identical to the one incorporated in
ISO 14971:2007 and AAMI
TIR57:2016.
Medical Devices
K. Vulnerability The term “vulnerability” is not Annex A of AAMI TIR57:2016

A vulnerability is a weakness in an defined or used in the document. explains a “vulnerability” is generally
information system, system security considered to be a specific type of
procedures, internal controls, human hazard. The definition of
behavior, or implementation that “vulnerability” is identical to the one
could be exploited by a threat. used in AAMI TIR57:2016:
2.34
vulnerability
weakness in an information system,
system security procedures, internal
controls, or implementation that
could be exploited or triggered by a
threat source
[SOURCE: SP 800-53; SP 800-53A;

SP 800-37; SP 800-60; SP 800-115;
FIPS 200]
Annex E
(informative)
Security incident handling and response

E.1 Medical device security incident handling and response
Incident handling and reporting should be an important part of a manufacturer's incident response plan. Security
incidents can take several forms including examples such as
 incidents where harm has occurred,
 incidents where harm is likely if a device is compromised,
 active incidents where device infections are possible through shared vulnerabilities with other third-party
platforms (e.g., WannaCry attack on vulnerable Windows systems),
 incidents where devices are not performing as expected but the evidence of the root cause being a security
exploit has not been proven, and
 incidents where data loss or loss of sensitive information has occurred.
E.2 Incident response preparation

The first and most important component of incident response is preparation, so that when an incident occurs the
incident response team can execute an incident response plan quickly and efficiently. Preparation takes many forms
including policies, coordination plans, communication plans, coordination with external actors, established
procedures, technical resources, and testing that includes wargames and tabletop exercises.
A policy should be established that determines the criteria for what constitutes an incident and who makes the
decision of when to activate the incident response process. Once the determination is made, then the incident
response plan is activated, and various plans and processes are engaged.
Criteria should be established to guide when top management should be briefed on an incident. Depending on the
potential business risk associated with an incident, this can range from communications soon after the business
impact is confirmed to situations where the incident can be summarized after it has been resolved. It is important to
define the risk threshold that drives the speed of communication before an incident occurs. This ensures that
decisions can be made quickly and responsible individuals can be trained. There could be thresholds where the top
management will want to reach out to the board of directors for further communications and input.
Device manufacturers should practice incident response through organizational wargames or tabletop exercises. In
such exercises, someone plans a series of events that unfold as an incident happens, and a set of stakeholders,
ideally those specifically identified as the organization’s points-of-contact and decision makers for incident response,
work together in a room to identify who they would communicate with and what information they would need as the
event unfolds. Such practice, similar to a disaster response exercise for emergency service personnel, helps identify
missing connections and missing elements of the written incident response procedures. Repeating such exercises
periodically with different scenarios helps hone the process and assist new stakeholders in understanding their
responsibilities on what needs to be done.
Periodically, national groups like H-ISAC will coordinate sector-wide national-level or regional-level tabletop exercises
with the intent of performing simulated national-level cybersecurity incident management scenarios. Industry,
regulators, ISAOs, and other cybersecurity related groups like NCCIC ICS will jointly participate in these tabletop
exercises. The knowledge gained from these tabletop exercises are funneled back to all the participants’
organizations.
Typically, these tabletop exercises will provide an opportunity for various stakeholders to practice their responses and
learn from others. Practice and shared experience are important elements of successful response plans. Those
exercises that involve national-level scenarios and stakeholders provide the additional benefit of providing face-to-
face interactions amongst the stakeholders who, otherwise, may interact only in the event of an emergency, which
leaves little margin for error or delay.
Tabletop exercises also provide an important role in training and testing processes developed within an organization
as part of their incident response plan.
E.3 Security incident categories
A security incident can take many forms, and it would be impractical for the manufacturer to develop procedures for
all possible types of security incidents. Instead, it is useful to determine appropriate responses for common incident
categories. Below is a non-exhaustive list of common security incident categories:
 denial of service: an attack that prevents or impairs the authorized use of networks, devices, or applications;
 malicious code: a virus, worm, trojan horse, ransomware, or other code-based malicious entity that
successfully infects a device;
 unauthorized access: a person or malicious process gains logical or physical access without permission to a
network, device or, application;
 inappropriate usage: a person violates acceptable use of any network or computer policies; and
 multiple component: a single incident that encompasses two or more incident categories.
Timely detection and notification of a security incident to affected personnel is crucial in reducing the impact of the
security incident on the manufacturer or its customers. Security incident monitoring is reliant on people, process, and
technology. People should be appropriately trained and knowledgeable on the identification of security incidents and
how to report, handle, and respond to security incidents once identified.
Processes should be designed, developed, and implemented throughout the organization to facilitate consistent and
effective security incident handling and response. When an incident is detected by a party other than the
manufacturer, a mechanism should be established to ensure rapid communication to and from the manufacturer.
Depending on the type of device, its designed services, and the relative technical maturity of the manufacturer and
the HDO, the initial detection of a security incident may be by either organization. Processes should be established
that ensure rapid communication of detected security incidents from manufacturer to HDO and vice versa.
Lastly, technology should be deployed to detect threat events, assist in determining whether the threat event rises to
the level of a security incident, and support the handling of the security incident workflow and response. Technology
solutions that can be implemented to identify threat events include, but are not limited to, anti-virus and anti-malware
detection, application whitelisting, governance, risk management, compliance tools, host-based and network-based
intrusion detection, and a SIEM solution.
E.4 Security incident assessment

A root cause analysis should be performed to determine if the event under review has been properly categorized as a
security incident and represents a confirmed issue. Personnel trained in the discipline and familiar with the product
should be assigned to identify the source of the observed symptoms and determine their cause. Only when cause is
established can the scope and severity of the problem be determined. Once triaging has occurred and validation has
confirmed that a threat event is a security incident, the security incident handling process begins. As part of security
incident handling, the incident first should be classified to determine an appropriate response. A non-exhaustive list of
common security incident classification categories has been identified in the previous subclause. In addition to
identifying the classification category, an assessment should occur to understand the level of risk associated with the
security incident.
When a security incident occurs, and it is determined there is a potential for impact to patient safety (i.e., adverse
event), it should be evaluated in accordance with the manufacturer’s quality processes to determine the effect, if any,
on patient safety and the predetermined quality and performance of any potentially affected products and product-
impacting processes.
E.5 Security incident response execution

Depending on the classification category and risk level, an incident response will be identified. High-risk security
incidents will have the highest priority and should be addressed prior to other lower risk security incidents. In a
scenario where there is more than one high-risk security incident, the incident response team will need to conduct an
assessment to determine prioritization. Once high-risk security incidents are resolved, medium-risk security incidents
will have the next level of priority. Similar to high- and medium-risk security incidents, if there are multiple low-risk
incidents, the incident response team will need to conduct an assessment to determine prioritization.
It is important for the manufacturer to understand reporting requirements such as notifying organizational leadership,
third-party stakeholders, regulators, law enforcement, and the public (including media). Organizational leadership
should be notified immediately by the team that discovers, or receives credible information, that an incident has
occurred. A list should be developed and maintained that outlines legal and regulatory reporting requirements that
need to be met during and post-incident.
Third-party stakeholders (e.g., customers, CERTs, ISAOs/ISACs) and regulators (e.g., the Food and Drug
Administration (FDA)) should be notified per contractual and regulatory requirements, after a root cause has been
determined or if there are legal requirements to report prior to the root cause determination. A manufacturer should
identify and coordinate with local and federal law enforcement officials if the incident is the result of malicious activity
perpetrated by a threat actor. Prior exercising of communication is recommended to understand incident reporting
channels where law enforcement involvement is required. Notifying the public (including media) is dependent upon
local, national, and international laws. A manufacturer should identify their global footprint and should develop and
actively maintain regional requirements for incident notification.
Manufacturers with multiple business units and corporate level security functions should develop communications
and reporting functions so the correct points of contact are identified so when an incident is reported, communications
paths to the affected business and senior management are already identified.
E.6 Internal coordination activities

E.6.1 Internal stakeholders
Once a medical device security incident occurs, the responsible medical device manufacturer or their agents will
need to internally coordinate their response to the incident. Prior to the incident, the manufacturer should proactively
plan for coordination among affected internal stakeholders.
Internal stakeholders may vary based on the device’s intended use and associated technologies used by the device.
Potential internal stakeholders that may be involved with internal coordination for a medical device security incident
include
 legal,
 medical,
 privacy,
 regulatory,
 compliance,
 research and development,
 product engineering,
 product security,
 product risk management team,
 corporate communications,
 information technology (i.e., security and/or network),
 quality,
 customer relationship manager,
 incident coordinator,
 executive leadership, and
 purchasing controls/supplier management.
E.6.2 Deciding how to respond
Deciding how to respond to a medical device security incident is vital to a successful incident recovery outcome and
should be operationalized in advance of an actual medical device security incident. NIST SP 800-61 r2 Computer
Security Incident Handling Guide identifies four phases of security incident handling:
 preparation;
 detection and analysis;
 containment, eradication, and remediation; and
 post-incident activities.
NIST SP 800-61 r2 provides a framework of activities that should be established to create an incident response
capability for an entity (e.g., a medical device manufacturer). It recommends
 creating an incident response policy and plan,
 developing procedures for performing incident handling and reporting,
 setting guidelines for communicating with outside parties regarding incidents,
 selecting a team structure and staffing model,
 establishing relationships and lines of communication between the incident response team and other
groups, both internal (e.g., legal department) and external (e.g., law enforcement agencies),
 determining what services the incident response team should provide, and
 staffing and training the incident response team.

Deciding how to respond occurs during the observation and assessment phase of this life-cycle. Once an incident
has been identified, the manufacturer should assess and confirm whether the incident has potential impact to the
manufacturer’s medical device product(s). After impact to products is confirmed, the responsible party should contact
the product security incident response team (PSIRT)'s governance team and the PSIRT.The PSIRT should consist of
representatives from those business functions that can rapidly respond and create the updates required at a speed
consistent with the severity of the incident. This includes, but is not limited to
 research & development,
 regulatory,
 quality,
 communications,
 manufacturing,
 customer support, and
 sales & marketing.
A cross-functional governance team should consist of leadership that can commit resources and ensure that external
communications and regulatory issues are managed according to the manufacturer’s policy. The team should have
responsibility for
 legal,
 regulatory,
 communications,
 quality,
 compliance,
 research & development leadership, and
 senior leadership.
The PSIRT should classify the incident according to type and potential impact(s) and then responded to these in
order of priority. In the case of multiple security incidents occurring simultaneously, the designated incident
coordinator and the PSIRT will classify the incidents according to their immediate and potential adverse effects and
prioritize recovery and investigation activities according to the severity of these effects.
 If immediate action is required, the manufacturer will begin coordinated incident response activities.
 If immediate action is not required, the incident coordinator should work with the product team to determine
appropriate response actions.
E.6.3 Internal coordination of external communications
NIST SP 800-61 r2 emphasizes the importance of organizations to work together during incident response. A critical
success factor for manufacturers is the advanced planning for coordinating internally any external communications
that arise from the manufacturer’s PSIRT in response to the security incident. PSIRTs need to know, in advance,
which cross-functional coordination should occur before any external communication is made. Having a
communication plan to follow facilitates this process. A communication plan should determine
 how internal and external communications will be reviewed by the appropriate stakeholders,
 the planned frequency of communications between internal stakeholders during the incident,
 how external PSIRT communications will be internally approved and shared in advance with other internal
organizational units,
 the means by which legal, public affairs, regulatory, product security, and executive management are
informed and, if necessary, the mechanism to formally approve the external communication,
NOTE 1 Legal should be involved in any incident response activities/communications associated with law enforcement
activities.
 who is authorized to speak about the incident to external stakeholders and the media, and
 how corporate communications is to release the external communications through the appropriate internal
channels.
NOTE 2 Corporate communications is normally the appropriate internal channel for any external communications to the
media. Corporate communications should be the internal organization responsible for handling any media inquiries.
Documented procedures and guidelines for handling internal coordination of external communications is important, as
are tabletop exercises. Training should reinforce situational awareness of the PSIRT and other affected stakeholders
throughout the entirety of an incident response.
E.6.4 Patch release coordination
Software patch releases are subject to medical device software validation and risk analysis processes. Software
updates (patches) due to security concerns are necessary because they maintain a medical device’s safety and
effectiveness and are intended as mitigations to vulnerabilities. The manufacturer is responsible for patch approvals.
Patch deployment is a shared responsibility between the manufacturer and, where applicable, HDOs and other
affected patients and/or clients.
Based on the circumstances of the software patch, the manufacturer should review applicable regulatory guidance to
determine whether the software patch requires regulatory notification.
Patch releases during a security incident require cross functional coordination between the PSIRT managing the
incident and the product team responsible for the testing, verification, and validation of the patch. Items that require
cross functional coordination include
 configuration management with the SBOM,
 notification of affected stakeholders about the patch release,
 all applicable device quality system and associated processes have been followed,
 timing of the patching deployment is understood by all affected stakeholders, and
 software patches are code signed in such a way as to ensure the patch has not been altered.
E.6.5 Incident response plan (impact and technical analysis)
The primary objective of a security incident response plan is to manage a security incident in a way that limits
damage, increases the confidence of external stakeholders, and reduces recovery time and costs. An additional
objective is to improve efficiency and expedite response activities. Effective incident response plans
 improve decision-making,
 improve efficiency,
 improve internal coordination,
 improve external coordination,
 expedite response activities,
 establish clear roles and responsibilities across the manufacturer, and
 limit damages by preventing further escalation of the incident.
The scalability of the incident response plan can range from a single organizational unit to an entire corporate
enterprise. Typical contents of a security incident response plan should include
 introduction (purpose, use, scope),
 how to use the incident response plan (levels of incident response and escalation points),
 event handling (event types, guides for categorization, suggested actions),
 incident taxonomy (e.g., NIST taxonomy),
 data-classification frameworks,
 performance objectives (for data types and incident types),
 definition of incident response team operating models,
 thresholds for executives to take decisive measures, operating models such as documenting decision rights
for who authorizes contacting law enforcement,
 containment and investigation strategy (how to develop and implement),
 communication plan (customers, media, regulators, and other stakeholders),

 identification and remediation of failure modes (looking for ways the incident response could break down,
then making enhancements under continuous improvement),
 key tools for use during response,
 response plans (plans for each incident type, checklists of key processes, actions, and notifications to be
triggered in the event of a cyberattack, categorized by both incident and asset type), and
 post-incident procedures (evidence retention/evidence preservation strategy, lessons learned, continuous

improvement opportunities).
Bibliography
[1] AAMI TIR57:2016, Principles for medical device security—Risk management
[2] ANSI/AAMI/ISO 14971:2007, Medical devices—Application of risk management to medical devices.

Association for the Advancement of Medical Instrumentation; 2007. Arlington, VA.
[3] ANSI/AAMI/ISO TIR24971:2013, Guidance on the application of ISO 14971. Association for the Advancement
of Medical Instrumentation; 2013. Arlington, VA.
[4] ANSI/AAMI/IEC 80001-1:2010, Application of risk management for IT networks incorporating medical
devices—Part 1: Roles, responsibilities and activities. Association for the Advancement of Medical
Instrumentation; 2010. Arlington, VA.
[5] AAMI/ANSI/IEC, TIR 80001-2-2:2012, Application of risk management for IT networks incorporating medical
devices—Part 2-2: Guidance for the disclosure and communication of medical device security needs, risks and
controls. Association for the Advancement of Medical Instrumentation; 2012. Arlington, VA.
[6] FDA, Postmarket Management of Cybersecurity in Medical Devices.

https://www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm482022
.pdf (Accessed 06 February 2018)
[7] HIMSS/NEMA Manufacturer Disclosure Statement for Medical Device Security (MDS2).
http://www.himss.org/resourcelibrary/MDS2
[8] IEC TR 80001-2-8:2016, Application of risk management for IT-networks incorporating medical devices—Part
2-8: Application guidance—Guidance on standards for establishing the security capabilities identified in IEC
TR 80001-2-2
[9] NIST SP 800-61 Rev. 2, Computer Security Incident Handling Guide
[10] NIST SP 800-94, Guide to Intrusion Detection and Prevention Systems (IDPS)
[11] NIST SP 800-92, Guide to Computer Security Log Management
[12] NIST SP 800-53 Rev. 4, Security and Privacy Controls for Federal Information Systems and Organizations
[13] NIST SP 800-88 Rev. 1, Guidelines for Media Sanitization
[14] NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments
[15] NIST SP 800-160 Volume 1, Systems Security Engineering
[16] NIST NISTIR 7298, Rev. 2, Glossary of Key Information Security Terms, May 2013.
http://nvlpubs.nist.gov/nistpubs/ir/2013/NIST.IR.7298r2.pdf
[17] SANS Consensus Policy Resource Community: Information Logging Standard, 2014
[18] Best Practices: Event Log Management for Security and Compliance Initiatives. Ipswitch Inc. 2010
https://www.ipswitch.com/Ipswitch/media/Ipswitch/Documents/Resources/Whitepapers%20and%20eBooks/EL
M_Security_WP.pdf?ext=.pdf
[19] “Successful SIEM and Log Management Strategies for Audit and Compliance”; SANS Institute, 2010
[20] FDA, Draft Content of Premarket Submissions for Management of Cybersecurity in Medical Devices.
https://www.fda.gov/regulatory-information/search-fda-guidance-documents/content-premarket-submissions-
management-cybersecurity-medical-devices-0 (Accessed 04 June 2019)

AAMI+TIR97-2019+(R2023)

Uploaded by

Copyright:

Available Formats

AAMI+TIR97-2019+(R2023)

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AAMI+TIR97-2019+(R2023)

Uploaded by

Copyright:

Available Formats

Technical

Advancing Safety in Health Technology

Principles for medical device security—Postmarket

Approved 27 September 2019 and reaffirmed 31 January 2023 by

Keywords: medical device, information security, risk management, postmarket

© 2019 by the Association for the Advancement of Medical Instrumentation

All Rights Reserved

Printed in the United States of America

Association for the Advancement of Medical Instrumentation

Cochairs: Geoffrey Pascoe

Members: AJ Aspinwall, Norton Healthcare

iv © 2019 Association for the Advancement of Medical Instrumentation ■ AAMI TIR97:2019

© 2019 Association for the Advancement of Medical Instrumentation ■ AAMI TIR97:2019 v

vi © 2019 Association for the Advancement of Medical Instrumentation ■ AAMI TIR97:2019

ANSI/AAMI/ISO TIR24971:2013/(R)2016 Medical devices—Guidance on the application of ISO 14971 describes a

 observation and transmission (Subclause 4.2);

 assessment (Subclause 4.3); and

 action (Subclause 4.4).

Supporting annexes contain the following:

Principles for medical device security—Postmarket

 developing a coordinated vulnerability disclosure process;

 implementing processes to manage device security patching; and

 planning for device retirement.

2 Terms and definitions

NOTE Adapted from IEC 60601-1:2005, definition 3.4.

[SOURCE: ISO 14971:2007, 2.1]

© 2019 Association for the Advancement of Medical Instrumentation ■ AAMI TIR97:2019 1

2 © 2019 Association for the Advancement of Medical Instrumentation ■ AAMI TIR97:2019

[SOURCE: ANSI/AAMI/ISO 14971:2007, definition 2.5]

[SOURCE: ANSI/AAMI/ISO 14971:2007, definition 2.7]

© 2019 Association for the Advancement of Medical Instrumentation ■ AAMI TIR97:2019 3

[SOURCE: ISO/IEC 80001-2-2: XXXXXXXXX]

3 Postmarket considerations for security policies and security program

3.2 Coordinated vulnerability disclosure

3.3 Information sharing

4 © 2019 Association for the Advancement of Medical Instrumentation ■ AAMI TIR97:2019

3.4 Communication of security capabilities

4 Design features for postmarket security risk management

5 Installation and configuration

© 2019 Association for the Advancement of Medical Instrumentation ■ AAMI TIR97:2019 5

5.2 Security utility updating

5.3 Other considerations for security maintenance in the clinical environment

6 Postmarket management of fielded devices

6 © 2019 Association for the Advancement of Medical Instrumentation ■ AAMI TIR97:2019

 observation and transmission;

© 2019 Association for the Advancement of Medical Instrumentation ■ AAMI TIR97:2019 7

 a report of a security vulnerability from a third party,

 new threats and vulnerabilities detected through threat intelligence,

 customer questions regarding the security of the device, and

 vulnerabilities detected internally by the manufacturer or product team.

Figure 2—Cybersecurity signal handling process

 the origin, date, time of the signal,

 technical information about the details of the event,

8 © 2019 Association for the Advancement of Medical Instrumentation ■ AAMI TIR97:2019

6.1 Observation and transmission

6.1.1.1 Supplier monitoring

 reviewing trade publications and product-related bulletin boards for information.

6.1.1.2 Vulnerability monitoring

 vulnerability databases such as National Cybersecurity Communications Integration Center Industrial

 security information from subcontractors; and