The topic of cybersecurity for medical devices has steadily grown since 2001.  In that year, after September 11, there were a number of technically philosophical talks and papers warning that cyber terrorism, later dubbed cybersecurity could become an issue for medical devices.  At the time it was considered to be of mild interest, but few imagined that anyone could be so twisted as to attack hospitals or life saving devices.

 

With increased interest in the topic, there has been an increasing number of regulatory guidance documents, standards, and technical reports made available.  Not only has regulatory interest level changed rapidly, but the technology behind cybersecurity is constantly and rapidly changing.  The result is that we can easily get lost in “too much help” in the available literature.  The goal of this paper is to select a few of the more important documents on the topic, and give some background on each document, provide an easy link to download the document, and help the newly interested understand which document or documents are important to the task at hand.

 

The cybersecurity papers in the table below are divided into the following groups:

• Regulatory Guidance Documents
• Regulatory Summaries and Recommendations
• Government Technical Reports
• Industry Standards

 

Regulatory Guidance Documents

 

These are perhaps the most important with which to be familiar.  They are not requirements, just guidance, but most of us know that FDA guidance has a way of being treated as requirements.

 

Soon after 9/11, malware started showing up in hospitals.  Not many devices were connected to the Internet directly or indirectly at the time, so most of the FDA concern was focused on enterprise level devices such as PACS (picture archiving and communication system).  There was a conflict between the FDA validation requirements for changing device software and the need to install anti-virus software patches and updates in a timely manner.  The 2005 guidance, Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software addressed the issue with this software which was mostly OTS software.  

 

Nine years went by.  A number of papers were published on the ease of hacking into medical devices with embedded software.  The same pattern developed.  These papers were met with mild curiosity (most medical device engineers knew it was simply because there had been no thought of designing devices to be secure).  But soon it became evident that it was more than theoretical that devices could be attacked.  

 

In response, the FDA, in 2014, issued the Content of Premarket Submissions for Management of Cybersecurity in Medical Devices.  This guidance was the first to recommend that device design and development activities should consider manage cybersecurity before the devices were released to market.  This guidance, though somewhat behind the times, is still in effect today.

 

Two years later in 2016 the Postmarket Management of Cybersecurity in Medical Devices was released by the FDA in recognition of the fact that cybersecurity is not a static target.  The threats change daily, and worse, they are different from software “bugs” that are design flaws that eventually manifest in the field as they are slowly discovered.  Cybersecurity vulnerabilities are like intelligent “bugs” that never completely go away because somebody is always looking for a way in.

 

A revised version of the 2014 Premarket guidance was floated in draft form for comments in 2018.  The feedback from industry was so voluminous that the agency decided to retract the draft version and completely rewrite the guidance.  The 2018 version is no longer available on the FDA website and should not be used if you happen to have an archived copy.

 

The new improved 2022 draft version of  the Cybersecurity in Medical Devices: Quality System Considerations and Content Premarket Submissions was just released for public comment in April, 2022.  As the title implies, it is an updated version of the premarket guidance and has been broadened to encompass Quality System implications.  From the Background section of this guidance: “The recommendations contained in this guidance document, when finalized, are intended to supplement FDA’s “Postmarket Management of Cybersecurity in Medical Devices,” “Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software” (2016) and “Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices.”  When finalized, this guidance will replace the final guidance “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices. (2014)”

 

Regulatory Summaries and Recommendations

 

The Digital Health Center of Excellence – Guidances with Digital Health Content website is not so much a locus of new material but is a complete listing of all FDA materials that in any way are focused on, or even mention Digital Health (which is to say device software).

 

The Digital Health Center of Excellence – Cybersecurity website is similar in the sense that there is little new content on the page, but it is a good site for current events, news, white papers, reports, and guidances including some from outside the FDA.

 

Government Technical Reports

 

Cybersecurity concerns obviously are not limited to the medical device industry.  In fact, there is a school of thought that cybersecurity should be regulated, monitored, and guided by a centralized government agency.  Who knows whether that will ever happen, but certainly there is a lot of “cross-pollination” going on between industry sectors when guidances, standards, and reports are written.  

 

The closest thing to a centralized authority on cybersecurity right now is the National Institute of Standards and Technology.  Their documents on this topic are detailed and professional.  They get into the “how to’s” more than the FDA guidances which are more “must do’s” and more generic narrative on the subject.

 

Of particular interest, the Security and Privacy Controls for Information Systems and Organizations reads like a checklist or encyclopedia of controls for protecting data.  From the abstract:

 

This publication provides a catalog of security and privacy controls for information systems and organizations to protect organizational operations and assets, individuals, other organizations, and the Nation from a diverse set of threats and risks, including hostile attacks, human errors, natural disasters, structural failures, foreign intelligence entities, and privacy risks. The controls are flexible and customizable and implemented as part of an organization-wide process to manage risk. The controls address diverse requirements derived from mission and business needs, laws, executive orders, directives, regulations, policies, standards, and guidelines. Finally, the consolidated control catalog addresses security and privacy from a functionality perspective (i.e., the strength of functions and mechanisms provided by the controls) and from an assurance perspective (i.e., the measure of confidence in the security or privacy capability provided by the controls). Addressing functionality and assurance helps to ensure that information technology products and the systems that rely on those products are sufficiently trustworthy

 

Also of interest, the Framework for Improving Critical Infrastructure Cybersecurity V1.1 proposes a framework for implementing cybersecurity risk management.  From its Executive Summary:

 

While this document was developed to improve cybersecurity risk management in critical infrastructure, the Framework can be used by organizations in any sector or community. The Framework enables organizations – regardless of size, degree of cybersecurity risk, or cybersecurity sophistication – to apply the principles and best practices of risk management to improving security and resilience. 

 

