We celebrated National Cybersecurity Awareness Month a few weeks ago by bringing you the FDA’s newly published Medical Device Cybersecurity Regional Incident Preparedness and Response Playbook, with a promise to cover the Agency’s promised update on its Guidance for Content of Premarket Submissions for Management of Cybersecurity in Medical Devices, which was first published in 2014.
Well, the Agency has now published the Draft Guidance (you can review it here), and it is really interesting for a few reasons. First, the FDA continues to view medical device cybersecurity risks through the same lens as it views any other risk. That is to say, treatment with any medical device presents potential risks, and premarket submissions for connected medical devices should permit analysis of cybersecurity risks compared against the device’s benefits. Second, the Draft Guidance generally follows the philosophy and framework set forth in the FDA’s current guidance, but places considerably greater flesh on the bone. Third, the Draft Guidance places a much greater emphasis on medical device warnings, including suggesting the inclusion of a long list of detailed information—so much information that we wonder about usefulness and feasibility.
So what does the Draft Guidance say? The theme is that the increasing use of connected medical devices and portable media in medical devices makes effective cybersecurity more important than ever to ensure device functionality and safety. The Draft Guidance’s mission is clear: “Effective cybersecurity management is intended to decrease the risk of patient harm by reducing device exploitability which can result in in intentional or unintentional compromise of device safety and essential performance.” (Draft Guidance, at p.3) “Intentional or unintentional.” In other words, we are talking here not only about bad actors and malicious attacks, but also accidents and other situations where no harm to a device’s function was intended at all.
One new feature is the creation of two tiers of medical devices: A device is “Tier 1, Higher Cybersecurity Risk” if (1) the device is capable of connecting to another medical or non-medical product, or to a network, or to the Internet; AND (2) a cybersecurity incident affecting the device could directly result in patient harm to multiple patients. All other devices are “Tier 2, Standard Cybersecurity Risk.” (Id. at 10) The catch-all nature of Tier 2 seems odd at first blush because it would appear to include devices for which there is no conceivable cybersecurity risk, such as orthopedic implants. Also note that these tiers cut across the FDA’s existing statutory device classifications, such that a Tier 1 device could be Class II or Class III device. They are separate criteria. (Id.)
The consequence of falling into Tier 1 is that the Draft Guidance calls for considerably more exacting information in premarket submissions. More specifically, premarket submissions for Tier 1 devices should “include documentation demonstrating how the device design and risk assessment” incorporate certain design controls that accomplish the following:
- Identify and Protect Device Assets and Functionality – The focus here is on the design of “trustworthy” devices and the presentation of documentation demonstrating “trustworthiness.” A trustworthy device should prevent unauthorized use through sufficient authentication and encryption; should ensure the trustworthiness of content by maintaining “code, data, and execution integrity” through such measures as software/firmware updates and enabling secure data transfer; and should maintain confidentiality. ( at 11-16)
- Detect, Respond, Recover – As the Draft Guidance puts it, “appropriate design should anticipate the need to detect and respond to dynamic cybersecurity risks.” This includes designing the device to detect cybersecurity events promptly. It also includes designing the device to respond to and contain the impact of cybersecurity incidents and to recover its capabilities. This would be though such measure as routine security updates and patches, systems to detect and log security compromises, features that protect critical functionality, and measures for retention and recovery of system configurations. It also includes something called a “CBOM”—a Cybersecurity Bill of Materials, essentially a list of hardware and software components that are or could become susceptible to vulnerabilities. ( at 16-18)
Perhaps the most interesting part of the Draft Guidance is the recommendation for device labeling. As product liability litigators, medical device labeling is near and dear to our hearts because a manufacturer’s potential liability often depends on the adequacy of the risk information and instructions for use.
The FDA seems to agree that device labeling is important. After citing the governing statutes and regulations, the Agency counsels that “when drafting labeling for inclusion in a premarket submissions, a manufacturer should consider all applicable labeling requirements and how informing users through labeling may be an effective way to manage cybersecurity risks.” (Id. at 18-19) The Draft Guidance then lists 14 separate factors that it recommends for inclusion in the labeling. We paraphrase them below not because we expect you to study them, but more so you can get a sense of how exacting these recommendations could be. Here goes:
- Device instructions and product specifications related to recommended cybersecurity controls appropriate for the intended use environment;
- A description of the device features that protect critical functionality;
- A description of backup and restore features;
- Specific guidance to users regarding supporting infrastructure requirements;
- A description of how the device is or can be hardened using secure configuration;
- A list of network ports and other interfaces that are expected to receive and/or send data, and a description of port functionality and whether the ports are incoming or outgoing;
- A description of systematic procedures for authorized users to download version-identifiable software and firmware;
- A description of how the design enables the device to announce when anomalous conditions are detected (e., security events);
- A description of how forensic evidence is captured, including but not limited to any log files;
- A description of the methods for retention and recovery of device configuration;
- Sufficiently detailed system diagrams for end users;
- “A CBOM including but not limited to a list of commercial, open source, and off-the-shelf software and hardware components to enable device users . . . to effectively manage their assets, to understand the potential impact of identified vulnerabilities to the device (and the connected system), and to deploy countermeasures to maintain the device’s essential performance”;
- Where appropriate, technical instructions to permit secure network deployment and servicing, and instructions on how to respond upon detection of a cybersecurity vulnerability or incident; and
- Information, if known, concerning device cybersecurity end of support, e., the time when the manufacturer may no longer be able to reasonably provide software patches and updates.
We support providing adequate information to device users, and we doubly support taking medical device cybersecurity seriously. These recommendations, however, raise several questions. For one thing, who is the intended audience? The learned intermediary doctrine in most every state holds that medical device warnings are for the prescribing physicians—and no one else. Is this information to be written for physicians, or IT professionals, or even patients? We don’t know.
We also wonder about whether it is feasible to provide all this information, or even useful. Maybe it would be both, or maybe neither. But we think it is fair to ask whether providing “sufficiently detailed system diagrams” and lists of “commercial, open source, and off-the-shelf software and hardware components” is the most helpful information for protecting patient health and safety. What is a “CBOM”? We also wonder how the adequacy of this information would be judged. Unlike medical risk information, this information is beyond what most physicians (the learned intermediaries) would readily appreciate. In the so-far-extremely-unlikely event that a cybersecurity incident results in harm to a patient, will we have a new category of experts to depose?
To round it out, the Draft Guidance recommends including design documentation and risk management documentation that demonstrates device trustworthiness and the design’s connection to “threat models, clinical hazards, mitigations, and testing.” (Id. at 21-22)
The above questions and more can be presented to the regulators as they consider the Draft Guidance and put it in final form. Comments and suggestions are currently due sometime next March, although these deadlines tend to slip. We will eagerly see what people have to say. Stay tuned.