Page 1 of 13

MDS – G38

Version Number: 2.0

Version Date: 4/11/2019

Guidance to Pre-Market

Cybersecurity of Medical Devices

Page 2 of 13

Table of Content

Introduction ................................................................................................................................... 3

Purpose ........................................................................................................................................... 3

Scope............ ................................................................................................................................... 3

1. Medical Device Cybersecurity Strategy .............................................................................. 4

1.1 Security of the Design ....................................................................................................... 4

1.2 Device Cybersecurity Risk Management .......................................................................... 4

1.2.1 ISO 14971 and Further Considerations ................................................................... 4

1.2.2 National Institute of Standards and Technology (NIST) Framework for Improving

Critical Infrastructure .............................................................................................................. 6

2. Cybersecurity Verification and Validation Testing............................................................ 6

2.1 Vulnerabilities and Exploits Testing: which include the following testing ....................... 7

3. Labeling or Customer Security Documentation ................................................................. 7

4. Cybersecurity required documentation for SFDA marketing authorization .................. 8

4.1 Security of the design ........................................................................................................ 8

4.2 Risk management related to cybersecurity of medical devices ......................................... 8

4.3 Standards ........................................................................................................................... 8

4.4 Cybersecurity verification and validation testing .............................................................. 8

4.5 Traceability Matrix ............................................................................................................ 8

4.6 Planning for continuous monitoring and maintenance plan .............................................. 9

4.7 Labelling or Customer Security Documentation ............................................................... 9

Annexes......................................................................................................................................... 10

Annex (1): Definitions & Abbreviations .................................................................................... 11

Page 3 of 13

Introduction

Medical devices have progressed from analogue and isolated hardware to networked devices that

include remote access, wireless technology and complex software. Increasing levels of

interconnectedness and data exchange between medical devices can be beneficial to both patients

and the healthcare system. However, this can leave devices vulnerable to unauthorized access

which can negatively impact safety by causing diagnostic or therapeutic errors, or by affecting

clinical operations.

This guidance developed by the SFDA to aid industry by identifying issues associated with

cybersecurity that manufacturers should take into account through the design and development of

their medical devices as well in preparing premarket submissions for those devices.

Purpose

The purpose of this guidance is to provide fundamental concepts and recommendations on pre-

market submission and suggest best practices on how to secure medical devices connected to a

network. These measures shall be taken into account by manufacturers to ensure that no risks are

part of the finalized medical device.

Scope............

This guidance provides recommendations and suggestions to be considered and information to

include in SFDA medical device premarket submissions for effective cybersecurity management.

This guidance document is applicable to premarket submissions for medical devices including In-

Vitro medical devices that contain software (including firmware) or programmable logic as well as

software that is a medical device (collectively referred to as “software devices”)

Page 4 of 13

1. Medical Device Cybersecurity Strategy

Medical device cybersecurity is a shared responsibility between the manufacturer, regulator,

user and healthcare provider. It is the responsibility of the Manufacturers to monitor, assess,

and mitigate potential cybersecurity risks throughout the lifecycle of their product. This section

will illustrate the main elements that should be included in the medical device cybersecurity

strategy

1.1 Security of the Design

Manufacturer should develop an understanding of cyber security vulnerabilities associated

with the medical device and the potential risk early in the product life‐cycle, during the initial

design and development phase when design requirements are being developed. Addressing

cybersecurity risks at the design phase can mitigate the cybersecurity risks which could

contribute to: a failure of the medical device in delivering therapy, a breach in the

confidentiality, a compromise in the integrity and availability of the medical device data or

intentional unauthorized access to the medical device and/or the network. The manufacturer

should also consider design controls that allow the device to detect, resist, respond and recover

from cybersecurity attacks and in the mean while not affecting other safety‐related aspects of

the medical device (e.g., usability).

1.2 Device Cybersecurity Risk Management

Conducting risk management is essential for a medical device throughout its life‐cycle.

Manufacturers should integrate medical device cybersecurity into each device’s risk

management process, and should develop and maintain an organizational framework for

managing cybersecurity risks. Manufacturers should consider the NIST “Framework for

Improving Critical Infrastructure Cybersecurity” as a blueprint of best practices to guide their

cybersecurity activities, including those related to risk management. In addition,

Comprehensive risk management principles, as described in ISO 14971‐07:2007 Medical

devices Application of risk management (ISO 14971), should be also incorporated throughout

the life‐cycle.

1.2.1 ISO 14971 and Further Considerations

The ISO 14971 standard provides a process which the manufacturer of a medical device

can use to identify hazards associated with a medical device, estimate and evaluate the

risks associated with these hazards, control these risks, and monitor the effectiveness of

that control.

The following qualitative levels of severity of patient harm, based on descriptions in ISO

14971, could be used in a cybersecurity risk assessment:

Negligible: Inconvenience or temporary discomfort

Minor: Results in temporary injury or impairment not requiring professional medical

intervention

Serious: Results in injury or impairment requiring professional medical intervention

Page 5 of 13

Critical: Results in permanent impairment or life-threatening injury

Catastrophic: Results in patient death

In addition to implementing ISO 14971, it is recommended for manufacturers to expand

