Cybersecurity for

Medical Devices
MDR and IEC TR 60601- 4-5
Requirements

Justin Heyl

TÜV SÜD PS GmbH | Cyber Security for medical devices 17.03.2021

 MEDICAL DEVICE QUALITY IS ALL WE DO,
AND WE’RE ALWAYS AHEAD OF THE GAME.

“Great eQMS
75 275k #1 114k Software…”
years industry podcast listeners blog and podcast look to us for the “The software is easy to use with little
experience in the industry latest in quality to no customization needed. It has
been a great tool for developing our
device through design control. The
post-market additions have been
amazing as well as tasks. After using
multiple types of eQMS software
FEATURED IN over the years, this is the best by
far!”

“My QMS is world “Design controls

class” lifesaver”

“One-stop shop” “Fantastic product, even better

team”
Increasing awareness on cyber security in medical devices

“As the level of threat is […] critical “We need to do our utmost to “Medical device manufacturers are
for medical devices, more suitable protect critical healthcare systems responsible […] about identifying
Cyber Security mechanisms will […] and work towards improving risks and hazards […]
have to be developed in the future.” the safety of the patients” including […] cybersecurity.”

GERMAN FEDERAL OFFICE EUROPEAN UNION AGENCY U.S. FOOD AND DRUG
OF INFORMATIN SECURITY, FOR CYBERSECURITY (ENISA), ADMINISTRATION (FDA),
The State of IT Security in Germany, Cybersecurity – The Right Medicine for Cybersecurity, 2019
2018 the eHealth Sector, 2018

TÜV SÜD AG 2021 3

Cybersecurity – Information Security – Data Privacy

Information Security
Protection of all information
Information assets (data, expertise,
employees, buildings, …)
Security

Data Privacy Cyber Security

Protection of personally Protection of IT and
identifiable information (PII) Data Cyber OT assets

Privacy Security

GDPR

TÜV SÜD AG 2021 4

Overview on standards and guidance documents for cyber security

Name EU
MDR – Medical Device Regulation Regulations

MDCG 2019-16 – Medical Device Need to be followed

Coordination Group – Guidance on
Cybersecurity for medical devices
ISO 14971:2012 - Application of risk Harmonized Standard
management to medical devices
ISO 14971:2019 - Application of risk State of the art
management to medical devices

TÜV SÜD AG 2021 5

Medical device regulation (MDR) and Cybersecurity
▪ MDR requires development according to state of the art considering IT-Security
„…the software shall be developed … in accordance … information security…“ [Annex I 17.2]
▪ MDR requires definition of security measures to protect against e.g. unauthorized access
„…IT security measures, including protection against unauthorised access…“ [Annex I 17.4]
▪ The MDCG 2019-16 guidance document specifies the cybersecurity requirements found in Annex I of the regulation

MDR requires cybersecurity risk management throughout the whole

life cycle of the medical device

TÜV SÜD AG 2021 6

MDCG/Notified Body checklist
– Security requirements: to ensure safety and effectiveness of products against security risks and
threats
– Validation and verification of the solutions adopted to meet those requirements (e.g. methods and
results of security testing).
– Risk Management
– Risk Assessment
– Instructions for Use
– Post Market Surveillance Plan
– Post Market Surveillance Process
– Cybersecurity Routine Updates and Patches
– Manufacturers post market surveillance system: related to handling and remediation of
cybersecurity incidents and vulnerabilities.
– Cybersecurity Development Process

TÜV SÜD AG 2021 7

MDCG/NB Checklist
▪ Often, specific security information is shared through documentation other than the instructions for use, such as
instructions for administrators or security operation manuals. Such information may include the following:

– List of IT security controls included in the medical device

