One of the major pillars of the current Industry 4.0 is Automation. Indeed, technology is intervening in almost every domain to “automate” the workforce and make human life easier and better. In the present age, machines are getting integrated with the Internet of Things, Cloud Computing, and Artificial Intelligence with the data flow being transferred and processed via the Internet. These changes indeed catalyze the overall productivity, but also expose data to the public domains. In cases of continuous data transfers and exposition, Cybersecurity becomes a pivotal element where it not only protects the data but also proactively provides mechanisms to defend against malicious attacks and malware. In the case of medical devices that include sensitive medical data flows and software-controlled hardware devices like heart implants or Continuous Glucose Monitoring (CGM) devices, Cybersecurity becomes an important factor for contributing towards system safety and quality...

2. Understanding Cybersecurity in Medical Devices and Applications
1. Introduction
One of the major pillars of the current Industry 4.0 is Automation. Indeed, technology is
intervening in almost every domain to “automate” the workforce and make human life easier and
better. In the present age, machines are getting integrated with the Internet of Things, Cloud
Computing, and Artificial Intelligence with the data flow being transferred and processed via the
Internet. These changes indeed catalyze the overall productivity, but also expose data to the public
domains.1
In cases of continuous data transfers and exposition, Cybersecurity becomes a pivotal
element where it not only protects the data but also proactively provides mechanisms to defend
against malicious attacks and malware. In the case of medical devices that include sensitive
medical data flows and software-controlled hardware devices like heart implants or Continuous
Glucose Monitoring (CGM) devices, Cybersecurity becomes an important factor for contributing
towards system safety and quality. To ensure that medical devices, software, and applications (web
or mobile-based) are safe and effective before releasing them in the market, FDA mandates
Cybersecurity measures be implemented to protect against cyber-attacks. Also, the FDA mandates
that medical device manufacturers be compliant with the industry-accepted Cybersecurity
protocols.2
In this paper, we begin by specifying the vulnerabilities identified in the medical systems.
The vulnerabilities include the potential data access points which later might be identified by
patients, clinicians, device manufacturers, or cybersecurity/software engineers as the points of data
breaches. The later part of the paper discusses the recent attacks in the field of healthcare and
medical services. In the next key section of the paper, we provide the guidance methodologies for
pre and post device submission which includes the steps taken by the device manufacturers and
software engineers if they identify a threat in the system after the product is live, or if the system
has suffered a cyber-attack. The same section also includes the cybersecurity standards accepted
by the FDA. Before concluding the paper, we outline strategies that may be used to mitigate
Cybersecurity risks which also include the roles and responsibilities of device manufacturers,
patients, health care personnel, software developers, and the FDA to ensure data security and
patient safety.
2. Vulnerabilities in Medical Devices & Software Applications
Vulnerabilities can be defined as the data access points through which computer malware,
worms, or viruses can be injected. These malicious elements are small, scripted code snippets
which function to disrupt the normal functioning of a computing system, such as filling the server
with continuous iterative request calls, which overloads the server outside its handling capacity
and eventually crashes the machine. In some cases, these viruses may also function to block certain
functionalities like permanently changing device and system access passwords.
It is vital to understand the access points in medical devices and applications since
proactively securing and isolating them will prevent the very first step that is showcasing the data.
One of the platforms currently all applications and devices are migrating to is the Internet of Things
(IoT). In IoT, devices speak to one another via data transfer and automate the software process
with help of sensors and communication tools like Bluetooth, Radio Frequency (RF) Tools, Zigbee