the risk management principles of cybersecurity with the following additional

considerations:

identifying any cybersecurity hazard

estimation and evaluation the associated risks

control risks to an acceptable level

monitor the effectiveness of the risk controls

Moreover, there are cybersecurity risks that could affect the safety or effectiveness of the

medical device. A cybersecurity risk that negatively affect the effectiveness, clinical

operations, or results in diagnostic or therapeutic errors should be reflected in the medical

device’s risk management process (Figure 1). This consideration is reflected in AAMI

TIR57:2016 Principles for medical device security – Risk management which suggests

that the risks associated with the cybersecurity of a device can include direct and indirect

patient harms (as described in ISO14971).

Figure 1: A Venn diagram illustrating the relationship between cybersecurity risk and

safety risks as defined by ISO 14971 (adapted from AAMI TIR57).

Page 6 of 13

1.2.2 National Institute of Standards and Technology (NIST) Framework for

Improving Critical Infrastructure

Although this document is aimed at improving cybersecurity risk management activities

for critical infrastructure, the principles and approaches described in this document are

broadly applicable to all medical devices.

The following five core functions of the framework relate to medical device design

controls:

1. Identify: The manufacturer should perform a risk analysis to identify cybersecurity

risks in their product(s).

2. Protect: Design controls should be implemented to limit the risk associated with the

identified cybersecurity risks.

3. Detect: Processes or measures should be in place to identify when the device has been

compromised due to a cybersecurity event.

4. Respond: A defined process or plan should be developed on how the device,

manufacturer or user will respond to a cybersecurity event.

5. Recover: A plan describing the activities the device, manufacturer or user must

undertake to restore the device to normal operating capacity following a cybersecurity

event. The outcome of any investigations into previous recoveries may be used as

feedback into the risk management process.

This framework is can be used to complement the ISO 14971 risk management processes

and help to improve established cybersecurity risk management process. A manufacturer

that does not have an established cybersecurity risk management process may consider

using the framework as a guide to establish best practices in the cybersecurity of the

devices that they manufacture.

2. Cybersecurity Verification and Validation Testing

Manufacturer should verify and validate all cybersecurity risk control measures verified

and against design specifications and/or design requirements. All verification and

validation activities should be traced back to design specifications and/or design

requirements.

All Functions, features and design components that have been implemented to mitigate

identified cybersecurity should be verified and validated.

UL 2900-2-1:2018 standards for guidance on cybersecurity testing outline some type of

testing that manufacturer might consider when conducting verification and validation

testing. Suggested testing is devices to two categories:

Page 7 of 13

2.1 Vulnerabilities and Exploits Testing: which include the following testing

Vulnerability testing: that include software code testing against a database of known

vulnerabilities

Malware Testing: Malware detection tools are used to scan the code to determine if any

known malware exists.

Malformed Input Testing (i.e., FUZZ testing): The device is subjected to massive

amounts of malformed (invalid or unexpected inputs) to observe if the device will behave

in an unorthodox manner or if it will “crash”.

Structured Penetration Testing: This type of testing requires a cybersecurity expert who

is familiar with hacking techniques (i.e., white hat or ethical hacker). The cybersecurity

expert attempts to circumvent the layers of defense that were designed into the device.

2.2 Software Weakness Testing: which include

Static Source Code Analysis: Utilization of a software tool to examine (i.e., debug) the

source code without executing the software code.

‐market Requirements for Medical Device Cybersecurity | 15

Static Binary and Bytecode Analysis: Utilization of tools that will examine compiled code

created from source code

3. Labeling or Customer Security Documentation

The technical documentation written by the manufacturer for installation, configuration of the

device, AND the technical requirements for their operating environments are crucial for a safe

and secure use by the user. This also includes providing the Software Bill of Material (SBOM)

or also referred to as Customer Security Documentation to:

Ensure suitable level of transparency.

Can be used by administrators as part of their asset management to examine applications

and code from suppliers to obtain an accurate view of potential vulnerabilities and

weaknesses

Help administrators to identify required software patches in a timely manner in order to

protect their systems.

Help to inform purchasing decisions by providing prospective buyers with visibility into

the components used in applications and determining potential security risk and licensing

problems.

Page 8 of 13

4. Cybersecurity required documentation for SFDA

marketing authorization

In the premarket submission, manufacturers should provide evidence of compliance for the

following information:

4.1 Security of the design

Identifying cybersecurity risks during the design development and throughout the life-

cycle of medical device

Implement control measures in the device to control identified risks and protect against

threats.

List of controls that are in place to assure that the medical device software will remain

free from malware from the point of origin to the point at which that device leaves the

control of the manufacturer.

4.2 Risk management related to cybersecurity of medical devices

a cybersecurity risk analysis based on reliable standards and/or frameworks

a cybersecurity risk management report the risk that include reduction measures

adopted to cover safety and effectiveness requirements

4.3 Standards

A list of all standards and frameworks applied, in whole or in part.

Expected baseline standards are:

o ISO 13485 Medical devices—Quality management systems—

Requirements for regulatory purposes

o ISO 14971 Medical devices—Application of risk management to medical

