How To Prove (Or Improve) The Trustworthiness Of Your Medical Devices

As medical devices grow in complexity and become increasingly interconnected through networks and communication  links, their vulnerability to attacks from hostile elements or failures due to inherent defects or exploited vulnerability increases the risk of significant impacts to healthcare, users, or patients depending on them. Cybersecurity has become of paramount importance in the development, approval, and commercialization of medical devices. The FDA, Health Canada, the EU's Medical Device Regulation (MDR) and In Vitro Diagnostics Regulation (IVDR), and Australia's Therapeutic Goods Administration (TGA) all expect a holistic, risk-based approach to the design, manufacture, deployment, maintenance, and servicing of medical devices, with suitable and ever-vigilant cybersecurity protection ensuring trustworthy devices.

What Do The Regulations Say About Making Medical Devices Trustworthy?

Ensuring medical devices are trustworthy is vitally important as we become more dependent on them for reliable, secure, and safe operation. The FDA in its draft guidance defines a "trustworthy device" as a medical device containing hardware, software, and/or programmable logic that: (1) is reasonably secure from cybersecurity intrusion and misuse; (2) provides a reasonable level of availability, reliability, and correct operation; (3) is reasonably suited to performing its intended functions; and (4) adheres to generally accepted security procedures.

Health Canada has taken a similar approach to the FDA with its basis on the National Institute of Standards and Technology's (NIST) Cybersecurity Framework and well-crafted pre-market guidance that requires manufacturers to have a cybersecurity strategy for any medical device that runs software code that includes secure design, cybersecurity risk management, objective evidence, and a plan for continued monitoring and applicable response to risks, vulnerabilities, and threats.

The European Commission with its new regulations on medical devices and in vitro diagnostic medical devices further established that design documentation shall demonstrate that the medical device is trustworthy. Specifically, the MDR states in general requirements (GR): "Devices shall achieve the performance intended…and shall be designed and manufactured in such a way that, during normal conditions of use, they are suitable for their intended purpose... They shall be safe and effective and shall not compromise the clinical condition or the safety of patients, or the safety and health of users..." (Annex I, No. 1).  The principle of integrated security can be deduced from Annex I, No. 4: safe design and manufacture; adequate protective measures regarding those risks that cannot be excluded; safety information; and, if necessary, training. Furthermore, Annex I, No. 17 spells out that devices "shall be designed to ensure repeatability, reliability, and performance in line with their intended use… taking into account the principles of the development life cycle, risk management, including information security, verification, and validation." Lastly, EU's MDR mandates that medical device manufacturers are to set the requirements regarding protection from unauthorized access. 

Australia's TGA considers medical device security as part of the social trust in the healthcare system and as such requires medical device manufacturers, irrespective of the classification of the device, to generate and maintain evidence to manage cybersecurity, akin to a safety concern, consideration, and minimization of risks that are imperative for compliance with many aspects of the Essential Principles legislation.

Where And How To Document Your Device's Trustworthiness

The question is: How do you prove (or improve) the trustworthiness of your medical device? What is the objective evidence necessary to show that the device performs as intended for its specific purpose, when needed, with operational resiliency, and without unwanted behaviors or exploitable vulnerabilities? The following list of suggested activities is not exhaustive but provides the type of information and objective evidence that would ensure that when the time comes for a submission for commercialization and/or inspection, medical device manufacturers will be ready to prove the trustworthiness of their device.

Design History File

The compilation of records that describe and establish the design history of a finished device is the starting point to demonstrate that cybersecurity has been considered in its design, including identification of the hazards and risks associated with its intended purpose, the elimination or reduction of the identified risks as far as possible, and the adoption of measures to address any risks that cannot be eliminated. Some of the objective evidence that would demonstrate and establish such trust would be:

1. Cybersecurity analyses of threats and risks, including system boundaries and operating environment and based on those analyses, the corresponding corrections and countermeasures
2. Documented review of software components with known and unknown vulnerabilities
3. Based on risk analysis, implemented detection and protection against malware
4. Simulate an attack and demonstrate that the functionality of the medical device is retained, and the medical device is capable of returning to normal operation with the full range of functions.
5. Implement independent cybersecurity design review gates, where the objective evidence is captured as part of the design history file.
6. Apply the same philosophy and approach on patch management and updates to updates to the operating systems.
7. Document the activities that have been taken to protect:
   1.  Data in transit
   2.  Data at rest
   3.  Data in use
