April 21, Division of Dockets Management (HFA-305) Food and Drug Administration 5630 Fishers Lane, Room 1061 Rockville, MD 20852

Transcription

1 701 Pennsylvania Avenue, NW Suite 800 Washington, D.C Tel: Fax: Division of Dockets Management (HFA-305) Food and Drug Administration 5630 Fishers Lane, Room 1061 Rockville, MD Re: Docket No. FDA-2015-D-5105: Postmarket Management of Cybersecurity in Medical Devices; Draft Guidance for Industry and Food and Drug Administration Staff; Availability To Whom It May Concern: The Advanced Medical Technology Association ( AdvaMed ) appreciates the opportunity to provide comment on the Food and Drug Administration s ( FDA or Agency ) Draft Guidance for Industry and Food and Drug Administration Staff: Postmarket Management of Cybersecurity in Medical Devices ( Draft Guidance ). 1 AdvaMed represents manufacturers of medical devices, diagnostic products, and health information systems that are transforming health care through earlier disease detection, less invasive procedures, and more effective treatment. Our members range from the smallest to the largest medical technology innovators and companies. Patient safety is the number one priority of the medical technology industry and we appreciate the Agency s interest in providing guidance regarding the postmarket management of medical device cybersecurity. Furthermore, we applaud FDA s leadership with respect to medical device cybersecurity, including its work to organize the January 20-21, 2016 Public Workshop. We are encouraged to see the significant strides FDA and the broader healthcare community have made in moving medical device cybersecurity forward. We strongly encourage FDA to align postmarket management of cybersecurity closely with the Quality System Regulation, as we believe is the Agency s intent. To that end, FDA should avoid inadvertently creating parallel documentation pathways or processes that could lead to confusion or redundancy. We also encourage FDA to better align the Draft Guidance with the Agency s guidance, Content of Premarket Submissions for Management of Cybersecurity in Medical Devices ( Premarket Cybersecurity Guidance ). 2 Although we realize this presents some 1 Postmarket Management of Cybersecurity in Medical Devices; Draft Guidance for Industry and Food and Drug Administration Staff; Availability (Jan. 22, 2016), available at df. 2 Available at df. Bringing innovation to patient care worldwide

2 Docket No. FDA-2015-D-5105 Page 2 of 18 administrative challenges, we believe the Agency should combine both guidances into a single, holistic guidance on medical device cybersecurity. Moreover, because the Agency is proceeding through guidance, it should be made clear in the document that its recommendations are not prescriptive and should not form the basis of a citable event during an inspection. This is particularly true given the number of technical guidances that FDA has released, which require the Agency to take a flexible approach for cybersecurity management. Should FDA intend for the recommendations described in the Draft Guidance to be prescriptive, the Agency should proceed through notice and comment rulemaking. Below we provide three general comments concerning the Draft Guidance. More specific comments can be found in the attached document. 1. Eliminate Essential Clinical Performance We recommend FDA eliminate the concept of essential clinical performance from the Draft Guidance and instead focus on maintaining device functionality and safety, as described in the Premarket Cybersecurity Guidance. 3 We do not believe FDA has previously used this term, and we do not believe it is typically used in relation to firmware and/or software. 4 Should FDA maintain the concept of essential clinical performance, it should revise the definition so that it is consistent with IEC (which requires compliance with ISO 14971) to: Essential performance means performance necessary to achieve freedom from unacceptable risk of a clinical function, other than that related to basic safety, where a loss or degradation beyond the limits specified by the manufacturer results in unacceptable risk. Compromise of the essential performance can produce a hazardous situation that results in harm and/or may require intervention to prevent harm. We also note that while essential clinical performance may be easily defined in a simple case, such as a medical device with one intended use and minimal connectivity, it does not translate well for complex situations and environments. For example, an in vitro diagnostic analyzer may be a class I instrument, but may run 300 or 400 different assays with different 3 See, e.g., Premarket Cybersecurity Guidance at p. 2 ( Effective cybersecurity management is intended to reduce the risk to patients by decreasing the likelihood that device functionality is intentionally or unintentionally compromised by inadequate considerations to cybersecurity. ). 4 For example, FDA s Guidance, Content of Premarket Submissions for Software Contained in Medical Devices, does not contain this term. Available at 93.pdf.