devices

4.4 Cybersecurity verification and validation testing

Detailed reports showing testing that was conducted to verify and validate the

security of the device.

Summary Reports showing all evidence of cybersecurity testing.

4.5 Traceability Matrix

A traceability matrix that contains maps of all identified cybersecurity risks to:

o Requirement specifications

o Design specifications

o Design verification and validation tests

Page 9 of 13

4.6 Planning for continuous monitoring and maintenance plan

A summary that illustrate the maintenance plan. The summary should define the post‐market

processes that will be followed to ensure the continued safety and effectiveness of the device

throughout its life‐cycle.

Considerations in monitoring and responding to emerging risks can include:

Post‐market vigilance: A plan that show how to track, assess, and respond to new

cybersecurity risks and vulnerabilities.

Patching: A plan to update the software to maintain the safety and effectiveness of the device

either regularly, or in response to an identified vulnerability.

Vulnerability Disclosure: formalized process for obtaining cybersecurity vulnerability

information, assessing vulnerabilities, developing mitigation and remediation strategies, and

disclosing the existence of vulnerabilities and mitigation or remediation approaches to

various stakeholders.

Information sharing: Participation in Information Sharing Analysis Organizations (ISAOs)

or Information Sharing and Analysis Centers (ISACs) that promote the communication and

sharing of updated information about security threats and vulnerabilities.

4.7 Labelling or Customer Security Documentation

User documentation that includes relevant information, as outlined in Section 5 above, to

allow the user to effectively manage the device’s cybersecurity.

Page 10 of 13

Annexes

Page 11 of 13

Annex (1): Definitions & Abbreviations

SFDA Saudi Food and Drug Authority

MDS Medical Devices Sector

MDMA Medical Devices Marketing Authorization

IEC International Electrotechnical Commission

ISO International Standards Organization

NIST National Institute of Standards and Technology

SBOM Software Bill of Material

UL Underwriter’s Laboratories LLC

Manufacturer any natural or legal person with responsibility for design and manufacture

of a medical device with the intention of making it available for use, under

his name; whether or not such a medical device is designed and/or

manufactured by that person himself or on his behalf by another person.

Medical Device means any instrument, apparatus, implement, machine, appliance, implant,

in vitro reagent or calibrator, software, material or other similar or related

article:

A. Intended by the manufacturer to be used, alone or in combination,

for human beings for one or more of the specific purpose(s) of:

- Diagnosis, prevention, monitoring, treatment or alleviation of

disease,

- Diagnosis, monitoring, treatment, alleviation of or

compensation for an injury or handicap,

- Investigation, replacement, modification, or support of the

anatomy or of a physiological process,

- Supporting or sustaining life,

- Control of conception,

- Disinfection of medical devices,

- Providing information for medical or diagnostic purposes by

means of in vitro examination of specimens derived from the

human body;

and

B. Which does not achieve its primary intended action in or on the

human body by pharmacological, immunological or metabolic

means, but which may be assisted in its intended function by such

means.

Page 12 of 13

In-Vitro

Medical Device

a medical device, whether used alone or in combination, intended by the

manufacturer for the in-vitro examination of specimens derived from the

human body solely or principally to provide information for diagnostic,

monitoring or compatibility purposes. This includes reagents, calibrators,

control materials, specimen receptacles, software and related instruments or

apparatus or other articles.

Accessory a product intended specifically by its manufacturer to be used together with

a medical device to enable that medical device to achieve its intended

purpose.

Cybersecurity means the body of technologies, processes, practices, responses and

mitigation measures designed to protect a medical device against

unauthorized access, modification, misuse, or denial‐of‐use, and

against the unauthorized use of information stored, accessed, or

transferred to or from a medical device.

Risk The combination of the probability of occurrence of harm and the severity

of that harm.

Vulnerability The state of being exposed to the possibility of being attacked or harmed.

Threat The potential impact over the safety of medical device via unauthorized

access, misuse, or modification of medical device data.

Software a software system that has been developed for the purpose of being

incorporated into the medical device being developed or that is intended for

use as a medical device in its own right.

Attack is an attempt to gain unauthorized access to system services,

resources, or information, or an attempt to compromise system

integrity. Hazard All of the possible rick or danger from the use of medical device

Integrity the property of data, information and software to be accurate and

complete and have not been improperly modified. Malware means software designed with malicious intent to disrupt normal

function, gather sensitive information and/or access other connected

systems. System means a medical device comprising a number of components or parts

intended to be used together to fulfill some or all of the device’s

intended functions, and that is sold under a single name. Verification means confirmation through provision of objective evidence that

specified requirements have been fulfilled

Page 13 of 13

References ISO 13485:2016 Medical devices — Quality management systems — Requirements for

regulatory purposes

ISO 14971 Medical devices — Application of risk management to medical devices

AAMI TIR57:2016 Principles for medical device security – Risk management

National Institute of Standards and Technology (NIST) Framework for Improving

Critical Infrastructure

UL 2900-2-1: 2018 Software Cybersecurity for Network-Connectable Products, Part 2-1:

Particular Requirements for Network Connectable Components of Healthcare and

Wellness Systems