Fda Releases Guidance On Cybersecurity In Medical Devices – Med Device Online

FDA Releases Guidance On Cybersecurity In Medical Devices – Med Device Online

By John Giantsidis, president, CyberActa, Inc.
The digital revolution that resulted in the Internet of Things (IoT), Internet of Medical Things (IoMT), Software as a Medical Device (SaMD), and connected devices permeating the healthcare environment, both in the hospital and at home, comes with the possibility of cyberattacks and intrusions against a compromised connected medical device and the network to which such a device is connected.
Healthcare has been proven to be a valuable target for cyber threat actors (also known as hackers) and medical devices are increasingly the targets of malicious cyberattacks, which result not only in data breaches but also increased healthcare delivery costs, and they can ultimately affect patient health outcomes.1
The consequences of these attacks, and the corresponding safety and fiscal impacts that can result from them, have prompted many governments agencies and other actors (industry associations, technical societies, standards organizations, research institutions, policy groups, and nongovernmental organizations) to undertake measures to protect themselves and their citizens. In the EU, both the MDR and IVDR requirements mandate consideration of medical device cybersecurity, and the Medical Device Coordination Group (MDCG) in its guidance directs manufacturers on how to fulfil all the relevant essential requirements of Annex I to the MDR and IVDR with regard to cybersecurity.2 In Australia, the Therapeutics Goods Administration is treating medical device cybersecurity as part of the Essential Principles and the TGA requires that the cybersecurity “Essential Principles are met by applying accepted best-practice regarding quality management systems and risk management frameworks, which is typically via application of state of the art standards."3
Since 2005, the FDA has been striving to enhance medical device cybersecurity, and the latest FDA effort is a draft guidance that expects security throughout the total product life cycle (TPLC). Another effort is bipartisan congressional support of the Protecting and Transforming Cyber Health Care Act of 2022 (PATCH Act of 2022),4 which, if passed, would revise the existing Federal Food, Drug, and Cosmetic Act. However, let’s revisit the PATCH Act if/when it gets passed.
The FDA’s draft guidance on medical device cybersecurity provides insight on how the agency is going to apply the existing regulatory requirements. But how does one get ready to meet FDA’s medical device cybersecurity expectations?
First, it is important to understand that the scope of FDA’s guidance is exceptionally broad and covers devices that contain software (including firmware) or programmable logic, as well as SaaMD, and would be expected for:
The FDA guidance establishes six broad expectations and introduces the newly minted concept of a Secure Product Development Framework (SPDF), which encompasses all aspects of a product’s life cycle, including development, release, support, and decommission to satisfy Quality System Regulations (QSR) in 21 CFR Part 820:
The FDA guidance sets the nexus between a reasonable assurance of safety and effectiveness for devices with cybersecurity risks and the expectation that such cybersecurity risks are governed by the QSR. The FDA borrows from NIST and introduces a Secure Product Development Framework (SPDF) concept, akin to NIST’s Secure Software Development Framework5 and suggests that such integration with product and software development, risk management, and the quality system at large can satisfy cybersecurity QSR. The following principles may be considered the fundamental practices that the FDA had in mind regarding SPDF:
The FDA guidance sets the expectation that devices must meet the security objectives of authenticity, integrity, authorization, availability, confidentiality, and secure and timely updatability and patchability. The extent to which security requirements are needed to meet these objectives would depend on:
For example, a device would be deemed that it appropriately accounts for authenticity when it evaluates and ensures authenticity for:
The expectations for demonstrating Integrity (Code, Data or Execution) provide an illustrative example:
The FDA guidance concludes that transparency is critical to ensure safe and effective use and integration of devices and systems and such transparency can be conveyed via both device labels and vulnerability management plans.
For devices with cybersecurity risks, FDA also believes that informing users of security information through labeling may be an important part of QSR design controls to help mitigate cybersecurity risks and help ensure the continued safety and effectiveness of the device. A word of caution, however: Any risks transferred to the user should be detailed and considered for inclusion as tasks during usability testing (e.g., human factors testing) to ensure that the user has the capability to take appropriate actions to manage those risks. The FDA outlines the following labeling to communicate security information to users:
The FDA guidance further expects that manufacturers institute a formal plan for how they will identify and communicate vulnerabilities that are identified after releasing the device to users. This plan is to be in unison with risk management processes under 21 CFR 820.30(g) and corrective and preventive action processes in accordance with 21 CFR 820.100.
“Security risk management should be part of a manufacturer’s quality system.” That is FDA’s expectation and further elucidates that the process for performing security risk management is a distinct process from performing safety risk management as described in ISO 14971:2019. The FDA guidance sets the expectation that the security risk assessment is to focus on exploitability, or the ability to exploit vulnerabilities present within a device and/or system, and the FDA recommends that manufacturers establish a security risk management process that encompasses, at a minimum, design controls, validation of production processes, and corrective and preventive actions to ensure both safety and security risks are adequately addressed. The following security risk management practices are highlighted by the FDA guidance:
FDA considers threat modeling “foundational” and an integral part of security risk management. Threat modeling documentation shall ultimately demonstrate how the risks assessed and controls implemented for the system address questions of safety and effectiveness. The FDA guidance sets the following expectations about threat modeling:
The FDA is clear that to demonstrate compliance with quality system design controls and to support supply chain risk management processes, all software, including that developed by the device manufacturer (“proprietary software”) and obtained from third parties, should be assessed for cybersecurity risk and that risk should be addressed. Moreover, manufacturers must put in place processes and controls to ensure that their suppliers conform to the manufacturer’s cybersecurity requirements. That means that cybersecurity would have to be extended to supplier management practices and documented in the Device Master Record as required by 21 CFR 820.181.
The FDA guidance places great emphasis on the process and issuance of a Software Bill of Materials (SBOM) and considers the changes in the SBOM as part of the Design History File (21 CFR 820.30) and Device Master Record (21 820.181). Any industry-accepted formats of SBOMs can be used, provided that the following information is included:
FDA outlines that manufacturers are responsible for identifying cybersecurity risks in their devices and the systems in which they expect those devices to operate and implementing the appropriate controls to mitigate those risks. These risks may include those introduced by device reliance on hospital networks or cloud infrastructures and, as such, the FDA draft guidance requires that security architecture information demonstrates that the risks considered during the risk management process are adequately controlled, which, in turn, supports the demonstration of the safety and effectiveness of the medical device system.
The FDA guidance relies on the existing regulatory framework of 21 CFR 820.30(b), (c), and (d) for the expectation that design processes, design requirements, and acceptance criteria for the security architecture of the device holistically address the cybersecurity considerations for the device and the system in which the device operates. An analysis of the entire system is expected, to understand the full environment and context in which the device is expected to operate, and the security architecture is to include a consideration of system-level risks, including but not limited to risks related to the supply chain (e.g., to ensure the device remains free of malware or vulnerabilities inherited from upstream dependencies such as third-party software, among others), design, production, and deployment (i.e., into a connected/networked environment).
In addition to the design control requirements (i.e., 21 CFR 820.30(b), 21 CFR 820.30(c), 21 CFR 820.30(d), and 21 CFR 820.30(g)), FDA recommends, under 21 CFR 820.100, manufacturers develop and maintain security architecture view documentation as part of the process for the design, development, and maintenance of the system. If corrective and preventive actions are identified, these views can be used to help identify impacted functionality and solutions that address the risks.
The FDA recommends providing, at minimum, the following types of security architecture views (both diagrams and explanatory text) in premarket submissions:
Each of these security architecture views are to:
The FDA draft guidance, under the existing QSR, declares that verification and validation activities shall include sufficient testing performed on the cybersecurity of the system through which the manufacturer verifies and validates their inputs and outputs. The FDA further summarizes that cybersecurity controls require testing beyond standard software verification and validation activities to demonstrate the effectiveness of the controls in a proper security context to therefore demonstrate that the device has a reasonable assurance of safety and effectiveness. The following cybersecurity testing and corresponding objective evidence would be considered the minimum that may support a premarket submission:
The FDA’s medical device cybersecurity guidance would require that manufacturers’ devices with software, firmware, or programmable logic, as well as software as a medical device (SaMD), minimize the cybersecurity risks associated with the design, safety, and use of those devices. Manufacturers would have to generate and maintain evidence regarding the quality management systems and risk management frameworks used to manage medical device cybersecurity to demonstrate compliance. Overall, the FDA understands that the cybersecurity threat landscape is rapidly evolving and requires constant monitoring and appropriate corrective and preventive action from medical device manufacturers, alongside timely communication to medical device users to establish their awareness of cybersecurity threats. Interested stakeholders can submit comments on this draft guidance for FDA’s consideration until July 7, 2022, to Docket No. FDA-2021-D-1158 available at https://www.regulations.gov/docket/FDA-2021-D-1158.
About The Author:
John Giantsidis is the president of CyberActa, Inc, a boutique consultancy empowering medical device, digital health, and pharmaceutical companies in their cybersecurity, privacy, data integrity, risk, regulatory compliance, and commercialization endeavors. He is the vice chair of the Florida Bar’s Committee on Technology and a Cyber Aux with the U.S. Marine Corps. He holds a Bachelor of Science degree from Clark University, a Juris Doctor from the University of New Hampshire, and a Master of Engineering in cybersecurity policy and compliance from The George Washington University. He can be reached at john.giantsidis@cyberacta.com.
Get the latest articles from Med Device Online delivered to your inbox.


Leave a Comment

Leave a Reply

Your email address will not be published.

Cyber Security Today for Wednesday Sept 7, 2022 – TikTok exposes billions of records, number one attack vector and more… – IT World Canada

(ISC)² Opens Global Enrollment for '1 Million Certified in Cybersecurity' Initiative – DARKReading

Cybersecurity Resources – Office of Educational Technology – Department of Education (.gov)

Cybersecurity hiring remains red-hot—the industry to surpass $400 billion market size by 2027 – Fortune