8. Testing protocols and results against known vulnerabilities and malware
9. Protocols, methodology, and results on fuzzing (malformed input testing where the device is being challenged with invalid or unexpected inputs)
10. Static application security testing (SAST) and dynamic application security testing (DAST) results and touchpoints with the rest of the development process

The summary record of all design actions, from start to transfer, including changes, has all the information necessary to show that the design was developed in accordance with a design plan and the quality systems requirements, including cybersecurity.

Device Master Record

The finished design output is the basis for the device master record (DMR), which includes device and production specifications, in addition to the acceptance criteria to be used and packaging and installation, maintenance, and servicing instructions. The DMR is where the installation procedure and description of any cybersecurity-related aspects during installation and initial configuration would be captured. For example, that may include firewall and network configuration, initial passwords that need to be changed, integration into the customer's network infrastructure, and training that needs to be completed before the handover of the medical device. Also, it would be advisable to have a description of what the customers/users can do, how they should do it, and the associated training program that would accompany the device. The DMR should also include the product release criteria, where the in-process or final inspection process demonstrates that medical devices are not being shipped with outdated, no longer supported, or vulnerable components. It is important to consider the creation of the software bill of materials (SBOM) process and format, where all the software and hardware components are listed to be communicated to users and buyers.

Last, and very importantly for SaMD or connected medical devices, the mechanism and process for both software and security patches must demonstrate cybersecurity, including consideration of remote connectivity as part of the maintenance process.

Device History Record/Service Record

The device history record and, once the device is installed, its service record, if available, contain the evidence to demonstrate that the device was manufactured, shipped, installed, and/or serviced according to the DMR. It should be made clear that servicing of medical devices by entities other than the OEM, according to the FDA, raises cybersecurity challenges because privileged access is needed to perform the necessary diagnostic, maintenance, and repair functions.

The aforementioned SBOM process is critical to demonstrate that before the commercial release of the medical device, all publicly known vulnerabilities have been evaluated and at the time of the release, the device had met its trust threshold.

Evidence and Procedures in the Quality Management System

Each medical device manufacturer can (and should) develop a quality system commensurate with the risk and complexity of the device, its manufacturing process, and any other activities associated with the safe use of such device(s). The following are some of the processes in which cybersecurity is created or embedded within the existing QMS:

1. Process for the detection, reporting, assessment, and containment of potential incidents regarding cybersecurity of patients, users, and third parties, including reporting to pertinent regulatory authorities
2. Process for customer notification of patch management
3. Update existing procedures and frameworks to include and consider cybersecurity:
   1.  Risk management
   2.  Change control
   3.  Complaint management
   4.  Recall and field action
   5.  CAPA
   6.  Internal audit
   7.  Management review
   8.  It would be advisable to initiate a comprehensive quality plan to evaluate and document the categories of products, systems, policies, and SOPs based upon an impact analysis, perform a gap analysis, and take appropriate actions based upon a determination of risk.

The suggested way to view medical device cybersecurity is similar to that for other risks: If cybersecurity risk is not effectively minimized or managed, it can result in compromised device functionality, loss of data (medical or personal) availability or integrity, or exposure of other connected devices or networks to security threats. This, in turn, may have the potential to result in patient illness, injury, or death.

Conclusion

Medical device cybersecurity has created a management environment in which cybersecurity is no longer confined to a singular department or function — it has been accepted as one of the priorities of regulatory agencies and patients alike and requires that cybersecurity strategies are aligned with the manufacturer's objectives and needs. Senior management needs to accept the idea that medical device cybersecurity is not a technical issue but a business one.

We should consider medical device cybersecurity as a collection of tools, policies, concepts, safeguards, guidelines, risk management approaches, actions, training, best practices, and technologies that can be used to protect patients and users and bring about trust, which can only be in an environment of active threats, not passive failures. Manufacturers will continue facing ever-increasing demands in the cybersecurity of their products; those who can demonstrate trustworthiness will have a leg up on the competition and the oversight of regulators.

About The Author:

John Giantsidis is the president of CyberActa, Inc, a boutique consultancy empowering medical device, digital health, and pharmaceutical companies in their cybersecurity, privacy, data integrity, risk, SaMD regulatory compliance, and commercialization endeavors. He is also a member of the Florida Bar's Committee on Technology and a Cyber Aux with the U.S. Marine Corps. He holds a Bachelor of Science degree from Clark University, a Juris Doctor from the University of New Hampshire, and a Master of Engineering in Cybersecurity Policy and Compliance from The George Washington University. He can be reached at john.giantsidis@cyberacta.com.