Software in Medical Devices, by MD101 Consulting

Section 1 - Introduction

The first section of the guidance draws the link between regulatory requirements and cybersecurity processes / artifacts. The figures 1 & 2 are quite a good synthesis of the MDR requirements covering cybersecurity. Note that these figures could be duplicated with several other topics, like electrical security, biocompatibility (and so on), and state-of-the-art applicable standards.
The topics listed in section 1.4 cover all topics where cybersecurity is involved. This list is very useful to assess where cybersecurity requirements shall be implemented in your QMS processes. E.g: design controls, post-market surveillance.

Section 2 - Basic cyber concepts

If you've already read documents like AAMI TIR 57 or the 2 FDA guidances on cybersecurity, you will retrieve in this section some information common to these documents. The novelty in this MDCG guidance is the link between these concepts and the MDR General Safety and Performance Requirements (GSPR).
We also retrieve in this section concepts of defense in depth, good security hygiene (basic security hygiene in FDA guidance), and the relationship between security risks and safety risks.
Another concept is introduced, not so easily found in other guidance: the link between usability engineering and cybersecurity:
[a vulnerability] should be regarded as an enabler of reasonably foreseeable misuse .
If an exploit exists, an user will use it with a probability to assess, linked to the user's education level and the ease of exploitation based on use scenarios.

The concept of joint responsibility is also introduced. All stakeholders in the supply chain shall take their part of the job: medical device integrators operators, and users. Manufacturers, don't be fooled by this joint responsibility: as usual, your responsibility will be engaged in case of adverse event. You shall have established processes to ensure the proper installation, deployment, configuration, and exploitation of your devices in a secure manner. Simply said, this joint responsibility doesn't exonerate manufacturers. Quite the opposite, it engages the responsibility of other stakeholders.

Section 3 - Secure design and manufacture

Section 3 delves into technical details (as far as a guidance can do, it's not a standard), with a list of good practices to ensure that the device is secure by design. These 6 best practices can be seen as the steps of processes found in IEC 62304 design and maintenance processes:

1. Security management:
   1. 4.1 of ISO 13485, for the security risk management process
   2. 5.1 of IEC 62304: Software development plan
   3. 6.1 of IEC 62304: Software maintenance
2. Specification of Security Requirements:
   1. 5.2 of IEC 62304: software requirements analysis
3. Secure by design, including defense in depth:
   1. 5.3 of IEC 62304: software architecture
4. Secure implementation:
   1. 5.4 of IEC 62304: software detailed design
   2. 5.5 of IEC 62304: software implementation and unit verification
   3. and a precision on SOUP management
5. Secure Verification and Validation
   1. 5.6 of IEC 62304: software integration testing
   2. 5.7 of IEC 62304: software system verification
6. Management of security-related issues
   1. 6.2 of IEC 62304: Problem and modification analysis
   2. 9 of IEC 62304: Problem resolution
7. Security update management
   1. 6.3 of IEC 62304: Modification implementation
   2. 8.2 of IEC 62304: Change control
8. Security guidelines:
   1. 5.8 Software release
   2. and also software documentation, see IEC 82304-1 section 7.

Security Risk management

Section 3.2 continues with recommendations on the security risk management process, especially the link between security risks and their impact on safety. A very important remark is present in this section, for the sake of clarity of safety risk management reports: safety risk assessment might list generic security related hazards (...). This is to avoid detailing every possible attack vector.
This section also insists on the fact that compliance to GSPR 1 to 4 requires to assess security risks. Thus, cybersecurity isn't nested only in GSPR 17.2 on software, but is promoted to the first main GSPR's.

Security capabilities

Section 3.3 lists some possible security capabilities for software. This list is absolutely not exhaustive. This is a good starting point, though.
Interestingly, this section also contains an analogy between the precedence of safety mitigation actions (section 6.2 of ISO 14971) and their security risk equivalent. Worth reading!
This section ends with a remark on the need to maintain safety and effectiveness but also performance requirements and efficiency of mitigation actions, with security capabilities. New columns to your risk assessment matrices?

Minimum IT requirements

Section 3.6 gives an indicative list of IT security requirements. You can take this list as the equivalent of the annex C of ISO 14971:2009 (not 2019, you will have to pay twice but this is another subject).
This section also gives recommendations on accompagnying documents about cybersecurity. It's funny to read that they recommend to have these instructions in electronic format (hello regulation 207/2012/EU, e-IFU isn't a risk, it's a mitigation action!).

Verification and validation

This rather short section, is actually too short! If you want to know everything about verification of security measures, go to UL 2900-1 and UL 2900-2-1.

Lifecycle aspects

This last sub section of section 3 covers the support processes with respect to cybersecurity. It is elaborated in section 5 of the MDCG guidance. The best method is to update your current software maintenance process and problem resolution process to add provisions about security feedback and problems. Likewise, the PMS report or PSUR shall contain a section about cybersecurity.

Section 4 - Documentation on IFU

This section deals with all GSPR 23.x, on how to see them from the point of view of security. It's a very useful section, to fill your answers to GSPR matrix template. The recommendations on information to the users also overlap with the requirements found in IEC 82304-1. Likewise, this section is useful to add new sections about cybersecurity in your IFU template.

Section 5 - PMS and vigilance

Section 5 makes the link between regulatory requirements on PMS / vigilance, and cybersecurity. It makes a short recall on PMS, incidents and serious incidents. Examples of security events that have to be considered as incidents are given in annex II. The best way to follow these recommendations is probably to update your PMS process (PMS plans, PSUR templates) to add provisions to manage security incidents, like any other incident.
This section ends with a reference to the IMDRF reporting tool. But there is no explanation on why the MDCG relies on this tool, nor is there any reference to the IMDRF elsewhere in the guidance. Some other guidances are expected on reporting tools. The mystery remains...

Conclusion

Compared to FDA guidances, the MDCG 2019-16 covers of both premarket and post market FDA cybersecurity guidances. It is a good surprise in the regulatory landscape.
In terms of compliance for manufacturers, I suggest to put this document in an excel sheet and do a traceability matrix to ensure the right application of all the recommendations (requirements!) contained in these 46 pages.