Professional Documents
Culture Documents
Medical Devices
MDR and IEC TR 60601- 4-5
Requirements
Justin Heyl
“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!”
“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
Information Security
Protection of all information
Information assets (data, expertise,
employees, buildings, …)
Security
Privacy Security
GDPR
Name EU
MDR – Medical Device Regulation Regulations
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
▪ (Resource) Availability
▪ (System / Data) Integrity
▪ (Data) Confidentiality
However, these are rather subordinate goals to achieve the first three.
▪ In medical devices, one must also consider safety.
“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.
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
▪ 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.
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
▪ 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.
▪ 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.
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.
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.
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.
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.
▪ 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.
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
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.
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
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).
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.
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.
▪ 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.