– System Diagram with all interfaces and data communication
– List of all open ports
– Depending on the type of product, provisions to ensure integrity/validation of software updates and security patches
– Technical properties of hardware components
– Cybersecurity Bill of Materials : A CBOM including but not limited to a list of commercial, open source, and off-the-shelf
software and hardware components to enable device users (including patients, providers, and healthcare delivery
organizations (HDOs)) to effectively manage their assets, to understand the potential impact of identified vulnerabilities
to the device (and the connected system), and to deploy countermeasures to maintain the device’s essential
performance.
– User roles and respective access privileges/permissions on the device
– Implementation of the logging function, particularly the medical device’s log storage capacity and the recommendations
for backing up and using the logs

TÜV SÜD AG 2021 8

FDA Additional Specific Requirements to considered:
– FDA intends to consider the following in determining whether a manufacturer is an active participant
in an ISAO
– It is recommended as part of a manufacturer’s cybersecurity risk management program that the
manufacturer incorporate elements consistent with the NIST Framework for Improving Critical
Infrastructure Cybersecurity (i.e., Identify, Protect, Detect, Respond, and Recover;
https://www.nist.gov/sites/default/files/documents/cyberframework/cybersecurity- framework-
021214.pdf ).
– Adopting a coordinated vulnerability disclosure policy and practice. The FDA has recognized
ISO/IEC 29147:2014: Information Technology – Security Techniques – Vulnerability Disclosure
which may be a useful resource for manufacturers;
– The FDA has recognized ISO/IEC 30111:2013: Information Technology – Security Techniques –
Vulnerability Handling Processes

TÜV SÜD AG 2021 9

Overview on standards and guidance documents for cyber security

Name EU US
IEC TR 60601-4-5:2021 Safety related technical security specifications for medical devices Likely to become a
harmonized standard
IEC 62443-3-2:2020 Security for industrial automation and control systems –
Security risk assessment for system design
AAMI TIR57:2016 - Principles for medical device security - Risk Not mandatory Consensus
management. Standard for the
FDA
ISO/TR 24971:2020 - Guidance on the application of ISO 14971 Not mandatory
IEC 81001-5-1:2020 - Health software and health IT systems safety, Likely to become a N/A
effectiveness and security - Security - Activities in the product life cycle harmonized standard
UL 2900-2-1:2018 - Software Cybersecurity for Network-Connectable Products – N/A Recommended
Requirements for Healthcare Systems by FDA
FDA cybersecurity guidance N/A Recommended
DIN 80001-1:2010 – Safety, effectiveness and security in the implementation and use of N/A N/A
connected medical devices or connected health software - Application of risk management

Note: ISO 27001 would provide assurance on a companies' maturity level, similar to HITRUST

TÜV SÜD AG 2021 10

Overview
In general IT security it is differentiated between:

▪ (Resource) Availability
▪ (System / Data) Integrity
▪ (Data) Confidentiality

IEC 62443, which IEC 60601-4-5 extensively references, also includes:

▪ Identification and authentication control
▪ Restricted data flow
▪ Timely response to events

However, these are rather subordinate goals to achieve the first three.
▪ In medical devices, one must also consider safety.

TÜV SÜD PS GmbH | Cyber Security for medical devices 17.03.2021 11

Assessment and Certification according to 62443-4-1 „Security
Lifecycle Process“ and compliance with IEC TR 60601-4-5
To show compliance to IEC TR 60601-4-5 it is necessary to address the process requirements as highlighted
in the sub clause 4.6 which specifies the following:

“All of the MEDICAL DEVICES defined in this document are assumed to be developed and supported following
a secure software development PROCESS, e.g. as described in planned IEC 80001-5-1 (Not yet published) or
in IEC 62443-4-1.”

We would recommend you to address the security life cycle process and also consider maturity level 2 (documented)
or 3 (in practice) in order for the compliance to IEC/TR 60601-4-5. For this purpose we would recommend an
assessment/ Certification to the IEC62443-4-1 standard before engaging in Cybersecurity Product testing. Also, once
you have your test plan you could choose to do the testing inhouse or with an independent test house.

TÜV SÜD PS GmbH | Cyber Security for medical devices 17.03.2021 12

IEC 62443 – Services

Workshop IEC 62443-2-4 & -4-1