3. [which is a communication tool for devices placed in proximity], LAN based networks, and in the
end, the Internet.
Bluetooth has revolutionized the way devices communicate and is actively used as a data
transfer tool in almost every computing device. But it is also one of the devices which makes the
entire system most vulnerable. If the latest Bluetooth firmware and updates are not installed, it
makes devices highly vulnerable as hackers can access these tools using a technique called
“Bluebugging”. If hackers access a Bluetooth-enabled device using Bluebugging, they have
complete control of the device. Such devices include examples like Bluetooth-based printers,
cameras, vehicles, and remotely controlled machines.3
Another major vulnerability is using information systems locally with outdated
technologies. Examples of information systems include Hospital Management Systems and data
repositories such as Blood Banks and Organ Preservation Repositories. If attackers get access to
one of these systems, they can relay attacks to other connected information systems. These attacks
may be induced by clicking malicious email links or keeping the system active without secured
sessions. One of the similar reasons for vulnerability is using old pieces of hardware, software,
middleware, and firmware.4
New or current devices may include frameworks to secure themselves
against the latest viruses, but with old systems installed, they may not even possess the mechanism
to understand new malware and viruses, which results in the system getting attacked and hampered
in terms of functionality.
3. Real Cases of Cyberattacks & FDA Concerns in Medical Devices and Applications
On June 18, 2018, the Fetal Diagnostic Institute of the Pacific was hit by a ransomware
attack which breached the data of 40,800 patients. An employee of Philadelphia-based Blue Cross
hospital exposed online the data of 16,762 patients by uploading the patient data file to a public
website. In Orlando, at the Orlando Orthopedic Center, a third-party software upgrade resulted in
exposing data of 19,101 patient records for two months. A Missouri-based Blue Springs Family
Care stated that they suffered a data breach of 44,979 patient records after hackers peppered the
provider with a variety of malware, including ransomware.6
In 2020, Netwalker, a ransomware
operator that threatens to publish data online if ransoms aren't paid, hacked Springfield, Pa.-based
Crozer-Keystone Health System and tried to auction it’s data online. Houston based Harris Health
System reported the loss of 2,298 patient records. In June 2020, the Florida orthopedic group was
hit with a $99M lawsuit due to personal patient data exposure because of a malware attack.5
The
most recent incident recorded was by the University of California San Francisco stating they paid
$1.14 million to hackers after a June 1, 2020 ransomware attack on servers blocked access to their
medical school's computer systems.6
In 2013, the FDA started observing and reporting cybersecurity concerns in medical
devices and applications. In the 2020 safety communication section, FDA posted the case of the
“SweynTooth” vulnerabilities which are 12 risks identified in Bluetooth Low Energy-based
devices that may crash the device, add interference in working, or allow access to an unauthorized
user. The manufacturers affected by such attacks include Texas Instruments, NXP, Cypress, and
many more. In January 2020, the FDA raised awareness in GE’s Healthcare Clinical Information
Central Stations and Telemetry Servers which are used mainly in health care facilities for
displaying information, such as the physiologic parameters of a patient (temperature, heartbeat,
blood pressure), and monitoring patient status from a central location. In October 2019, 11

4. vulnerabilities, named “URGENT/11” were recorded by a security firm in the third-party off-the-
shelf software component IPnet, a tool that supports network communications between computers.
These vulnerabilities may allow anyone to remotely take control of the medical device and change
its function, causing a denial of service, or causing information leaks with logical flaws. The FDA
also expressed concerns for the Medtronic MiniMed insulin pumps (unauthorized access through
the wireless network to control pump activities, June 2019), Medtronic cardiac implantable
cardioverter defibrillators (ICDs) or cardiac resynchronization therapy defibrillators (CRT-Ds) (
they do not use any kind of encryption, authorization, or authentication which may lead to
unauthorized access)7
, and Abbott’s implantable cardiac pacemakers (unauthorized access to
program commands in the implanted pacemaker, August 2017).8
Even though device manufacturers and software engineers are always working on patches,
which are programs developed to repair software components, device manufacturers are now
engaging in proactive activities and using frameworks to secure devices and applications based on
the history of cybersecurity attacks and the concerns expressed by the FDA. The following section
describes the standard Cybersecurity protocols and frameworks that device manufacturers should
meet to be compliant with the FDA regulatory requirements.
4. Cybersecurity Protocols Recommended by the FDA
There are specific standards given by the International Organization for Standardization (ISO),
International Electrotechnical Commission (IEC), and the Association for the Advancement of
Medical Instrumentation (AAMI) that the FDA approves and encourages developers to utilize
while implementing a Cybersecurity framework. The selected framework should meet these
standards, which should also be documented during the pre-market submission for FDA approval.
Some of the standards include:
4.1 ISO/IEC 81001-1 and IEC 80001-5-12
ISO/IEC 81001-1 relates to the Health software and health IT systems safety, effectiveness, and
security – Part 1: Foundational principles, concepts, and terms, and IEC 80001-5-1 relates to the
Safety, effectiveness, and security in the implementation and use of connected medical devices or
connected health software – Part 5: Security – Part 5-1: Activities in the product lifecycle.
Both standards provide the terminology and an in-depth definition of components while designing
a healthcare system. ISO/IEC 81001-1 provides the definitions for significant actors and
components in the software lifecycle process including customer, developer, hazard, hazard
management, residual risk (risk remaining after risk control), risk management, control,
assessment, root cause, vulnerability, and weakness. The terminologies given by this standard can
be used as a reference mechanism while designing and implementing a Cybersecurity framework.
IEC 80001-5-1 provides the actual measures that manufacturers should include in the designing,
development, verification, and validation phases.
4.2 IEC 60601-4-5 Guidance and interpretation – Safety-related technical security
specifications for medical devices2
The standard family IEC 60601 is mostly applicable to medical electrical devices with IEC 60601-
4-5 being an exception. This standard applies to all medical products that are integrated into IT

