Medical device manufacturers must increasingly devote resources to identifying and managing cybersecurity risks and features of their devices. Devices that once might have been considered to have no network connectivity have been brought into regulatory focus as cyber devices with FDA’s most recent guidance on cybersecurity, “Select Updates for the Premarket Cybersecurity Guidance: Section 524B of the FD&C Act.” Because cybersecurity must be designed into the product to be effective, security is a core requirement of the product.
But we already have design controls and IEC 62304 “Medical device software – Software life cycle processes” – isn’t that enough? True, IEC 62304’s Software Development Life Cycle (SDLC) does require consideration of security requirements during software requirements analysis. But creating a secure-by-design device is more than documenting that “the device should be secure,” and there is more to ensuring secure medical devices than writing requirements.
FDA’s guidance “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions” recommends use of a Secure Product Development Framework, one of which is embodied in IEC 81001-5-1:2021, “Health software and health IT systems safety, effectiveness and security – Part 5-1: Security – Activities in the product life cycle.” Fortunately, this framework aligns well with the SDLC of IEC 62304, so it is relatively straightforward to embed secure design practices in an existing software development lifecycle used for Software in a Medical Device (SiMD) or Software as a Medical Device (SaMD).
Figure 1. Some key differences at the intersection of IEC 62304 and IEC 81001-5-1.
A few adjustments can be made to existing SDLC processes and templates to accommodate cybersecurity, for example:
- Add development environment security and post-market support for patching and updating to the Software Development Plan to cover security issues.
- Add defense-in-depth or other secure architecture approaches to your architectural design to build a solid foundation.
- Secure your software units with secure interface design and secure coding practices.
- Add threat mitigation, vulnerability and penetration testing to your verification test suite.
- Determine how you will ensure file integrity from development to production to the customer.
- Build a post-market vulnerability monitoring and patching program.
Adjusting your documentation practice is relatively minor. The bigger shift is the change in mindset required to accommodate security-based thinking. That is a change project for another day and another column.
For expert guidance on developing secure medical devices, contact MEDIcept today at sales@medicept.com
Gregg Van Citters – Senior Software Quality Engineer