In medical device development, focus is mainly on innovation, functionality, and time-to-market, while cybersecurity can sometimes take a back seat – often viewed as something to tack on at the end, instead of carefully thought out and planned for throughout the development process. This lack of emphasis can result in costly recalls, regulatory challenges, and potential risks to patient safety.
Regulatory bodies are increasingly emphasizing the importance of cybersecurity due to the growing complexity and connectivity of medical devices. Guidance documents, such as the FDA Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, FDA Postmarket Management of Cybersecurity in Medical Devices, MDR in the EU, and standards such as IEC 81001-5-1 (also included in Japan’s PMDA since April 1 2024) underscore the expectation that security is not an afterthought but a core design consideration.
In this two-part series, we will examine how cybersecurity considerations should be integrated throughout the entire development process to ensure strong cybersecurity in compliance with relevant regulations and standards. This first article focuses on how an organization should assess its capabilities and identify the requirements necessary during the concept and design phase, as well as the development phase. The second part of this series will address the requirements needed during the pre-submission and post-market stages.
Internal audit of capabilities
From the outset, companies must first assess their readiness to develop connected medical devices that comply with cybersecurity regulations. This assessment should evaluate the relevant teams’ understanding of cybersecurity practices, which includes secure software development, threat modelling, encryption, authentication, and vulnerability management, and include a review of their internal capabilities in embedded systems engineering, wireless communication protocols, and secure integration with mobile and cloud platforms. The assessment should also gauge the company's familiarity with regulatory frameworks and examine its own QMS systems to ensure they are robust enough to meet regulations at each stage.
The results of this assessment often lead to a strategic decision: whether the company has the internal resources to independently build the device securely or whether it should seek external partners to address critical gaps.
To help with this decision, let’s examine a checklist of the main requirements needed at each phase of device development.
Concept and design phase
Medical device asset process
Developers must begin by cataloging all assets, including hardware, software, firmware, and network interfaces. They must also identify and catalog the data that will be collected by the device, particularly sensitive patient health information, allowing for the identification of vulnerabilities. To maintain strong security, it's crucial to establish continuous asset monitoring and update the framework to adapt to evolving threats, especially when implementing new features or responding to emerging risks.
Threat modeling process
Threat modeling is a structured approach to identifying, evaluating, and mitigating potential cybersecurity threats early in the design and development process of a medical device. Developers must map out the system architecture to understand how different components will interact and identify potential vulnerabilities. Once threats are identified, developers must evaluate their potential impact and likelihood and then implement mitigations accordingly. This must be an iterative process that evolves alongside the device.
Security risk management process
The outputs of the threat modeling process serve as critical inputs to the security risk management process, helping inform risk assessments with a detailed understanding of potential threat scenarios and system vulnerabilities. This step involves conducting thorough risk assessments to evaluate potential vulnerabilities and their consequences for patients and healthcare systems. Developers must implement and test security controls like access restrictions, data encryption, and intrusion detection to reduce risks to acceptable levels. These efforts must comply with regulations such as the FDA’s Quality System Regulation and IEC 81001-5-1. Additionally, risk mitigation strategies and justifications should be well-documented for regulatory submissions and post-market monitoring.
Integration with safety risk management assessment
Cybersecurity and safety are inherently intertwined in medical device development. A failure in cybersecurity, such as unauthorized access or data manipulation, can directly lead to patient harm, making it a safety issue as much as a security one.
To effectively address this, risk control measures must consider both intentional (cyber-related) and unintentional (system or user error) failures. Collaboration between cybersecurity and safety engineering teams is essential for identifying overlapping risks and avoiding conflicting mitigation strategies. This joint approach aligns with regulatory expectations, which stress the importance of a holistic view of risk. Medical device developers should be striving to meet the SW-96 Safety and Security Risks standard.
Development phase
Security architecture
Developers must design systems that integrate security principles at all levels; hardware, software, and network. The FDA advocates for a ‘Zero Trust Architecture’ approach, requiring strict verification for every access point rather than automatically trusting users, processes, or devices. Communication protocols should ensure secure data transmission through encryption and authentication to protect sensitive health information.
Additionally, system architecture must enable compartmentalization to isolate critical functions and minimize the attack surface. Access control policies must restrict interactions with key functions to authorized personnel or systems. Lastly, the architectural planning should include considerations for a secure boot process, firmware validation, and secure over-the-air (OTA) updates.
Development and implementation of secure practices
During development, embedding secure practices in every aspect of software and hardware engineering is crucial. This starts with using secure coding standards to prevent vulnerabilities. Robust authentication and authorization mechanisms are needed to ensure that only verified users access sensitive data. Strong encryption must protect data at rest and in transit. Security-focused code reviews and static analysis help identify weaknesses early, while threat-driven testing, like penetration testing, assesses resilience against attacks.
Tracking the SBOM
The SBOM (Software Bill of Materials) lists all software dependencies, including third-party libraries and open-source components. Keeping it updated helps manufacturers track software components and identify potential vulnerabilities. When new issues are discovered in databases like the Common Vulnerabilities and Exposures (CVE), developers can swiftly determine if their components are affected, allowing for rapid patching and ensuring medical devices stay secure against emerging threats.
Security testing
This phase involves rigorous testing to identify vulnerabilities and assess the device's resilience to cyber threats. It typically involves penetration testing, vulnerability scanning, and fuzz testing to evaluate resistance to unauthorized access and malicious activities.
Penetration testing is a process that simulates cyberattacks to identify vulnerabilities, ensuring the security and integrity of the medical device. This testing phase includes vulnerability scanning, binary analysis, and protocol examination to protect patient data and maintain device reliability. It is part of the regulatory compliance process, often conducted by certified third parties, and aligns with FDA standards like UL 2900. The results must be documented to demonstrate compliance.
Vulnerability analysis entails a thorough assessment to identify and address potential security weaknesses that cyber threats could exploit. The process includes rigorous testing such as vulnerability scanning, penetration testing, and fuzz testing to evaluate the device's resilience against unauthorized access and malicious activities. Additionally, it involves continuous monitoring of emerging threats and vulnerabilities through resources like the Common Vulnerabilities and Exposures (CVE) database, as well as implementing rapid patching to ensure ongoing security.
In summary
The requirements covered in this article play a pivotal role in embedding robust cybersecurity into medical devices. However, effective cybersecurity doesn’t end once a device is built — it must be maintained, updated, and protected throughout its entire lifecycle.
In part 2 of this series, we examine the requirements after development, diving into the critical steps of regulatory submission, post-market surveillance, and long-term risk management.
To learn more about how we work with medtech companies to manage their cybersecurity requirements, get in touch with us today.