3 Docket No. FDA-2015-D-5105 Page 3 of 18 intended uses. Defining essential clinical performance in that situation would be extremely difficult and could lead to unintended consequences (such as reporting all vulnerabilities regardless of risk). 2. More Information is Needed About ISAOs We agree with FDA that the sharing of threat information is likely to benefit patient safety. However, it would be helpful if the Draft Guidance provided more information concerning FDA s vision of the benefits associated with industry s participation in an Information Sharing and Analysis Organization ( ISAO ). Additional information would also be helpful with respect to how FDA intends to: (1) Participate in an ISAO, (2) determine that a particular ISAO is acceptable for participation by a medical device manufacturer, and (3) the role of the ISAO and its responsibilities. We also recommend the Agency not suggest that an ISAO is the only type of organization that can accomplish the stated goals. Although we acknowledge that certain protections are granted solely to ISAOs and cannot be conveyed by FDA to other similar organizations, there may be other institutions that could provide comparable benefits. 3. ISO and the NIST Cybersecurity Framework We agree with FDA s reference to and use of the National Institute for Standards and Technology s ( NIST ) Framework for Improving Critical Infrastructure Cybersecurity ( NIST Cybersecurity Framework ) 5 and strongly encourage FDA to continue to rely on consensus standards as the foundation for both pre- and postmarket cybersecurity policies. However, we believe FDA should place greater emphasis in the Draft Guidance on ANSI/AAMI/ISO 14971:2007/(R)2010, Medical devices Application of risk management to medical devices. The NIST Cybersecurity Framework, unlike ISO 14971, does not account for sector-specific limitations and requirements, including those related to medical device risk management. 6 In this regard, it may also be beneficial for the Agency to review and consider a draft of the Technical Information Report (TIR) under development by the Association for the Advancement of Medical Instrumentation ( AAMI ). See TIR-57 Principles for medical device security Risk management. * * * 5 Available at 6 See, e.g., GAO Report to Congressional Committees, Critical Infrastructure Protection, Measures Needed to Assess Agencies Promotion of the Cybersecurity Framework (Dec., 2015), available at

4 Docket No. FDA-2015-D-5105 Page 4 of 18 AdvaMed would like to thank the FDA for its consideration of these comments. Please do not hesitate to contact me at or zrothstein@advamed.org if you have any questions. Respectfully submitted, /s/ Zachary A. Rothstein, J.D. Associate Vice President Technology and Regulatory Affairs Attachment

5 Date: Document Title: Submitters Name: Company: Postmarket Management of Cybersecurity; Draft Guidance for Industry and Food and Drug Administration Staff Zachary A. Rothstein, JD Advanced Medical Technology Association (AdvaMed) 1 General We recommend FDA align the terminology used in the Draft Guidance with ISO 14971, to the extent practical. For example, risk mitigations should be changed throughout the document to risk control measures. Furthermore, the following ISO definitions should be incorporated into the Draft Guidance: Changes in terminology from those used by ISO will confuse stakeholders. Furthermore, the Agency s Premarket Cybersecurity Guidance relies on ISO terms. Harm: Physical injury or damage to the health of people, or damage to property or the environment. Hazard: Potential source of harm. Hazardous Situation: Circumstance in which people, property, or the environment are exposed to one or more hazard(s). Residual Risk: Risk remaining after risk control measures have been taken. Risk: Combination of the probability of occurrence of harm and the severity of that harm. Risk Control: Process in which decisions are made and measures implemented by which risks are reduced to, or maintained within, specified levels. We also recommend FDA define cybersecurity as it applies in the

