New Cybersecurity Requirements for MDR

This Guest Blog has been brought to you by Kyle Rose, President of Rook Quality Systems.

Do you have or are you planning on launching a connected medical device into the European market?

The MDR is the regulatory framework that must be met and in January this year, they released new guidance for cybersecurity and connected devices. While initially, this was to go into effect in May 2020, this has been shifted to May 2021 instead.

Here is a “part one” blog post, looking at the general overview of what the guidelines entail:

Meeting MDR cybersecurity standards

The new guidance, published by the European Commission’s Medical Device Coordination Group covers cybersecurity for software devices and IVDR software devices. Its purpose is to provide manufacturers with guidance on fulfilling the cybersecurity requirements of the MDR.

MX1 of the guidance has several touchpoints on cybersecurity. It also provides the overall structure for creating your device and ensuring that you have robust cybersecurity concepts in place. These then tie to the design and manufacturing of the software.

Design verification is another major aspect of the guidance, highlighting how it should all be captured within a risk management plan and process. It also says you should be able to show that regular updates are made to the software and that it is “state-of-the-art.”

There are quite a few general cybersecurity requirements: data protection, conformity assessment, postmarket surveillance, trend reporting, ongoing testing, and bug fixes of the device. Those requirements are also broken into categories such as IT security, operational security, and information security. Each is shown to relate to the cybersecurity process for the device.

Cybersecurity categories

IT Security – The protection of computer systems from adverse events. This includes software, hardware, or electronic data and protecting them from cyber threats. Confidentiality, integrity, and availability of the systems are the key goals here:

Confidentiality – All information must remain confidential both when it’s at rest and in transit.
Integrity – The information must remain of high integrity.
Availability – The systems and processes must be available and able to communicate.

Operations Security – This is the protection against intended corruption, including procedures or workflows by unintended users. Only those who are intended should be able to access procedures and workflows for your software.

Information Security – All data must be protected against theft, alteration, or deletion, whether it is stored or transmitted data.

Security Issues

Security issues may be considered either weak or restrictive. Weak security includes weak access control for the operation of the device. Restrictive security means that it’s so tight, it makes it hard to use under regular operation.

When you assess the risk you need to check for issues of weakness or over-restrictiveness. These would require design changes to be implemented and tested.

Safety, effectiveness, and security of the device

The guidance additionally looks at the safety, effectiveness, and security of the software. This identifies that the device should show true performance as intended by the manufacturer and it should be designed and manufactured in such a way that it is fit for purpose under normal conditions of intended use.

The device should be safe and effective and not compromise the clinical condition or safety of patients, or the safety of other users or persons. Risks associated with use should constitute acceptable risks when weighed up with benefits to the patient and a high level of health and safety should be taken into account.

MDR risk tied to cybersecurity

You need to make sure the same things applied to design and risk procedures under MDR are also taken into account as far as risk-benefit analysis, reducing risk, and ensuring the software system is state of the art, along with compliant cybersecurity measures.

The guidance goes into more detail about what should be considered when identifying the IT infrastructure for your device. For example, this might take into account different healthcare providers, whether it’s to be used in a hospital and user apps. You need to make sure you have a risk management process that adheres to cybersecurity best practices. Some of the things critical for this intended use environment are:

Identifying good physical security to prevent unauthorized access to the software.
User-based access control. So for example, giving different levels of access to different users.
Network access control such as segmentation to limit medical device communication
Patch management practices and security patch management updates. You need to ensure these are done in a timely fashion.
Malware protection to prevent unauthorized code execution.

The operator should also ensure that security is maintained during the operation of the software medical device and is not compromised. They need to ensure the correct amount of security for the operational environment. These are the sorts of things you need to clearly define in your instructions for use or in the software itself (including any infrastructure and training requirements).

There are some additional guidelines on setting up security management for your device in compliance with MDR cybersecurity. There are eight practices that should be followed:

Security Management – All security-related activities should be adequately planned and documented.
Specification of Requirements – These must be defined basically how you would with your software specifications.
Security by Design – You should have gone through your design process in compliance with the device and incorporated cybersecurity.
Implementation – Making sure that cybersecurity design has been implemented properly. If there are procedures on software releases, you need to ensure those are followed.
Verification and Validation Testing – This means defining those activities and tying them to the risk of your software, then performing testing.
Management Security – Handling security-related issues if they do arise and add to the risk of your software, and performing testing.
Update Management – Defining how you would assess any risks and roll out any updates.
Security Guidelines – Used to provide user documentation on how to maintain a strategic cybersecurity approach to the software they are using.

Final thoughts

There are a lot more parts to the guidance which I could go into further but will save for another post. For example, managing design controls and other key aspects of the cybersecurity design process.

For now, these are the basic areas that you will need to cover as an overview of meeting MDR cybersecurity requirements. The good news is you have a little time. The delay in the effective date gives you another 12 months to prepare, although it’s always better to be prepared early.

If you need assistance from a consultant, Rook Quality Systems are here to help.

About the Author:

Kyle Rose is the President of Rook Quality Systems, a medical device consulting firm that helps startup medical device companies around the world with their quality and regulatory needs. They have a team of Quality Engineers that assist with medical device documentation, creating quality systems and software verification and validation.