Published in Privacy & Cybersecurity Law Report’s April 2017 issue.

In the closing days of last year, the FDA issued its final guidance on postmarket medical device cybersecurity. This guidance is a corollary to the previously issued final guidance on premarket cybersecurity issues, and the pre and post market pieces should be read, and fit, together. In both cases, the FDA sets out a comprehensive, and lifecycle approach to managing cyber risk. Under this guidance, the FDA is asking companies to operationalize a structured way to think through and act on these product, hardware, software, and network issues. Last year, we wrote about 5 things companies can do now to get ahead of the curve on the premarket guidance, and they still apply.

The final postmarket guidance follows much of the 2016 draft guidance, with a few important changes. We wrote a detailed piece on the 2016 draft guidance. The two big changes are:  a change in focus from possible cyber impact on the product (what was called the “essential clinical performance” of the device) to a focus on the health impact on the patient if a vulnerability were exploited (what is now called the “patient harm”); and a fleshing-out of the recommended vulnerability disclosure process and time frames. Focusing on the possible impact to the patient seems like a good change. Cyber risk is a function of threat, vulnerability and consequence, and with medical devices, the consequence surely revolves around the patient. It is the second change – around vulnerability disclosure, timing for disclosure, and required information sharing with an industry-wide “Information Sharing Analysis Organization (ISAO)” that will take real thought, work and finesse.

Under the final guidance, if there is an “Uncontrolled Risk” given the exploitability of the vulnerability and the severity of patient harm if exploited, that risk should be remediated “as quickly as possible.” As for notice to the FDA and customers, you must report these vulnerabilities to the FDA pursuant to part 806 (which requires manufacturers to report certain device corrections and removals), unless the manufacturer meets four specific requirements: (1) there are no known serious adverse events or deaths; (2) within 30 days of learning of the vulnerability the manufacturer communicates with its customers and user community describing at a minimum the vulnerability, an impact assessment, the efforts to address the risk of patient harm, any compensating controls or strategies to apply, and commit to communicating the availability of a future fix; (3) within 60 days of learning of the vulnerability, the manufacturer fixes the vulnerability, validates the change, and distributes the fix such that the risk is reduced to an acceptable level; and (4)  the manufacturer participates in the ISAO and provides the ISAO with any customer communications upon notification of its customers. If you meet these obligation and timelines, you do not have to report under part 806 – but if you don’t meet these obligations you do have to report and then are subject to the usual 806 reporting.

So, to avoid part 806, you want to follow the four conditions. But they are more complex than one might think at first glance. As a general matter, information technology companies do not like to notify users of a vulnerability until there is a fix. A known vulnerability without a fix can easily (and often are) exploited by adversaries. Customers are less secure. Therefore, generally companies announce vulnerabilities and fixes together, so that customers can protect themselves before bad guys can exploit. Usually, only on rare occasions, when there is a known active exploit, would you notify customers before you have a fix. The FDA and the medical device industry seem to be searching for the appropriate approach for medical devices, where there is potential for non-trivial patient harm, and an existing regulatory structure and overall public health mission.  The issue of vulnerability disclosure is complex, and subject to much debate (the U.S. Commerce Department just published the results of a year-long study, concluded there is still much work to be done to get it right). Similarly, the issue of information sharing about cyber threat and vulnerability information with others in industry, and with the government is still an area of much discussion. A year ago, Congress passed an information-sharing bill to help reduce potential barriers to information sharing, including provisions for some amount of liability protection for sharing cyber threat and vulnerability information with others. Today, companies are still finding their way around the business and legal issues , even under the new legislation.

Therefore, to meet the 30 and 60 day notice requirements, and the information sharing requirement, medical device companies will have to carefully craft their notices to both meet the specificity requirement in the final guidance, and not disclose enough that adversaries will be alerted to the possibility of a vulnerability, figure out what function, method, process or technology is implicated, focus on that topic and exploit it before a fix is developed, shared, and implemented. The same considerations hold for sharing vulnerability and notice information with the ISAO, whose members will include competitors and which information could (depending on the ISAO rules and information classification decisions) be further shared with government and security industry partners. Net-net, a clear understanding of the technical vulnerability, possible consequences, ability to fix, and appreciation of the line between notification and usefulness for exploit is required. It may also be true that no fix can be had in 60 days, and that if there are many reported vulnerabilities backed-up and in the queue to be fixed, a company may fix the priority tickets first, and then the least priority items may take longer than 60 days to address and fix as a matter of band-width and expertise. Consequently, over time, companies may be faced with decisions about whether to try to meet the 806 exception conditions, or file 806 notices with the FDA and deal with the potential implications. None of this is to say that the benefits of the 806 exception are not worth it, or are trivial, it just means that your approach has to be clueful and strategic.

One more issue, of course continues to be quite important – the global rules must be rationalized. Medical device companies build-once and sell globally, and the security, integrity, vulnerability, and disclosure rules and best practices have to work globally. As these new guidelines get rolled-out, significant education globally will be critical.

Over time, and most likely, like most things in security, this ‘final guidance’ will be a work in progress, as companies and the FDA and regulators globally begin to deal with specific use cases that push the boundaries of what situation is a “Controlled Risk,” an “Uncontrolled Risk,” and what 30 and 60 day notifications, and fixes, and ISAO information is required, helpful, and not helpful. As we always say – ‘security is a journey, not a destination’ – and so too will the postmarket cyber guidance be.