6 Draft Guidance. On its own, the term cybersecurity is broad and may be more encompassing than what FDA intends for purposes of the Draft Guidance. 2 General We recommend FDA discuss the concept of benefit/risk in greater detail, particularly as it relates to cybersecurity threats. FDA should also provide specific guidance on the evaluation of risk severity and likelihood in the context of cyber threats. 3 General FDA should clarify how vulnerabilities reported through a vulnerability disclosure process should or should not also be handled as complaints, specifically as compared to what is defined in 21 C.F.R General We recommend adding a glossary of key terms and a list of acronyms used in the Draft Guidance. Benefit/risk is not discussed in the Draft Guidance. Nevertheless, the concept is critical within the context of ISO and for FDA. The traditional definition of likelihood does not scale well when applied to cyber threats. A complaint is defined in 21 C.F.R as any written, electronic, or oral communication that alleges deficiencies related to the identity, quality, durability, reliability, safety, effectiveness, or performance of a device after it is released for distribution. The Draft Guidance does not seem to address this point directly. It only states that manufacturers should track cybersecurity signals from received complaints; however, it does not explain whether vulnerabilities reported through a coordinated disclosure process should be considered complaints. This will help clarify the Draft Guidance s recommendations and support future discussions Delete: and exploits. This language suggests that exploits should also be systematically evaluated, although we believe this is not feasible, nor is this concept further defined by the Draft Guidance Revise to: For a small subset of cybersecurity vulnerabilities and exploits that may compromise the essential clinical performance of a device and present a reasonable probability of serious adverse health consequences have resulted in serious adverse events or death, the FDA would require medical device manufacturers to notify the Agency. Section VII.B of the Draft Guidance describes response actions applicable to an uncontrolled risk (i.e., unacceptable residual risk) scenario Add to footnote one: or This addition will clarify FDA s expectations. 6

7 Add: healthcare facilities. Healthcare facilities are mentioned on line Define cyber hygiene in Section IV of the Draft Guidance. This term is not defined but is used throughout the Draft Guidance Add at the end of the sentence: and/or operators. Furthermore, the Draft Guidance should explain how manufacturers should handle postmarket reporting obligations for devices that were never intended to be on a network, but were connected by a third-party Revise to: To further aid manufacturers in developing their cybersecurity program managing their cybersecurity risk, the Agency encourages the use and adoption of manufacturers to review the voluntary Framework for Improving Critical Infrastructure Cybersecurity by the National Institute of Standards and Technology (NIST) with collective input from other government agencies and the private sector. Cybersecurity risks may also affect the device s operator. See also Comment to line 267. In addition, legacy devices may be added to networks by owners and/or integrators. The NIST Framework complements, but does not replace, an organization s risk management process and cybersecurity program. In addition, the NIST Framework is not directly applicable to the management of risks (including cybersecurity risks) for medical devices as described in standards such as ISO For example, the NIST Framework states: The Framework complements, and does not replace, an organization s risk management process and cybersecurity program Revise to:... is the secure sharing of cyber risk information.... This change provides alignment with the protections associated with an ISAO and other data sharing organizations Add to the end of the sentence: or as otherwise provided. This change allows for flexibility beyond the Critical Infrastructure Information Act of Add: EO mandates that the ISAO preserves business confidentiality, [and] safeguards the information being shared FDA should consider other protections to the extent the Agency is lawfully able to do so. This statement adds clarity for the reader. Industry supports FDA s use of incentives, consistent with other Critical Infrastructure sectors, and encourages the Agency to consider whether additional incentives would encourage further participation Replace Section VIII with Section VII We believe this is a typographical error We recommend FDA further clarify the scope and the identified This section should be expanded. 7

8 potential risks of the Draft Guidance by including information on the following: Identify mobile medical applications as being within the scope of this Draft Guidance, and clarify whether this guidance only applies to off-the-shelf software; Clarify whether the Draft Guidance applies to legacy devices currently in use and what FDA s expectations are with respect to legacy devices; Clarify whether the guidance will apply to devices cleared or approved before release of the final version; Clarify whether low risk devices that do not contain communication interfaces are within scope of the Draft Guidance; and Provide additional information concerning how this guidance impacts interoperable medical devices Revise to: A. Compensating Risk Controls Measures and make this change throughout the Draft Guidance (i.e., replace all instances of compensating controls with compensating risk control measures ) Revise to: A cybersecurity compensating risk control measure is a safeguard or countermeasure, external to the device, employed by a user in lieu of, or in the absence of sufficient risk controls measures that were designed in by a device manufacturer Revise to: Controlled risk is present when there is sufficiently low (acceptable) residual risk that the device s essential clinical performance could be compromised by a cybersecurity of harm from degradation of harm from degradation of the device s basic Consistent with our first comment above, this change clarifies that the control is applied to reduce risk. The additional word measures aligns the term with ISO These changes align the terminology with ISO These revisions more accurately reflect the application of risk management as described in ISO because a risk management professional must consider the impact of harm resulting from degradation of essential performance. 8