5. networks, affecting Software as a Medical Device (SaMD). The standard provides three types of
security level (SL) requirements:
• SL-T: The Target Security Level - for medical devices and networks to achieve the set
protection goal.
• SL-C: The Capability Security Level – for medical devices and networks while improving
IT security.
• SL-A: The Achieved Security Level, the level one achieves.
At each security level, IEC 60601-4-5 proposes five levels, from SL 0 (nothing implemented) to
SL 4, the highest level. The security levels help control the requirements and expenses of IT
security. The following table provides an example of the mapping between the aspects of security
requirements and the corresponding security levels:
Security Requirements SL0 SL1 SL2 SL3 SL4
VPNs No No Yes Yes Yes
Basic Form/ Interface Validation Yes Yes Yes Yes Yes
User Authorization No Yes Yes Yes Yes
Multi-factor Authentication at all Points No No No Yes Yes
Role-based Authorization No No Yes Yes Yes
Malware/ Virus/ Ransomware Protection No Yes Yes Yes Yes
Table 1: An example specifying the mapping between the security requirements and the
security levels.9
4.3 IEC 62304 Medical device software – Software life cycle processes2
This standard provides a framework of life cycle processes with activities and tasks necessary for
the safe design and maintenance of medical device software. Also, it provides requirements for
each life cycle process. Each life cycle process is further divided into a set of activities, with
most activities further divided into a set of tasks. The major addition given by this standard to the
previously developed standards for developing safe medical software is providing the processes
for software configuration management and software problem resolution.
4.4 The Secure Product Design Life Cycle – Best Practices for Device Manufacturers2
Utilizing practices developed in IEC 62443-4-1 Product Development Requirements, IEC 62443-
4-2 Technical Security Requirements for industrial control system components, and IEC 61508
Functional safety of electrical/electronic/programmable electronic safety-related systems, medical
device manufacturers can leverage these standards from the design to the deployment stage. These
standards emphasize on the design phase, verification, and testing phases.

6. Fig 1. The Secure Product Design Life Cycle
4.5 AAMI TIR97/Ed. 1, Principles for medical device security – Post-market security
management for device manufacturers2
This Technical Information Report (TIR) based protocol addresses post-market 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
of the concepts apply to any healthcare product that requires post-market management of security.
With this protocol, manufacturers can set up a system or enterprise level process to manage
security. Also, this protocol provides a way of performing post market interactions with users.
Other functionalities include creating post-market management security risk design features,
integrating with Health Care Delivery Organizations (HDOs) security components like their
policies and technologies, and relaying manufacturer’s safety requirements to medical devices
deployment team. Moreover, using this protocol, manufacturers can provide processes for:
• Monitoring devices with new vulnerabilities
• Take appropriate actions after assessing safety and security risks
• Develop vulnerability disclosure processes and implement security patch management
• Develop plans for device replacement and retirement.10
4.6 AAMI SW96/Ed. 1, Medical Devices – Application of security risk management to
medical devices2
This standard is being developed based on the AAMI TIR97. Even though this project has been
approved, it is currently on hold due to the development of AAMI TIR97.
5. Pre and Post Market Submission Guidance
5.1 Pre-market Submission Guidelines

