At Qity, we have had the privilege of collaborating with numerous researchers, developers, and manufacturers in the medical device industry, tackling one of the most complex and demanding aspects of medical device development: CyberSecurity.
Access to medical device markets not only implies compliance with cybersecurity regulatory requirements - it establishes it as prerequisite in all major regions (USA, EU, China, UK, and others).
Whether proactively preparing for upcoming challenges or striving to meet the requirements for regulatory submission, one aspect remains clear—when a device incorporates software or relies on connectivity, its architecture must account for cybersecurity risks and it is essential to demonstrate effective and efficient management of these risks to ensure the safety and reliability of the device and its potential impacts on users, integrators, and ultimately, patients on the face of cybersecurity threats.
In fact, the FDA has gone so far as to publish a Refuse to Accept policy focused on CyberSecurity in Medical Devices, and determining a number of requirements not entirely dissimilar from the European Medical Device Regulation.
Qity has suported numerous organisations in planning and preparing regulatory submissions with demonstrable success in Europe and USA. While enumerating and describing documents might sound trivial, adequately integrating CyberSecurity in the design and development life cycle of a medical device can be often challenging and cumbersome.
Either by helping plan out the Life Cycle of R&D, receiving training on CyberSecurity Regulatory Requirements, supporting operational market CyberSecurity challenges, or preparing for a successful submission, reach out via https://www.qity.be/about or info@qity.be and we'll be thrilled to lend a hand.
In Context: Environment and Product
By and large we'll focus on Medical Device CyberSecurity throughout this post. In practice this means most of the referred processes and documentation circle around risks associated directly with the Product Life Cycle in the context of optimising a successful submission.
There is a lot to say about the management of Information Security at an organisational level, and the value in implementing an Information Security Management System and a Privacy Management System, about Data Privacy, GDPR, and a myriad of other Security topics.
We'll hold on to those, though, for another occasion.
Regulatory Landscape
It is not uncommon for a newcomer into the industry to become overwhelmed with the number and diversity of standards and guidelines directly or indirectly related to cybersecurity for medical devices.
As a base set, it is not uncommon to consider the following as foundational to determine the requirements necessary to effectively plan for cybersecurity:
IEC 62304: Medical Device Software – Software Lifecycle Processes
Specifies lifecycle requirements for medical device software, emphasising safe design and development, risk management, and software maintenance processes.
IEC 82304: Health Software – General Requirements for Product Safety
Establishes general safety and reliability requirements for standalone health software, including lifecycle management and risk management principles.
IEC 62366: Application of Usability Engineering to Medical Devices
Provides guidance on applying usability engineering to medical devices to enhance safety by minimising user-related risks through user needs analysis and validation.
ISO 14971: Application of Risk Management to Medical Devices
Defines a comprehensive risk management process for identifying, assessing, and controlling risks associated with medical devices to ensure their safety throughout their lifecycle.
IEC 80001-1: Risk Management for IT-Networks Incorporating Medical Devices
Outlines the application of risk management principles for IT networks incorporating medical devices, focusing on safety, effectiveness, and security of interconnected systems.
U.S. FDA regulation that mandates design validation under real or simulated use conditions to ensure medical devices meet user needs and intended uses.
AAMI TIR57: Principles for Medical Device Security – Risk Management
Provides a framework for managing cybersecurity risks in medical devices, covering threat identification, risk controls, and continuous improvement of security measures.
The European Union's Medical Device Regulation emphasizes the integration of risk management and cybersecurity measures in the lifecycle of medical devices.
U.S. FDA guidelines recommending practices for addressing cybersecurity risks, including premarket and postmarket considerations for the development and maintenance of secure medical devices.
ANSI/AAMI SW96:2023 – Standard for Medical Device Security – Security Risk Management for Device Manufacturers
Offers requirements and guidance for addressing design, production, and post-production security risk management for medical devices within the risk management framework defined by ISO 14971.
Evidence, Records, and Artefacts
Despite the specificity of each regulatory body and the type of submission, effective cybersecurity planning generally targets the availability of a number of records and documents, adequately and consistently reviewed and updated in alignment with the Product Life Cycle.
The creation and maintenance of these evidences, records, and artefacts can be guided by specific CyberSecurity documents (such as CyberSecurity Plans, Design, Architecture, and Risk Register(s)), or integrated in the overarching planning and architecture documentation (such as Product Development Plan, System Architecture, and others), but demonstrating adequate identification, monitoring, and control of CyberSecurity risks is mandatory.
The implementation of a Secure Product Development Framework is a great starting point to demonstrate a structured approach to integrating security in product development, and significantly reduces the burden of generating submission documentation by timely and adequately guiding the secure product development and demonstrating Security by Design, as well as ensuring security through the maintenance of design controls throughout the Product Life Cycle, the availability of adequate policy and procedure for the development of secure software, and the record of integration of sound security practices throughout.
Regardless of approach, the execution of the planning should result in the availability of the following as a minimum set of required documentation for a successful submission:
Technical Documentation
- Threat Model Report
- CyberSecurity Architecture
- CyberSecurity Requirements and Specifications
- Secure Design Documentation
- Software Bill of Materials
Risk Management
- Risk Assessment Report
- Risk Register(s)
- Documentation of identified CyberSecurity risks and corresponding mitigation strategies
Testing and Vulnerability Management
- Security Testing Reports
- Evidence of Validation and Verification Activities
- Known Vulnerabilities and Anomalies
Post-Market and Operational Resilience
- Labelling and user guidelines on cybersecurity practices
- PMS plan, outlining continuous monitoring, incident response protocols, incident notification forms, and logs of communication with regulatory authorities
- Software maintenance plans and end-of-support timelines and decommissioning plans
The CyberSecurity Plan
An effective CyberSecurity Plan serves as the overarching strategy for addressing cybersecurity throughout the product lifecycle. It includes the identification of cybersecurity objectives, roles and responsibilities, and the approach for managing cybersecurity risks.
Qity CyberSecurity Plan Template
It outlines processes for secure development (and fully describes the SDPF whenever possible), vulnerability management, and incident response.
Tip: Confirm the structure of the CyberSecurity Plan is adequate prior to populating it with content. The structure of an effective Plan is a strong manner to ensure all facets of CyberSecurity are tackled timely and efficiently.
Tip: Confirm the structure of the CyberSecurity Plan is adequate prior to populating it with content. The structure of an effective Plan is a strong manner to ensure all facets of CyberSecurity are tackled timely and efficiently.
Technical Documentation
The Technical Documentation includes essential documents for both the product development and for a successful submission, and provide a comprehensive understanding of the cybersecurity measures. These documents are critical for demonstrating compliance with cybersecurity standards and integrating security into the design and architecture of the system, optimising the likelihood of a successful submission.
Threat Model Report
Using methodologies like STRIDE or MITRE ATT&CK to identify potential threats to the system, document the identification of threat actors, attack vectors, system vulnerabilities, and potential hazards.
The resulting report will be a valuable tool throughout the product development to identify, assess, quantify, and qualify risks, and to discuss the likelihood and impact (harm) of each identified threat.
Use Case Threat Model
Expertise in Attack Surface Analysis and Hazard Management is valuable when documenting the data flow diagrams included in a good Threat Model Report.
Tip: Design changes should trigger reviews of the Threat Model, ensuring that new threats, vectors, and vulnerabilities are timely and effectively identified, included, and managed.
CyberSecurity Architecture
When adequately used, provides a high-level overview of the system’s cybersecurity framework and includes details of secure communication paths, data encryption methods, access controls, data flows, interface descriptions, and security protocols. The architecture ensures that security measures are planned and integrated into the system from the design phase.
Tip: Whenever possible, cross-reference the content of the System Architecture with the CyberSecurity Architecture, to ensure all methods and interfaces are adequately protected. Ensuring adequate Security Architecture reviews as part of the life cycle is paramount to successfully design a secure device.
CyberSecurity Requirements and Specifications
The adequate outlining of all cybersecurity requirements, including those derived from applicable standards and regulatory guidance and detailing of specifications needed to achieve these requirements, covering elements like authentication, authorization, encryption, and secure data transfer, maximises the confidentiality, integrity, and availability of the device.
Tip: Ensure not only the regulatory and legal security clauses and controls are included in the requirements and specifications, but also items based on the specificity of the device and its intended use.
Secure Design Documentation
Security by Design is the fundamental principle behind the demonstration of a secure device. A robust SPDF (Secure Product Development Framework) or SSDLC (secure Software Development Lifecycle) will how the secure design principles have been incorporated into the product while providing sufficient traceability and historical context for secure design decisions.
It describes features like secure boot, partitioning, data integrity mechanisms, and protective measures against unauthorised access, and it provides guidance on how these contribute to an overall secure product.
An effective framework will include secure coding practices, security testing, risk management, and continuous monitoring, providing a framework that ensures the product is developed with security by design and maintains security throughout its lifecycle.
Tip: Integrating the security principles in the traditional Software Development Life Cycle (SDLC) and Configuration Management processes will facilitate the integration of security measures and methods and avoid duplication of instructions in the Quality Management System.
Software Bill of Materials
The SBOM lists all software components used in the system, including libraries, frameworks, and any third-party software. It is crucial for tracking vulnerabilities, as it helps identify affected components if a vulnerability is discovered in a specific software package.
When adequately used, the SBOM is one of the most useful Vulnerability assessment tools to demonstrate the effectiveness of threat assessment processes.
Tip: Integrating solutions that output CycloneDX or SPDX-compliant formats in Source Code Repositories will reduce the risk of errors and enable the real-time assessment of vulnerabilities identified in the identified Software Items, Units, Libraries, and other third-party software.
Tip: Integrating CVSS add-ons in Source Code Repositories, such as snyk, can effectively and automatically identify software threats and vulnerabilities.
Tip: Integrating solutions that output CycloneDX or SPDX-compliant formats in Source Code Repositories will reduce the risk of errors and enable the real-time assessment of vulnerabilities identified in the identified Software Items, Units, Libraries, and other third-party software.
Tip: Integrating CVSS add-ons in Source Code Repositories, such as snyk, can effectively and automatically identify software threats and vulnerabilities.
Risk Management
Effective management of Risks include methods and processes to identify, assess, and mitigate cybersecurity risks throughout the product development lifecycle, whilst ensuring that all risks are effectively managed and regulatory requirements for risk management are effectively met.
Risk Assessment Report
This report contains the latest evaluation of risks identified and associated controls and, when effective, includes a thorough analysis of each risk, addressing the probability, impact, and mitigation measures or controls for each cybersecurity threat, enabling effective risk management throughout the development cycle.
The Risk Assessment Report shall be mapped to the risk-related activities included in the Quality Management System, and shall be compliant with ISO 14971.
Tip: Ensure all Risks identified in both the Risk Profile and Threat Model Report are adequately managed and controlled prior to the preparation of the submission. Traceability between the CyberSecurity Requirements, Specifications, Design Controls, and Risks shall demonstrate that the risk profile of the device has been reduced to a satisfactory level, which varies depending on the classification of the device and associated bodies.
Documentation of identified CyberSecurity risks and corresponding mitigation strategies
The set of Risk Registers shall provide a clear and detailed list of all cybersecurity risks that have been identified throughout the PLC, including specific strategies and actions taken to mitigate each risk.
When effective, it provides evidence of proactive risk management, hazard identification, and provides regulatory authorities with assurance that potential issues (including potential harm) are being effectively controlled.
Testing and Vulnerability Management
Summary: The Testing and Vulnerability Management section focuses on documenting the testing activities performed to validate the security of the product. It also includes processes for managing vulnerabilities, ensuring that the product meets cybersecurity requirements.
Security Testing Reports
Device Security shall be periodically tested and the availability of reports and associated actions of the security-related testing activities, including penetration testing, fuzz testing, and vulnerability assessments provide evidence that the product has been tested against a broad range of potential security threats, and demonstrate that known vulnerabilities have been addressed.
Tip: Test often and provide a healthy mix of internal and external assessment on device-related security risks.
Evidence of Validation and Verification Activities
Both product and its design and/or development environment, such as non-product software, shall be effectively validated and verified according to its use and specification. Evidence of adequate V&V processes followed to validate and verify the security features of the product typically includes test cases, test results, and conclusions, demonstrating that the product and its environmental context meet cybersecurity requirements as outlined in the specifications.
Tip: Double check your tools, don't rely completely on automated output, and ensure the testing activities are aligned with the device risk profile.
Known Vulnerabilities and Anomalies
This document lists any known cybersecurity vulnerabilities and anomalies that have been managed to the minimum possible risk, but still pose a non-zero probability of occurrence. By explaining the steps and rationales behind the risk identification, assessment, and mitigation - and in particular by providing adequate rationale for residual risks - a manufacturer demonstrates both Security by Design and control over the CyberSecurity threats a device may be exposed to when in market.
Tip: Avoid extending the timeframe of your submission by actively managing risk to an acceptable level prior to undergoing regulatory.
Post-Market and Operational Resilience
A successful device on the market is demonstrably and continually effective after release. Demonstrating resilience against operational CyberSecurity threats is based on available guidelines for secure usage, incident response plans, and maintenance schedules to ensure the ongoing security and safety of the medical device.
Labelling and user guidelines on CyberSecurity practices
The availability of guidelines for configuring, operating, and maintaining the product securely, as well as information on what users should do to minimize security risks provides to the users or patients vital information on how to securely use the medical device.
Tip: By referring to an online available (and protected) location for CyberSecurity user or patient education, in addition to the provided guidelines, the device manufacturer can enrich the available information and continually improve the guidelines.
Post-Market Surveillance Plan
The PMS Plan shall include details of incident response protocols, the process for incident notification, breach notifications, and forms and logs for communication with regulatory authorities regarding CyberSecurity incidents.
It is equally important that sufficient detail is included to demonstrate the means used to monitor the security and safety of the medical device, when adequate and appropriate.
Tip: Depending on geographic area, the reporting of security incidents and data breaches has specific associated timelines and, failing to comply, exposes manufacturers to serious penalties and market consequences. Consider Operational CyberSecurity as part of the device design whenever adequate.
Software maintenance plans and end-of-support timelines and decommissioning plans
A successful submission will include a detailed schedule for software updates, bug fixes, and maintenance activities. It shall also define timelines for end-of-support and decommissioning of the product, ensuring that users/patients are aware of when support will end and what steps they need to take to secure their systems.
Tip: Be mindful of the updatability and patchability of the medical device early and critically plan for the update requirements considering the type of user/patient, expected skillset, and frequency.
The Qity Proposition
Our training and services offering includes:
- CyberSecurity device assessments and evaluations (CyberSecurity Technical Reviews, IEC 60601-4-5, IEC 62403, ISO 62443, MDCG, Pre-Market CyberSecurity, Post-Market CyberSecurity, and others)
- Tailored CyberSecurity Training and Education (ISO 13485, ISO 27001, IEC 62442, IEC 62304, IEC 82304, IEC 62366, IEC 80001, 21 CFR 820, AAMI TIR57, ANSI/AAMI SW96, and others)
- CyberSecurity Templates/Documentation Packages
- CyberSecurity/Quality Assurance Product Life Cycle support
- Vulnerability Assessments and Code Analysis
- Penetration and Fuzz Testing
- and more.
Find out more at https://www.qity.be/ and let us lend a hand!