9 safety or essential performance due to an exploitable vulnerability. We also add the concept, basic safety, because it is possible that a cybersecurity exploit could disable safeguards that prevent a user from accessing moving parts which could cause harm. In this case, moving parts are incidental to the operation of the medical device. (Note, the first use of basic safety should include a footnote to IEC : A1:2012 (Edition 3.1)) Add suppliers of hardware and software components. These entities are mentioned on line Delete: Signals may be identified within the HPH Sector. This statement does not seem necessary ; Entire document Revise to (with a footnote z to IEC : A1:2012 (Edition 3.1)): E. Essential Clinical Performance Essential clinical performance means performance that is necessary to achieve freedom from unacceptable clinical risk of a clinical function (i.e., intended use), other than that related to basic safety, where a loss or degradation beyond the limits specified as defined by the manufacturer results in unacceptable risk. z Compromise of the essential clinical performance can produce a hazardous situation that results in harm and/or may require intervention to prevent harm. The concept essential clinical performance has been developed for the purpose of this guidance. We recommend FDA eliminate the concept of essential clinical performance from the Draft Guidance and instead focus on maintaining device functionality and safety, as described in the Premarket Cybersecurity Guidance. We do not believe FDA has previously used this term, and we do not believe it is typically used in relation to firmware and/or software. Corresponding changes should be made throughout the Draft Guidance Delete the and in and/or. We do not believe the and is appropriate if the harm has already occurred Replace accidently with unintentionally. FDA s guidance concerning Cybersecurity for Networked 9

10 Medical Devices Containing OTS Software uses the term unintentionally throughout the document Revise to: Remediation is any action(s) taken to reduce an identified risk to the medical device s essential Revise to: Remediation actions may include complete solutions risk control measures to completely remove a cybersecurity vulnerability from a medical device (sometimes known as an official fix) or, risk control measures to reduce the residual risk associated with a vulnerability, or compensating risk controls measures that adequately mitigate the risk (e.g., notification to customer base and user community identifying a temporary fix, or work-around) Add before the sentence beginning with, An example : Remediation does not always require that a vulnerability be fixed. This language is more precise. The proposed changes align the narrative with risk management principles elaborated in ISO This sentence clarifies that a range of options are available to address a known vulnerability We recommend deleting the definition of threat modeling. Threat modeling is common and a well-understood methodology for cybersecurity evaluation. The definition FDA has referenced is not widely accepted and/or used, and therefore does not benefit the reader Replace organization with manufacturer. As used in this context, the term organization is unclear Revise to: Uncontrolled risk is present when there is unacceptable residual risk that the device s essential clinical performance could be compromised due to insufficient compensating controls and risk mitigations. of harm from degradation of the device s basic safety or essential performance due to an exploitable vulnerability. These revisions more accurately reflect the application of risk management as described in ISO since a risk management professional must consider the impact of harm resulting from degradation of essential performance ; 269 Add users of the medical device. Many devices are used outside of the clinical setting. In these cases, the user may be the patient, clinician or a third party Revise to: Failure to maintain cybersecurity can result in compromised device functionality, compromised confidentiality, loss of medical data (medical or personal) availability or integrity, or exposure of other connected devices or networks to security This edit clarifies the distinction between the risk of medical data being unavailable or incorrect (affecting treatment) and the risk of confidential data being accessed by unauthorized persons. 10