7. The Pre-market submission FDA guidelines emphasize the “Level of Concerns”. These levels
indicate the level of risks associated with a device or a software system. FDA recommends that
these levels should be determined before the mitigation of any identified relevant hazards. The
concern levels include Major (Results in serious injury or death), Moderate (May result in minor
injury), or Minor (Minimal functional effect). Also, device manufacturers should describe how
they selected a specific level of concern. At every stage, each document shall address these levels
of concerns associated with potential risks in the system.
• Documentation based on Minor, Moderate, and Major Concerns: Level of Concern
document, Software Description, Device Hazard Analysis, Traceability Analysis, and
Revision Level History
• Documentation based on Moderate and Major Concerns: Architectural Design Chart,
Software Design Specification (SDS), Software Development Environment Description,
List of remaining software anomalies (Bugs or Defects) annotated with an explanation of
the impact on safety or effectiveness, including operator usage and human factors.
• Software Requirements Specification (SRS): For Minor Level: Summary of functional
requirements from SRS. For Moderate/ Major Level: Complete SRS document.
• Verification and Validation: For Minor Level: Software functional test plan, pass/fail
criteria, and a summary of the test results. For Moderate/ Major Level: Description of V&V
activities at the unit, integration, and system level. System-level test protocol for Moderate
Concern. Unit, integration, and system-level test protocols for Major Concern.8
Moreover, manufacturers should establish design inputs for their device related to
cybersecurity and establish a cybersecurity vulnerability and management approach as part of the
software validation and risk analysis that is required by 21 CFR 820.30(g). The approach should
appropriately address the following elements: Identification of assets, threats, and vulnerabilities,
assessment of the impact of threats and vulnerabilities on device functionality and end
users/patients, Assessment of the likelihood of a threat and vulnerability being
exploited, determination of levels of concerns and suitable mitigation strategies, assessment of
residual risk, and risk acceptance criteria.
5.2 Post-market Submission Guidelines
As medical devices and applications evolve, so do the risks associated with them. Hence, it is
not always possible to completely mitigate the risks only by using premarket controls.
Cybersecurity risk management programs should focus on addressing vulnerabilities that avoid
unauthorized access or the unauthorized use of information that is stored, accessed, or transferred
from a medical device to an external recipient, resulting in patient harm.
Manufacturers should be proactive when they identify vulnerabilities. When the product is
running, manufacturers should implement measures including identifying sources of
vulnerabilities, monitor third party-software for new risks, and use a robust software lifecycle.
Additionally, they should subject the updates and patches built for risk mitigation through the
verification and validation phases. Also, they should establish a sophisticated process for
vulnerability handling. Besides accepted protocols, the FDA recommends that manufacturers use
the ISAO (Information Sharing and Analysis Organization) platform and standards to share threats
that affect the running medical devices. Sharing and spreading of such cybersecurity information
about vulnerabilities results in a successful post-market cybersecurity surveillance program.8

8. To manage post-market cybersecurity risks for medical devices, the key measures are risk
management and quality management systems which are compliant with 21 CFR part 820. Also,
the FDA recommends using a strong framework like NIST for Improving Critical Infrastructure
Cybersecurity which has a significant data flow for identifying and mitigating risks: Identity,
Protect, Detect, Respond, and Recover.11
6. Cyber Risks Mitigating Measures
In the early stages of development, medical device manufacturers should always select a
Cybersecurity framework that identifies components that could potentially cause data breaches. A
framework like NIST, which identifies risks and protects system against malicious data elements,
responds and recovers after system has undergone attack. Also, with cybersecurity researchers,
they should include the designed framework in every software development phase. While
capturing the system’s functional and security requirements, manufacturers should ensure their
system meets FDA’s device and software regulatory requirements.
For information systems, the security measures can be initiated by maintaining a centralized
entity that performs profile access and identity management. Additionally, systems would be more
secure if the access is designed using multi-layered models like VPNs, multifactor, or token-based
authentication. The information system mitigation part also includes designing a sophisticated
employee training program, with logging and third-party assessment tools that provides
information on links where users might have exposed the data. Manufacturers and software
engineers should implement an extensive cyber-risks mitigation plan for overall data and system
privacy and security.12
In the end, manufacturers should monitor third-party software components for new
vulnerabilities throughout the product’s lifecycle, report issues to FDA or Homeland Security in
case of new vulnerabilities, and also identify design verification and validation strategies for
software updates that are used to remediate vulnerabilities, including those related to Off-the-shelf
software. Major responsibilities fall on medical device manufacturers (MDMs) and health delivery
organization (HDOs) when it comes to mitigating cyber-risks and vulnerabilities. MDMs should
be vigilant about new or old risks and hazards associated with their devices. HDOs should
implement measures for protecting their information systems and network with the latest available
cybersecurity frameworks. Both entities should add mechanisms for ensuring complete system
security including device safety, quality and effectiveness.8
For any observed anomalies, it is
mandatory for manufacturers and facility personnel to submit device reports to the FDA. Reports
maybe also submitted voluntarily by patients, consumers, and healthcare professionals.13
7. Conclusion
Platforms like IoT facilitate abilities such as continuous health monitoring and device
control. But with recent developments in medical devices and applications, the flow of the data
through public domains is increasing, making the system vulnerable. Indeed, devices which do not
implement authorization, data encryption and authentication are highly vulnerable. Hence,
Cybersecurity becomes a vital factor to be considered as a part of system and data security. Based
on the past cybersecurity attacks and the concerns stated by FDA, there are tons of modern
Cybersecurity frameworks available in the market. Also, FDA has provided several protocols
which device manufacturers can implement in their systems through which they will meet the FDA