Introduction to IEC 62443 and Assessment and certification of the
discussing possible certifications Workshop development / integration process

Analysis Process IEC 62443-3-3, -4-1 & -4-2

Gap-Analysis or IEC/TR 60601-4-5
Assessment to identify improvement IEC 62443 Assessment and certification of
areas
components and control systems

Assess-
Product
ment
Pre-Assessment during
development IEC 62443-2-4 & -3-3
Solution
Assessment and certification of
Testing certification requirements while
automation solutions
still developing the product / solution

NOTE: Medical companies will follow the IEC/TR 60601-4-5 Instead of the IEC 62443-4-2

TÜV SÜD PS GmbH | Cyber Security for medical devices 17.03.2021 13

Security Aspects along the assessment?

Identifying what to do Making it secure Keeping it secure

▪ Risk based approach ▪ Secure product ▪ Management of:

▪ Threat modeling development lifecycle ▪ updates / defects
▪ Secure systems / product design ▪ documentations / guidelines
▪ Technical requirements

Note: MDS2 great overview of product and security features

Appendix 1 has complete list of documentation required.

TÜV SÜD Product Service GmbH | Industrial Cyber Security 17/03/2021 14

IEC/TR 60601-4-5
▪ The Standard IEC/TR modifies IEC 62443-4-2 only for specific aspects of MEDICAL DEVICES in MEDICAL IT-
NETWORKS.

The primary goal of this Standard is to provide:

▪ flexible framework that facilitates addressing current and future vulnerabilities and applying necessary mitigations in a
systematic, defensible manner.

▪ Each of the proposed COUNTERMEASURES should take into account that requirements regarding the safety and
performance of a MEDICAL DEVICE should not be negatively impacted.

TÜV SÜD PS GmbH | Cyber Security for medical devices 17.03.2021 15

IEC 62443-4-2: Common Control System Security Constraints

CCSC 1 –
The components of the system shall adhere to specific constraints as described
Support of Essential
in IEC 62443‐3‐3.
Functions

CCSC 2 –
Cases where one or more requirements specified in the standard cannot be met without
Compensating
the assistance of a compensating countermeasure that is external to the component.
Countermeasures

When required and appropriate, one or more system components (software applications,
CCSC 3 –
embedded devices, host devices and network devices) shall provide the capability for the system
Least Privilege
to enforce the concept of least privilege.

CCSC 4 –
All components defined in IEC 62443-4-2 shall be developed and supported following the secure
Software Development
product development processes described in IEC 62443-4-1.
Process

TÜV SÜD Product Service GmbH | Industrial Cyber Security 17/03/2021 16

Seven Foundational Requirements
▪ Identification and authentication control (IAC),
▪ Use control (UC),
▪ System integrity (SI),
▪ Data CONFIDENTIALITY (DC),
▪ Restricted data flow (RDF),
▪ Timely response to events (TRE), and
▪ Resource availability (RA).

TÜV SÜD PS GmbH | Cyber Security for medical devices 17.03.2021 17

IEC TR 60601-4-5 Scope
▪ IEC TR 60601-4-5 Provides recommendations for different MEDICAL DEVICE capability SECURITY LEVELS (SL-C). The
recommended security capabilities of a MEDICAL DEVICE may be used by various members of the medical community to
integrate the device correctly into defined SECURITY ZONES and CONDUITS of a MEDICAL IT-NETWORK with an
appropriate MEDICAL IT-NETWORK’S target SECURITY LEVEL (SL-T).

TÜV SÜD PS GmbH | Cyber Security for medical devices 17.03.2021 18

IEC TR 60601-4-5 Purpose
▪ MEDICAL DEVICE MANUFACTURERS should use this document to understand and apply the recommendations for
specific SL-C of their MEDICAL DEVICES.

▪ A MEDICAL DEVICE may not provide the capability itself but may be designed to integrate with a higher-level entity and
thus benefit from that entity’s capability.

▪ This standard should guide MEDICAL DEVICE MANUFACTURERS as to what specifications can be allocated and which
specifications need to be native in the MEDICAL DEVICE.