11 threats Add at the end of the sentence: and/or operator injury. A vulnerability may also affect the device s operator Revise to: It is FDA s priority that effective cybersecurity risk management is intended to reduces the risks to patients and/or operators by decreasing the likelihood that device functionality is intentionally or unintentionally compromised by inadequate cybersecurity. Other stakeholders have additional desired outcomes for cybersecurity, in addition to device function and patient safety Revise to: obsolescence/retirement. This change acknowledges that these terms are defined interchangeably and/or differently by different manufacturers Remove the second sentence (line 285, beginning with Manufacturers ) through line Revise to:... software verification, validation and risk analysis.... An introductory sentence and a reference to the Premarket Cybersecurity Guidance document is sufficient. The design inputs should be verified Revise to:... and may impact patient and/or operator safety. A vulnerability may also affect the device s operator Add: Maintain a detailed Bill of Material list for security vulnerable third party components to improve monitoring products for new vulnerabilities Revise to:... performance to support the development of risk control measures that protect We recommend FDA define the term, coordinated vulnerability disclosure, in the Draft Guidance consistent with ISO/IEC 29147: Revise to: Deploying mitigations that address cybersecurity risk early, with the goal of deployment and prior to exploitation. The use of tools to discover and track vulnerabilities in third party libraries and components allows an organization to quickly discover products that are impacted by a newly discovered vulnerability in a common component. Defining essential performance is a process activity, it does not impact developing a mitigation to a risk, but does help identifying what to mitigate. This change would provide additional clarification for users of the Draft Guidance that may not be aware of the process and/or standard. This change would acknowledge that not all threats can be mitigated prior to exploitation We recommend including reference to US-CERT and other Vulnerabilities reported to the US-CERT may be a useful 11

12 independent individuals as a potential source. means to receive information. Additionally, non-security researchers may be a vulnerability reporting source We recommend moving the text, For example... from line 337 to line 336, and placing the two related bullet points on lines under the text on line 336. The referenced bullet points (line ) provide examples of vulnerabilities. The bullet points are not directly related to threat sources. We also recommend adding an additional bullet point under line 337: It is recommended that manufacturers participate in an ISAO to obtain current information related to critical vulnerabilities and potential threats Revise to: It is recommended as part of a manufacturer s cybersecurity risk management program that the manufacturer incorporates consider elements consistent with of the NIST Framework for Improving Critical Infrastructure Cybersecurity (i.e., Identify, Protect, Detect, Respond, and Recover) Replace the sentence with: Periodic risk assessments (including reassessment of unmitigated vulnerabilities) will help prevent impact on the essential performance from vulnerabilities that emerge in the future. We agree that the medical device community would benefit from the creation of an information exchange mechanism. In this regard, a cybersecurity ISAO can play a critical role in sharing information related to threats. It is not realistic for individual manufacturers to track certain types of adversarial threat sources (e.g., Nation-State). See Annex D, NIST SP rev1. The NIST Cybersecurity Framework, unlike ISO 14971, does not account for sector-specific limitations and requirements, including those related to medical device risk management. We believe this language is more clear than currently drafted Revise to:... as part of cybersecurity risk management... We believe it is too common and easy to confuse safety risk and cyber risk by using risk without an appropriate qualifier, particularly in this Draft Guidance where both are discussed Further elaborate on what is meant by mapping requirements. This phrase is unclear as written Delete insulin. This example should be extended to include all types of infusion pumps FDA should reference ISO as means to objectively assess ISO is an international standard used by companies 12

13 cybersecurity risk for their devices. to assess their product s risk Further guidance is needed regarding how a manufacturer should conduct a probability assessment, particularly when the severity of the potential harm is to a degree where assuming a probability of 1 means that the potential harm is unacceptable. FDA should provide additional clarity or remove this reference FDA should explain in greater detail how vulnerabilities can be numerically quantified. We recommend FDA remove reference to the Common Vulnerability Scoring System ( CVSS ) and clarify that any approach to vulnerability scoring is an input to existing risk management processes Revise to: For risks that remain uncontrolled, additional remediation risk control measures or compensating risk control measures should be implemented. If the required risk reduction is not practicable, then a risk/benefit analysis of the residual risk should be performed (ref. subclause 6.5, ISO 14971). As drafted, it is unclear how a manufacturer should implement this sentence. Although the CVSS is one scoring system, is not the industry standard for such assessments. There are risks the device manufacturer may not be able to remediate (e.g., a hospital that has malware on its network that modifies packets in transit which causes denial of service to the medical device). Moreover, the existing text does not provide for a risk/benefit analysis as outlined in ISO Delete typically. FDA defined Cybersecurity Routine Updates and Patches in Section IV, although it applied the qualifier generally when discussing reporting requirements and deferred a detailed discussion to Section VII. We believe Section VII is also ambiguous regarding when reporting is required Revise to: Conduct appropriate software verification under 21 CFR (g)(f) and software validation under 21 CFR (g)... We recommend adding software verification, (f), because not all changes require validation Delete: and implement. As defined on line 160, this type of control is employed by a user. Line 493 and the related bullet points specify actions to be taken by a manufacturer Revise to: Communicate compensating risk control measures toprovide users with.... This bullet point is about compensating risk control measures, so the term should be used here. 13