The Framework provides a common organizing structure for multiple approaches to cybersecurity by assembling standards, guidelines, and practices that are working effectively today. Moreover, because it references globally recognized standards for cybersecurity, the Framework can serve as a model for international cooperation on strengthening cybersecurity in critical infrastructure as well as other sectors and communities.

 

These documents will take some interpretation for applicability to medical devices, but it will be easier than starting from scratch.  The NIST website for cybersecurity framework has a number of supplementary training materials and documents on the topic.

 

Industry Standards

 

There are three Underwriters Labs (UL) standards related directly to cybersecurity in medical devices.  The collection is often just referred to as UL-2900, but in fact, there are three that are specific to medical devices:  2900-1, 2900-2-1 and 2900-2-3.  There are one or two others in the 2900 series, but they are only peripherally related to medical devices.  The UL-2900 series has been recognized by the FDA as an acceptable standard the design and test of cybersecurity features in medical devices.  

 

The Scope sections for each of the three UL standards is copied below as a quick reference for the intent and content of each of the standards;

 

UL 2900-1  Outline of Investigation for Software Cybersecurity for Network-Connectable Products

 

Part 1: General Requirements

 

“1.1 This standard applies to network-connectable products that shall be evaluated and tested for vulnerabilities, software weaknesses and malware.

1.2 This standard describes:

1. a) Requirements regarding the software developer (vendor or other supply chain member) risk management process for their product.
2. b) Methods by which a product shall be evaluated and tested for the presence of vulnerabilities, software weaknesses and malware.
3. c) Requirements regarding the presence of security risk controls in the architecture and design of a product.

1.3 This standard does not contain requirements regarding functional testing of a product. This means this standard contains no requirements to verify that the product functions as designed.

1.4 This standard does not contain requirements regarding the hardware contained in a product.”

 

UL-2900-2-1  Software Cybersecurity for Network-Connectable Products, Part 2-1: Particular Requirements for Network Connectable Components of Healthcare and Wellness Systems

 

“1.1 This security evaluation standard applies to the testing of network connectable components of healthcare systems. It applies to, but is not limited to, the following key components:

1. a) Medical devices;
2. b) Accessories to medical devices;
3. c) Medical device data systems;
4. d) In vitro diagnostic devices;
5. e) Health information technology; and
6. f) Wellness devices.; and
7. g) All software components used for the secure operation of the device, wherever they may reside, including remote assets.

Note – Combinations of the technologies listed here may be applied to such solutions as “telemedicine,” where a single solution may contain both regulated and unregulated components.”

 

UL-2900-2-3  Standard for Software Cybersecurity for Network-Connectable Products, Part 2-3: Particular Requirements for Security and Life Safety Signaling Systems

 

“1.1 This security evaluation standard applies to the evaluation of security and life safety signaling system components. It applies to, but is not limited to, the following products:

1. a) Alarm Control Units;
2. b) Network-Based Intrusion Detection System;
3. c) General Purpose Signaling Units;
4. d) Digital Video Equipment and Systems;
5. e) Mass Notification and Emergency Communication / Evacuation Equipment and Systems;
6. f) Control servers;
7. g) Alarm Automation System Software;
8. h) Alarm Receiving Equipment;
9. i) Anti-Theft Equipment;
10. j) Automated Teller Machines;
11. k) Fire Alarm Control Systems;
12. l) Network Connected Locking Devices;
13. m) Physical Security Information Management (PSIM) Systems;
14. n) Smoke Control Systems;
15. o) Smoke / Gas / CO Detection Devices;
16. p) Audible and Visual Signaling Devices (fire and general signaling);
17. q) Access Control Equipment and Systems; and
18. r) Smart Locks.

 

1.2 This standard does not contain general requirements that are intended to address functional testing of the product unless expressly specified.

 

1.3 This standard also describes requirements for the product risk management process carried out by the vendor of the product, including a list of security controls that the product (or the vendor, as applicable) shall comply with unless a risk assessment done by the vendor shows that the risk of not implementing one of these security controls is acceptable.”

 

	Release	Source	Title
Regulatory Guidance Documents
1.	2005	FDA	Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software
2.	2014	FDA	Content of Premarket Submissions for Management of Cybersecurity in Medical Devices
3.	2016	FDA	Postmarket Management of Cybersecurity in Medical Devices
4.	2018	FDA	DRAFT Content of Premarket Submissions for Management of Cybersecurity in Medical Devices –Retracted
5.	2022	FDA	DRAFT Cybersecurity in Medical Devices: Quality System Considerations and Content Premarket Submissions  – DRAFT (as of May 1, 2022)
Regulatory Summaries and Recommendations
6.	2022	FDA	Digital Health Center of Excellence – Guidances with Digital Health Content
7.	2022	FDA	Digital Health Center of Excellence – Cybersecurity
Government Technical Reports
8.	2020	NIST	Security and Privacy Controls for Information Systems and Organizations – NIST Special Publication 800-53 Rev. 5
9.	2018	NIST	Framework for Improving Critical Infrastructure Cybersecurity V1.1  (2018)
Industry Standards
10.	2017	UL	UL 2900-1 – Outline of Investigation for Software Cybersecurity for Network-Connectable Products Part 1: General Requirements – $$$
11.	2017	UL	UL 2900-2-1 – Software Cybersecurity for Network-Connectable Products, Part 2-1: Particular Requirements for Network Connectable Components of Healthcare and Wellness Systems – $$$
12.	2020	UL	UL 2900-2-3 – ANSI/CAN/UL Standard for Software Cybersecurity for Network-Connectable Products, Part 2-3: Particular Requirements for Security and Life Safety Signaling Systems – $$$