▪ MEDICAL DEVICE MANUFACTURERS should provide documentation on how to properly integrate the MEDICAL
DEVICE into a MEDICAL IT-NETWORK.

TÜV SÜD PS GmbH | Cyber Security for medical devices 17.03.2021 19

Security Levels – The central concept of IEC 60601-4-5
The standard works with three types of security level (SL):

▪ SL-T: The Target Security Level, that one must achieve for the network including the networked medical devices, to
achieve the set protection goal.

▪ SL-C: The Capability Security Level, that can actually achieve for the medical product and the network, if one takes
measures to improve IT security.

▪ SL-A: The Achieved Security Level, the level one actually achieves.

TÜV SÜD PS GmbH | Cyber Security for medical devices 17.03.2021 20

Security Levels: SL-T
▪ Target security level (SL-T) is the desired level of security for a particular MEDICAL IT-NETWORK or a specified ZONE
of it. It is usually determined by performing a RISK assessment on a MEDICAL IT-NETWORK and determining that it
needs a particular level of security to ensure its correct operation. A system integrator specifies the SL-T for each ZONE of
the MEDICAL IT-NETWORK. “Requirements Specification” is a metaphor for this.

The SL-T and achieved SECURITY LEVELS (SL-A) for a complete MEDICAL IT-NETWORK or a ZONE of it are out of the
scope of the IEC 60601-4-5 Standard:

The SL-T must ultimately be determined by the operator or integrator, because only they can decide which network
environment a medical device will be used in. A programming device for a heart pacemaker, which would be openly
accessible to the internet, requires a higher security level than an anesthesia workplace, in a completely closed network of
an operating room.

TÜV SÜD PS GmbH | Cyber Security for medical devices 17.03.2021 21

Security Levels: SL-C
Defining SL-C for MEDICAL DEVICES is the goal and objective of the Standard

Capability security level (SL-C) is the SECURITY LEVEL that a MEDICAL DEVICE or other components of a MEDICAL IT-
NETWORK can provide when properly configured. This level states that a particular MEDICAL DEVICE or other component
of the MEDICAL IT-NETWORK is capable (or not) of meeting the required SL-T natively without additional COMPENSATING
COUNTERMEASURES when properly configured and integrated. A MANUFACTURER declares and verifies the MEDICAL
DEVICE’S SL-C.

the manufacturer determines the SL-C, that can be achieved if the operator configures and operates the device according to
specification. The SL-C depends on which measures the manufacturer has implemented and reviewed.

An SL-C is defined for COUNTERMEASURES and for inherent security properties of a MEDICAL DEVICE. It is a measure of
the effectiveness of the COUNTERMEASURES, which are either separate or integral to a MEDICAL DEVICE, for the
addressed security property and contributes to the SL-A in the corresponding part of the MEDICAL IT-NETWORK.

TÜV SÜD PS GmbH | Cyber Security for medical devices 17.03.2021 22

Security Levels: SL-C
COUNTERMEASURES can be:

▪ Technical COUNTERMEASURES (firewalls, anti-virus software, etc.),

▪ Administrative COUNTERMEASURES (policies and procedures), and
▪ Physical COUNTERMEASURES (locked doors, etc.).

The recommended “component requirements” (CRs) for MEDICAL DEVICES provided by the standard are mainly derived
from the IT-NETWORK “system requirements” (SRs) in IEC 62443- 3-3 which are in turn derived from the overall
Foundational Requirements defined in IEC TS 62443-1-1. MEDICAL DEVICE recommendations also include a set of
“requirement enhancements” (REs). The combination of CRs and REs implemented into a MEDICAL DEVICE will determine
the SL-C of the MEDICAL DEVICE.

TÜV SÜD PS GmbH | Cyber Security for medical devices 17.03.2021 23

Security Levels: SL-A
Achieved security level (SL-A) is the actual level of security for a particular MEDICAL IT NETWORK or a specified ZONE
of it. It is measured after a MEDICAL IT-NETWORK’S design is available or when a MEDICAL IT-NETWORK is in place. It is
used to establish that a security system or a specified ZONE is meeting the goals that were originally set out in the SL-T.