14 Furthermore, we recommend FDA elaborate on the extent to which a manufacturer must ensure these communications reach all users, particularly for home-use products Delete this sentence. We do not believe there is a need to repeat the definition in this section Delete the words typically and generally. These changes eliminate ambiguity. If left as currently drafted, the Agency provides no guidance regarding (1) when changes fall outside of the typical range and (2) when updates and patches are required to be reported We recommend clarifying the impact to devices that FDA views as systems, particularly when the vulnerability may exist for a class I or II device within that system. Furthermore, the Agency should clarify that reporting a vulnerability for a class I or II device within a system that FDA treats as a component of a class III system is only necessary when a change is made to the device that otherwise would trigger inclusion in an annual report We recommend FDA add examples of IVD vulnerabilities associated with controlled risk and their management. Periodic reporting requirements would be manageable when considered in the context of an individual device, but FDA s recent approach to treating devices as a system could lead to unnecessary reporting. For example, an IVD analyzer may run hundreds of assays. By itself, it may be a class I device. However, it may be submitted as a platform to a class III assay. A report in such a case should only be required if (1) a change is made to the device; and (2) it impacts critical functionality of the class III assay. While the current examples are helpful, it is important for IVD manufacturers to understand FDA s policies in the IVD context. We recommend adding at least one example Delete may and replace with does. This change provides clarity that reporting under Part 806 would not be required We recommend FDA either delete this example or clarify its intent. We believe, as written, the example may be interpreted to mean that the device manufacturer is responsible for any malware infection of their device regardless of its origin. FDA should clarify that all stakeholders in the healthcare system play a role in medical device cybersecurity. Clarifying this example will ensure that all members of the healthcare community play a role in medical device cybersecurity. 14

15 Revise to: While a remediation an official fix may not be feasible or immediately practicable, manufacturers should identify and implement risk control measures and communicate compensating risk controls measures, such as a work-around or temporary fix, to adequately mitigate the risk; We recommend that FDA clarify when reports are required under Part 803 rather than Part We do not believe 30 days is an achievable timeline to bring the residual risk to an acceptable level. The time required to properly address a vulnerability greatly depends on the specific issue and its complexity. Moreover, for public health reasons we do not believe a manufacturer should be rushed through the process of remediating a vulnerability. While we do not believe 30 days is an achievable timeframe, we would welcome the opportunity to continue to work with the Agency to develop a well-rounded approach that allows for flexibility based on the type and severity of risk. We believe the Draft Guidance should use terms defined within the document. There is general confusion regarding when a report under Parts 803 or 1004 removes the need for a report under Part 806. Manufacturers are often uncertain as to whether a Part 803 report is sufficient. In light of the unique nature of cybersecurity remediations with an uncontrolled risk to essential performance, more direct guidance on which reporting pathway to use would be helpful. We believe in many cases it will not be possible to fully analyze an attack or vulnerability and, within 30 days, perform appropriate verification and validation (as required by FDA regulation) before implementing a solution. Even in the best of circumstances, gathering and confirming all of the available information, reproducing the vulnerability, performing appropriate risk assessments, determining and testing appropriate fixes or compensating controls, and communicating to customers would be extremely challenging when dealing with complex medical devices (e.g., large interoperable systems). Moreover, rolling out a mitigation may require additional time depending on the size of the installed base and whether a remote connection is in place for the rollout or whether a service technician has to be on-site to manually install a patch or configure the device FDA should further define implements. It is unclear what FDA expects Revise to:... and notifies users and/or customers, and.... Manufacturers may communicate with device customers, who would not necessarily be considered users. This change should be considered throughout the Draft 15

