FDA Offers (draft) Guidance on Cyber Security

The FDA has issued a draft guidance document on the expected content of premarket submissions with respect to medical device cybersecurity.  This guidance targets individual medical devices rather than the network they may be resident on, and it also includes non-networked devices. The FDA notes that both networking capability and  portable media increase vulnerability. The latter issue might be called intermittent or remote connectivity.

Guidance documents tell interested people what the FDA's current thinking is relevant to its regulatory authority, in this case the review of 510(k), PMA and related submissions. A draft guidance is in effect what the FDA is thinking about thinking. Drafts go through a comment period (90 days in this case) after which the FDA contemplates the comments and, after an unspecified time, either issues a guidance document, issues a revised draft, withdraws the draft, or just lets it sit there. Since guidance documents are not requirements, there is standard language that you can use an alternate approach if you can justify it. An open question for me is whether even a draft sufficiently establishes an FDA expectation that should be followed in the interest of a smooth submission review.There are many draft guidances currently under comment or post-comment review, including the long awaited guidance on medical apps discussed here.

The current relatively brief draft has three interesting sections. The first defines the cybersecurity issue, the second is how a medical device might address cybersecurity, and the third is what documentation the FDA would expect to see if the draft becomes final in more-or-less its current form.

The cybersecurity issue is framed in the usual way with respect to the medical device providing confidentiality, integrity, and availability. The factors addressed are controlled access;  data and information accuracy including modification control; and that the data, information, and  systems are accessible and usable  on a timely basis in the expected manner. It is suggested that manufacturers should consider these issues during the design phase, defining and documenting the applicable risk analysis and management plan; identifying assets, threats, and vulnerabilities; conducting an impact assessment of the vulnerabilities; and conducting a residual risk assessment based on established acceptance criteria. While here being applied to cybersecurity, all of this is fairly basic design control and risk analysis including the notion that these are issues to be addressed during design as opposed to cobbled together at the end (if at all) .

Moving on to control capabilities, it is recognized in the draft that the type of controls needed depend on the environment of use, the nature of the risk, and the potential effects on patients. It is recommended that there be justification for the security features chosen including access control, content control, and fail safe and recovery.  Access control includes well known features such as IDs, passwords,and  the dreaded auto-logoff.  (My internist pointed out auto-logoff as one of the things he hated about his EHR, although EHRs are not regulated as medical devices.)

The trusted content component includes restricting updates to authenticated code, identifying authorized downloaders, and secure data transfer to and from the device. The issue of authorized downloaders may encourage some manufacturers to limit user access for such purposes, behavior that infuriates hospital clinical engineers and third party service organizations when they are locked out of device maintenance and repair, and in turn face associated service charges that often seem excessive.

Fail safe and recovery includes protecting the device’s critical functionality, even when the device’s security has been compromised; recognition of security compromises; and providing  methods for retention and recovery of device configuration by an "authenticated system administrator." This may again provide temptation to restrict access, and charge accordingly.

While most of the above is relatively standard material (albeit not always adequately considered or implemented), the need for the manufacturer to specifically address how they dealt with these issue in their FDA submissions is perhaps new, or newly made explicit. As the FDA nicely puts it, they "recommend" the inclusion of hazard analysis, mitigations, and design considerations pertaining to cybersecurity risks including  a list of all risks  considered; a list and justification for all cybersecurity controls that were used; a traceability matrix that links the security controls to the risks; and a systematic plan for providing validated updates and patches. Also recommended is appropriate documentation of controls to ensure that the device will be  delivered free of malware; and the inclusion of instructions for anti-virus software and/or firewall use.

Subject to what happens to this draft, and when, these FDA expectations reflect a potentially important baseline for explicit cybersecurity considerations, mitigations, and documentation.