Which actual security level (SL-A) the operator achieves, depends on multiple factors:

▪ Has the operator correctly configured within the network and the network itself?
▪ Has the operator implemented measures to increase IT security outside of the device?

For example, "integration tests” determine the actual SL-A achieved, wherein “integration” means the integration of the
device into the associated networks.

TÜV SÜD PS GmbH | Cyber Security for medical devices 17.03.2021 24

Security Levels

TÜV SÜD PS GmbH | Cyber Security for medical devices 17.03.2021 25

Security Levels- Example
▪ SL 0 – No specific requirements or security protection necessary

▪ SL 1 – Prevent the unauthorized disclosure of information via eavesdropping or casual exposure.

▪ SL 2 – Prevent the unauthorized disclosure of information to an entity actively searching for it using simple means with low
resources, generic skills and low motivation.

▪ SL 3 – Prevent the unauthorized disclosure of information to an entity actively searching for it using sophisticated means
with moderate resources, IACS 5 specific skills and moderate motivation.

▪ SL 4 – Prevent the unauthorized disclosure of information to an entity actively searching for it using sophisticated means
with extended resources, IACS specific skills and high motivation.

TÜV SÜD PS GmbH | Cyber Security for medical devices 17.03.2021 26

Capability – Target – Achieved

TÜV SÜD PS GmbH | Cyber Security for medical devices 17.03.2021 27

Discussion: Possible Critical Points*
It shouldn't be disputed that we require a standard for IT security specific to medical devices. Even the estimation of IEC
60601-4-5 needs endorsement that the IT security is comprehensively regulated, meaning for both manufacturers and
operators.

Whether IEC 60601-4-5 will do this, is up for discussion. Possible critical points are:
▪ Through the references and integration of other standards, IEC 60601-4-5 is hard to read and not clearly transparent.
▪ The standard often appears inconsistent, with regard to the concreteness of the requirements. By reference to IEC 62443,
these requirements are sometimes very concrete. Other requirements, such as that a DoS attack should not hinder "safety
related” functions, are “high level”, however.
▪ There is a lack of a clear code of conduct, e.g. along the development process. This is also taken into consideration in IEC
62443.
▪ The interplay and cooperation between manufacturers and operators is insufficiently addressed in IEC 60601-4-5, and
above all via references to the IEC 80001-1 family. There are (nearly) no Post-Market Surveillance requirements for
this. This is alarming considering the requirements of the MDR.

*Johner Institut

TÜV SÜD PS GmbH | Cyber Security for medical devices 17.03.2021 28

 Appendix 1: IEC 60601-4-5 Documentation

TÜV SÜD PS GmbH | Cyber Security for medical devices 17.03.2021 29

IEC TR 60601-4-5: Documentation
The following technical description should be supplied to the RESPONSIBLE ORGANIZATION as part of the
ACCOMPANYING DOCUMENTS:

a) A specification of target groups which are to be informed about specific technical information related to cyber
security.
b) A technical description for the affected target groups that clearly illustrates how to operate the MEDICAL DEVICE in a
technically secure manner.
c) Sufficiently detailed, security concept related, system diagrams for the target groups.
d) A security concept related Cybersecurity Bill of Material including but not limited to a list of commercial, open
source, and off-the-shelf software and hardware components.
e) A description of security features and functions (including description of SL-C) that protect the ESSENTIAL
FUNCTIONS, even when the cyber security of the MEDICAL DEVICE or the connected MEDICAL IT-NETWORK has
been compromised. Documentation of RISKS/THREATS which are covered by the SL-C concept of the MEDICAL
DEVICE itself.

TÜV SÜD PS GmbH | Cyber Security for medical devices 17.03.2021 30

IEC TR 60601-4-5: Documentation
f) Information on how hardening of the MEDICAL DEVICE to the greatest possible extent can be achieved, including how to
achieve different SECURITY LEVELS for the MEDICAL DEVICE, if the MEDICAL DEVICE is able to be configured to
different SL-Cs.