16 Guidance Number 3 should be optional but preferred. As long as numbers one and two are followed, number three should be optional and not required for exemptions to be considered unless significant value can be demonstrated by participation in an ISAO ; We recommend deleting lines It appears this information is covered by lines We recommend deleting this bullet point. Although prior references include statements maintaining that cybersecurity fixes do not generally require FDA approval prior to implementation, they have not been definitive. Inclusion of this bullet point does not resolve the ambiguity, and none of the examples address when prior FDA approval would be expected. FDA should delete this point or provide information concerning when prior FDA approval/clearance is expected. For example, the 2005 Guidance on Cybersecurity for Networked Medical Devices Containing Off-the Shelf-Software stated that it is not likely that a software patch will require a new 510(k), and only would be expected if it resulted in a new or changed indication for use or could significantly affect the safety or effectiveness of a device, and that for a PMA product a premarket submission is not necessary unless the change affected indications for use or safety and effectiveness. The current statement is more ambiguous. If there are specific circumstances or factors with regard to an uncontrolled risk that would necessitate a premarket submission, FDA should state these items in the guidance. Alternatively, FDA should restate the conditions set out in the 2005 guidance to be clear that premarket submissions related to security remediations will be rare Revise to: The customer base and user community should be provided with relevant information on recommended compensating These changes are consistent with defined terminology used in the Draft Guidance. 16

17 controls, remediations, work-arounds, temporary fixes and residual cybersecurity risks so that they can take appropriate steps to mitigate the risk and make informed decisions regarding device use Revise to:... newly acquired information concerning cybersecurity vulnerabilities, and device changes and new compensating controls The statement, Reference to other submissions/devices that were modified in response to this same vulnerability, infers that vulnerable devices, including Class I and Class II devices, must be included in PMA (Class III) annual reporting. We strongly recommend that, to the extent annual reporting of vulnerabilities is required, it be limited to Class III devices. Class II and Class I devices should not be subject to annual reporting The NIST Framework is not industry-specific and does not provide adequate detail to manage medical device cybersecurity risks. It would be helpful if the Agency could also address the relationship of cybersecurity risks to the management of risks as described in ISO Revise to: FDA recommends that manufacturers conduct cybersecurity risk analyses that include threat modeling for each of their devices and to update those analyses over time. Risk analyses and threat modeling should aim to triage vulnerabilities for timely remediation. Threat modeling is a one procedure for optimizing Network/Application/Internet Security by identifying objectives and vulnerabilities, and then defining countermeasures to prevent, or mitigate the effects of, threats to the system. Other procedures also may be used. Threat modeling provides traditional risk management and failure mode analysis paradigms, and a framework to assess threats from active adversaries/malicious use. For each vulnerability, a summary report should be produced that concisely summarizes the risk analysis and threat modeling informationa As written, it appears that all cybersecurity information is to be included in annual reports rather than providing the updated information or new information. While the Draft Guidance states that annual reporting is only necessary for PMA devices subject to these reports, we ask that FDA affirmatively state that annual reporting is not necessary for 510(k) cleared devices, even if the same vulnerability is present in a cleared device. ISO is a risk management standard specifically for medical devices. A threat modeling methodology is one option for evaluating cybersecurity risk. NIST SP , rev1, provides several alternative methodologies. We also suggest FDA clarify that the last sentence does not require a separate report for each vulnerability. 17

18 summary report should describe how new vulnerabilities were identified and mitigated. Due to the cyclical nature of the analyses, the information should be traceable to related documentation Delete: and threat modeling. See previous comments above Replace accessing with assessing. We believe this is a typographical error Revise to:... network monitoring or other monitoring techniques We recommend FDA provide additional information concerning the treatment of devices that connect through Bluetooth but do not connect to the internet or allow software to be pushed through as a means of strengthening cybersecurity We ask that FDA consider the addition of a flowchart that helps the reader determine: (1) Whether the Draft Guidance applies; (2) the level of severity of the risk; and (3) the pre- and postmarket requirements that apply based on the level of risk. Network monitoring may not be feasible for some devices. There may be medical devices that do not connect to networks but still may have cybersecurity vulnerabilities from software libraries. Some of the newer software vulnerabilities can alter software performance based on the environment in which the device is operated. The Draft Guidance does not address this situation. We have found flowcharts to be useful tools in understanding the Agency s policies. 18