Christopher Gates, Director of Product Security, Velentium07.20.23
The best representation of current FDA expectations on medical device cybersecurity is the April 8, 2022, “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions Draft Guidance for Industry and Food and Drug Administration Staff,” or more simply, the “April Premarket Guidance.”
In this publication, the FDA requires manufacturers to implement cybersecurity measures during the design and development stages of medical devices. While they allow the manufacturer to develop their own processes to achieve this goal, they also seem to imply that basing your processes on an existing standard would be the preferred approach. This is probably due to the industry-wide lack of training and subsequent knowledge required for each organization to properly formulate a secure development process in-house.
The FDA mentions a couple of standards as good candidates for defining this process. Their list includes:
So, what are the more current standards? Well, the HSCC is revising the JSP to version 2 (full disclosure: I happen to be on this working group), and it is shaping up to be an “instructional guide” for organizations trying to incorporate security into their development processes. While it can and will be a very useful document, it is less of a true “standard” by comparison to a real regulatory standard from ISO/IEC. The JSP v2 has not been released yet, but probably will be by the end of 2023.
IEC 62443-4-1 has not been revised, but the IEC has released a new standard focused on cybersecurity issues impacting software in connected health technologies. This includes medical devices as well as consumer-oriented health products and applications. IEC 81001-5-1 “Health software and health IT systems safety, effectiveness and security — Part 5-1: Security — Activities in the product life cycle” was released in December 2021 after three years of work by the committee. It is a variant from IEC 62443-4-1 and a bit of an update to the venerable (some would say “out of date”) IEC 62304:2006. IEC 81001-5-1 is an excellent document that establishes a common framework for the lifecycle processes related to all types of “health software.” Quoting directly from the standard:
“HEALTH SOFTWARE: software intended to be used specifically for managing, maintaining, or improving health of individual persons, or the delivery of care, or which has been developed for the purpose of being incorporated into a medical device. HEALTH SOFTWARE fully includes what is considered software as a medical device.”
To summarize, this includes medical devices, health and wellness applications, and “Software As a Medical Device” (SaMD).
To anyone familiar with other ISO/IEC publications, such as ISO 13485, IEC 62304, and ISO 16485, this document will seem very comfortable and easily fit into existing development processes.
The body of the document is structured into six sections:
Section 5 is the most relevant to the development process, and is further broken down into eight subsections:
In addition, there are seven annexes that cover a wide range of technical issues, from threat modeling to traceability back to IEC 62443-4-1. IEC 81001-5-1 is expected to be designated by the EU Commission as a harmonized standard under the MDR sometime in 2024. Further, it is likely to be recognized by the U.S. Food and Drug Administration as a “consensus standard” that can be used during premarket submissions.
IEC 81001-5-1 is an excellent standard to incorporate into development activities. It can immediately provide a framework into which additional processes can be incorporated. In fact, this is exactly what you will need to use to add structure to the FDA’s unstructured approach as detailed in the April Premarket Guidance. By walking through the FDA’s guidance, identifying the activities it calls out, and adding them into the 81001-5-1 framework, you can create clarity for your development teams about what activities are needed during each phase of development. Best of all, by using this approach, your development effort will be compliant with both the MDR and the FDA—that in itself is sufficient reason to implement IEC 81001-5-1.
Another standard (a less important consensus standard) that has also been released recently (February 2022) is NIST SP 800-218 “Secure Software Development Framework (SSDF) Version 1.1 Recommendations for Mitigating the Risk of Software Vulnerabilities.” This is not required by any country, nor is its focus on medical device software. However, it is an interesting approach to the security of the development lifecycle and associated activities.
In next month’s column, I will review NIST’s SSDF and demonstrate how IEC 81001-5-1—the FDA’s premarket guidance—and the SSDF can all coexist in a very secure development process.
Christopher Gates is the director of Product Security at Velentium. He has more than 50 years of experience developing and securing medical devices and works with numerous industry-leading device manufacturers. He frequently collaborates with regulatory and standard bodies, including the CSIA, Health Sector Coordinating Council, H-ISAC, Bluetooth SIG, and FDA to present, define, and codify tools, techniques, and processes that enable the creation of secure medical devices.
In this publication, the FDA requires manufacturers to implement cybersecurity measures during the design and development stages of medical devices. While they allow the manufacturer to develop their own processes to achieve this goal, they also seem to imply that basing your processes on an existing standard would be the preferred approach. This is probably due to the industry-wide lack of training and subsequent knowledge required for each organization to properly formulate a secure development process in-house.
The FDA mentions a couple of standards as good candidates for defining this process. Their list includes:
- The Health Sector Coordinating Council’s (HSCC) Joint Security Plan (JSP) v1 January 2019
- IEC 62443-4-1: 2018 Security for industrial automation and control systems - Part 4-1: Secure product development lifecycle requirements
So, what are the more current standards? Well, the HSCC is revising the JSP to version 2 (full disclosure: I happen to be on this working group), and it is shaping up to be an “instructional guide” for organizations trying to incorporate security into their development processes. While it can and will be a very useful document, it is less of a true “standard” by comparison to a real regulatory standard from ISO/IEC. The JSP v2 has not been released yet, but probably will be by the end of 2023.
IEC 62443-4-1 has not been revised, but the IEC has released a new standard focused on cybersecurity issues impacting software in connected health technologies. This includes medical devices as well as consumer-oriented health products and applications. IEC 81001-5-1 “Health software and health IT systems safety, effectiveness and security — Part 5-1: Security — Activities in the product life cycle” was released in December 2021 after three years of work by the committee. It is a variant from IEC 62443-4-1 and a bit of an update to the venerable (some would say “out of date”) IEC 62304:2006. IEC 81001-5-1 is an excellent document that establishes a common framework for the lifecycle processes related to all types of “health software.” Quoting directly from the standard:
“HEALTH SOFTWARE: software intended to be used specifically for managing, maintaining, or improving health of individual persons, or the delivery of care, or which has been developed for the purpose of being incorporated into a medical device. HEALTH SOFTWARE fully includes what is considered software as a medical device.”
To summarize, this includes medical devices, health and wellness applications, and “Software As a Medical Device” (SaMD).
To anyone familiar with other ISO/IEC publications, such as ISO 13485, IEC 62304, and ISO 16485, this document will seem very comfortable and easily fit into existing development processes.
The body of the document is structured into six sections:
- Section 4: General requirements
- Section 5: Software development process
- Section 6: Software maintenance process
- Section 7: Security risk management process
- Section 8: Software configuration process
- Section 9: Software problem resolution process
Section 5 is the most relevant to the development process, and is further broken down into eight subsections:
- Section 5.1: Software development planning
- Section 5.2: Health software requirements analysis
- Section 5.3: Software architectural design
- Section 5.4: Software design
- Section 5.5: Software unit implementation and verification
- Section 5.6: Software integration testing
- Section 5.7: Software system testing
- Section 5.8: Software release
In addition, there are seven annexes that cover a wide range of technical issues, from threat modeling to traceability back to IEC 62443-4-1. IEC 81001-5-1 is expected to be designated by the EU Commission as a harmonized standard under the MDR sometime in 2024. Further, it is likely to be recognized by the U.S. Food and Drug Administration as a “consensus standard” that can be used during premarket submissions.
IEC 81001-5-1 is an excellent standard to incorporate into development activities. It can immediately provide a framework into which additional processes can be incorporated. In fact, this is exactly what you will need to use to add structure to the FDA’s unstructured approach as detailed in the April Premarket Guidance. By walking through the FDA’s guidance, identifying the activities it calls out, and adding them into the 81001-5-1 framework, you can create clarity for your development teams about what activities are needed during each phase of development. Best of all, by using this approach, your development effort will be compliant with both the MDR and the FDA—that in itself is sufficient reason to implement IEC 81001-5-1.
Another standard (a less important consensus standard) that has also been released recently (February 2022) is NIST SP 800-218 “Secure Software Development Framework (SSDF) Version 1.1 Recommendations for Mitigating the Risk of Software Vulnerabilities.” This is not required by any country, nor is its focus on medical device software. However, it is an interesting approach to the security of the development lifecycle and associated activities.
In next month’s column, I will review NIST’s SSDF and demonstrate how IEC 81001-5-1—the FDA’s premarket guidance—and the SSDF can all coexist in a very secure development process.
Christopher Gates is the director of Product Security at Velentium. He has more than 50 years of experience developing and securing medical devices and works with numerous industry-leading device manufacturers. He frequently collaborates with regulatory and standard bodies, including the CSIA, Health Sector Coordinating Council, H-ISAC, Bluetooth SIG, and FDA to present, define, and codify tools, techniques, and processes that enable the creation of secure medical devices.