g) Documentation of THREATS that should be considered for the INTENDED USE environment in the context of a cyber
security assessment or cyber security management and a list of services that cannot be secured alone with the mechanisms
integrated in the MEDICAL DEVICE (SL-C) in the INTENDED USE environment and thus require additional technical or
organisational COMPENSATING COUNTERMEASURES.

h) A list of appropriate, recommended COUNTERMEASURES for the listed THREATS in the INTENDED USE
environment to permit secure network connected deployment and servicing

i) Recommendations regarding configurations that ensure secure operations

j) Advise to target groups to deactivate the applications and unused data ports, especially incoming ports that are not
required in their particular scenarios.
TÜV SÜD PS GmbH | Cyber Security for medical devices 17.03.2021 31
IEC TR 60601-4-5: Documentation
k) Information on how to protect configuration interfaces with standard IT. For example, use of web interfaces
exclusively in encrypted form and selection of web servers operating according to the cyber security recommendations for
secure web server operations.

l) Documentation of all interfaces, access points, network ports and their functions, including a description of port
functionality, the kind of other network components that can be connected, the kind of data/signals that are being transmitted,
and the direction in which the data/signals flow.

m) A description of how the design enables the device to announce when anomalous conditions (i.e. security events) are
detected. Security event types could be configuration changes, network anomalies, login attempts, or anomalous traffic
(e.g. send requests to unknown entities).

TÜV SÜD PS GmbH | Cyber Security for medical devices 17.03.2021 32

IEC TR 60601-4-5: Documentation
n) Where appropriate, instructions for target groups on how to respond upon detection of a cyber security vulnerability
or INCIDENT.

o) A description of how forensic evidence is captured, including but not limited to any log files kept for a security event. Log
file descriptions 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).

p) A description of backup and restore features and of methods for retention and recovery of MEDICAL DEVICE
configurations (at least those needed for ESSENTIAL FUNCTIONS) by an authenticated privileged user.

q) A description of systematic procedures for authorized users to download version-identifiable software and firmware
from the MANUFACTURER.

TÜV SÜD PS GmbH | Cyber Security for medical devices 17.03.2021 33

IEC TR 60601-4-5: Documentation
r) Information on how to ensure that remote maintenance does not affect the operation of the MEDICAL DEVICE in any
way if remote maintenance during operation of the MEDICAL DEVICE is allowed / necessary.

s) Information, if known, concerning MEDICAL DEVICE cyber security end of support. At the end of support, a
MANUFACTURER may no longer be able to reasonably provide security patches or software updates. If the MEDICAL
DEVICE remains in service following the end of support, the cyber security risks for users can be expected to increase over
time.

TÜV SÜD PS GmbH | Cyber Security for medical devices 17.03.2021 34

IEC TR 60601-4-5: Documentation
Other Documentation that is required:

▪ There will be cases where one or more recommendations specified in this document cannot meet the specification without
the assistance of a COMPENSATING COUNTERMEASURE that is external to the MEDICAL DEVICE. When this is the
case, the ACCOMPANYING DOCUMENTS for that MEDICAL DEVICE should describe the appropriate
COUNTERMEASURES applied by the connected MEDICAL IT-NETWORK to allow the specification to be met when the
MEDICAL DEVICE is integrated into a MEDICAL IT-NETWORK.

▪ Confidential data in the MEDICAL DEVICE context should not be held or further used unless this is essential for reasons
that are clearly stated by the MANUFACTURER in the ACCOMPANYING DOCUMENTS (e.g. a “flight recorder” or
logging function) or data needed for standards or regulatory requirements.

▪ A RISK and THREAT analysis should be conducted to select the hardware security for the MEDICAL DEVICE, and a
vulnerability analysis identifying the residual RISKS should be conducted once the hardware security is selected.

TÜV SÜD PS GmbH | Cyber Security for medical devices 17.03.2021 35