Regulatory requirements

Cybersecurity is not (and should not be) limited to compliance, but the regulations provide the minimal objectives to be met.

Reviewing the requirements

Guidance documents from FDA, Health Canada, the TGA, ANSM were analyzed to map and contrast requirements. Within each country, requirements that contained related information were included in the same section and were compared to one or more requirements from another international guidance. There are a total of 70 categories that have one or more international guidance requirements. For this analysis, medical device premarket guidance was the focus and note there are other regulatory bodies (e.g. EU General Data Protection Regulation, California Consumer Privacy Act (CCPA)) that have similar expectations for a wider application. It is important to note that all of the guidance documents analyzed are in draft form at the time of our study.

We now describe the similar high-level requirements that come from that analysis. We don't cover the requirements that only appear in one of the documents, but they are of course important too.

Software patches and updates

The US, Canada, Australia, and France all have requirements for anticipating software patches. There is a clear consensus that the device should be designed to anticipate patches and updates.

The FDA specifically refers to rapid deployment of patches and updates while the other three guidance documents do not include a component for timing. Additionally, only the FDA asks that devices be designed to facilitate testing of patches and updates.

Health Canada and ANSM similarly consider updating devices throughout their lifecycle, with Canada explicitly including third party/open-source software updates as well.

France takes a more general approach- asking that operating systems are up to date and that the operation of the medical device cannot impair the application of security requirements. In the EU more generally, regulation 2017/745 provides the new framework.

An interesting observation is that while the US calls for authentication of both firmware and software, Australia does not broadly discuss software authentication. This portion of the TGA guidance encourages implementing code signing solely for firmware updates. Conversely, France and Canada only discuss authentication of software, and do not explicitly include language surrounding firmware.

Beyond the healthcare use case, attacks on the patching process (ex: solarwinds) should be reviewed in detail, and lessons learned should be included in your own process.

User authN/authZ

All four guidance documents analyzed make recommendations for trusted user authorization and authentication management. Each document supports limiting access to devices by assigning privileges to users based on commensurate job requirements. A notable difference here is that the US includes explicit language around patient safety concerns arising from a cybersecurity incident. The FDA guidance states that a loss of confidentiality of credentials could be exploited and even result in multi-patient harm.

Encryption

Each guidance document contains requirements regarding encryption of data at rest and in transit. The FDA details the relevance to patients in stating that a “lack of encryption to protect sensitive information ‘at rest’ and ‘in transit’ can expose this information to misuse that can lead to patient harm.” Although the FDA is the only regulatory body to explicitly address patient safety in this section, all documents contain an overarching theme of patient safety.

One miss from the FDA that ANSM includes is that the medical device must be relatively autonomous in terms of security (secure network access). This section of the ANSM guidance is not a 1:1 matching to the concept of encrypting data at rest and in transit, however it is a unique requirement in that it implies MDMs must work with HDOs to establish network segmentation. The requirement from France is not as explicit as the other three countries and is more general in that it calls for “encryption of sensitive data” in a broader requirement pertaining to the environment of device use.

No mention of encryption at runtime (e.g. TEE, homomorphic encryption) is made.

Secure network communication

Health Canada and the TGA encourage manufacturers to consider how a device interfaces with other devices or networks. This is something that the FDA has not outlined in the premarket guidance that should be seriously considered.

Health Canada states that the manufacturer should consider design controls that take into account a device that communicates with a system or a device that is less secure. A unique addition from Canada is the notion that Health Canada only has authority if a data breach results in patient harm.

The TGA pushes for the provision of information on cybersecurity for users, including plain-language information. As many device users may not have a deep technical understanding of cybersecurity of devices, an aspect of security is providing information for individuals with varying levels of experience or understanding. No other draft guidance provides this kind of requirement.

ANSM discusses wireless connections, while Health Canada goes beyond and includes wireless and hardwired connections. ANSM states that the connected medical device should be compliant with current good practices requirement when implementing wireless communications. ANSM specifically mentions Wi-Fi mode and refers to the The National Cybersecurity Agency of France (ANSSI) website for good practices for securing Wi-Fi access. Another related and highly interesting requirement from ANSM suggests the option of using a VPN for greater security within a local network. They provide an example of a medical device used in a patient’s home in which the use of a VPN between the device at home and the hospital can help protect the data exchanged.

Example of network mapping

Risk management

Requirements regarding security documentation and risk assessment strategies are outlined in each country. The suggested documentation from the FDA is derived from AAMI TIR57 Principles for medical device security- Risk management, a technical information report that illustrates how to apply to security threats the principles outlined in ISO 14971, a standard that specifies a process for MDMs to identify hazards associated with medical devices. Health Canada and the TGA also make references to ISO 14971, to address this category of their standards.

A notable difference from the FDA is the use of exploitability versus probability to quantify risk. In the US guidance this risk analysis section focuses on security documentation and recommends providing descriptions of risk leveraging an analysis of exploitability to describe likelihood rather than probability. Health Canada and the TGA also make reference to this concept. ANSM does not include requirements regarding exploitability.

ANSM takes another approach to risk management and promotes the production of software that is “secure by construction.” The requirement asks that MDMs justify the choice of programming language and states that software development will need to comply with encoding rules that allow for automation of vulnerability detection.

Supply chain management

All regulatory bodies have requirements regarding cybersecurity hazards and threat modeling. The FDA focuses on considering system level risks and supply chain risks. Health Canada outlines a checklist of general things a manufacturer should do to evaluate and control risk. The TGA asks that MDMs consider cybersecurity practices for manufacturing and the supply chain. ANSM calls for risk analysis, policy for managing and purchasing software components, and verification methods for ensuring there are no vulnerabilities in the software.

One difference noted here is that Health Canada does not have language involving the supply chain unlike the other three guidance documents.

Note that supply chain management should include both software and hardware, as firmware attacks are on the rise.

Cybersecurity testing

Each of the four guidance documents contain language surrounding testing, thought with slightly different requirements. The FDA focuses on ensuring there are adequate cybersecurity risk controls. Health Canada focuses on four different kinds of testing: known vulnerability testing, malware testing, malformed input testing, structured penetration testing. The TGA focuses on implementing penetration testing- with an additional guideline asking that manufacturers take action on the outcomes of the penetration testing. France also makes an interesting distinction in this guidance. France proposes that dead code, or code that is not specified and not testable, be deleted. Justification must be provided for all lines of code not covered by the tests.