9. Cybersecurity requirements. With protocols like IEC 60601-4 implemented in the system, FDA
would consider the device to be robust and fault tolerant against the malware and ransomware
attacks, thus securing the system.
Our company, EMMA International, specializes in quality, regulatory, and compliance
solutions and services which also include providing the right guidance for including the correct
Cybersecurity frameworks, or verifying if the implemented Cybersecurity model meets the FDA
standards. If you have a medical device, or an application with Cybersecurity needs, our regulatory
and software experts can help ensure your device is FDA compliant. Call us today at 248-987-
4497 or email us at info@emmainternational.com for more information.

10. Bibliography
1
Danny Palmer (Nov 2018) IoT security: Why it Will Get Worse Before It Gets Better. Retrieved on 09/19/2020
from https://www.zdnet.com/article/iot-security-why-it-will-get-worse-before-it-gets-better/.
2
FDA. (2019) FDA Selection of Cybersecurity-related Standards in Development for Medical Devices. Retrieved
on 09/19/2020 from https://www.fda.gov/media/123070/-
download#:~:text=IEC%2062304%20is%20a%20foundational,and%20provide%20clarity%20for%20users.
3
Danny Palmer (June 2019) Cybersecurity: These are the Internet of Things Devices that are Most Targeted by
Hackers. Retrieved on 09/19/2020 from https://www.zdnet.com/article/cybersecurity-these-are-the-internet-of-
things-devices-that-are-most-targeted-by-hackers/
4
National Cyber Security Center (NCSC) (June 2016) How cyberattacks work. Retrieved on 09/23/2020 from
https://www.ncsc.gov.uk/information/how-cyber-attacks-work
5
Katie Adams (July 6, 2020) Healthcare providers that underwent cyberattacks in 2020 so far. Retrieved on
09/23/2020 from https://www.beckershospitalreview.com/cybersecurit-y/healthcare-providers-that- underwent-
cyberattacks-in-2020-so-far.html
6
Healthcare IT News (2018) The biggest healthcare data breaches of 2018 (so far). Retrieved on 09/26/2020 from
https://www.healthcareitnews.com/projects/biggest-healthcare-data-breaches-2018-so-far.
7
FDA (January 2020) Cybersecurity Vulnerabilities Affecting Medtronic Implantable Cardiac Devices,
Programmers, and Home Monitors: FDA Safety Communication. Retrieved on 09/26/2020 from
https://www.fda.gov/medical-devices/safety-communications/cybersecurity-vulnerabilities-affecting-medtronic-
implantable-cardiac-devices-programmers-and-home
8
FDA. (March 2020) Cybersecurity. Retrieved on 09/27/2020 from https://www.fda.gov/medical-devices/digital-
health-center-excellence/cybersecurity
9
Johner Institute. IEC 60601-4-5: The standard for IT security, is it also for stand-alone software? Retrieved on
09/27/2020 from https://www.johner-institute.com/articles/software-iec-62304/and-more/iec-60601-4-5/
10
AAMI (2019) AAMI TIR97: 2019. Principles for medical device security – Post-market security management for
device manufacturers. Retrieved on 09/27/2020 from http://my.aami.org/aamiresources/previewfiles/1909_TIR97-
preview.pdf
11
NIST. Cybersecurity Framework. Retrieved on 09/27/2020 from https://www.nist.gov/cyberframework
12
Nach Dave (December 2019) Cyberattacks on Medical Devices Are on the Rise—and Manufacturers Must
Respond. Retrieved on 09/27/2020 from https://spectrum.ieee.org/the-human-os/biomedical/devices/cyber-attacks-
on-medical-devices-are-on-the-riseand-manufacturers-must-respond
13
FDA. (August 2019) Medical Device Reporting (MDR): How to Report Medical Device Problems. Retrieved on
09/27/2020 https://www.fda.gov/medical-devices/medical-device-safety/medical-device-reporting-mdr-how-report-
medical-device-problems