Software in Medical Devices, by MD101 Consulting

Scope of the guidance

The new cybersecurity guidance stretches its scope to all concerns about confidentiality, security, privacy and so on. It applies also to any medical device software, including firmware. Networked software comes immediately to our minds, but not only. Even if software is embedded in a medical device without any kind of external connection, it is in the scope of the guidance. Hence such device, say, with a software update capability by USB stick, could be subject to cyber attacks.

Content of the guidance

After classical introduction, scope, and a bunch of definitions, the guidance contains three main sections: general principles, cybersecurity functions, and cybersecurity documentation.
Note: text in italic font in this article, quotes sentences from the guidance.

General principles

I won’t paraphrase the general principles in the guidance, and let you read them by yourself. If you don’t have time, just remember that:

1. The FDA recognizes that medical device security is a shared responsibility between stakeholders (including manufacturers),
2. Manufacturers should address cybersecurity during the design and development of the medical device,
3. Cybersecurity management approach is part of the software validation and risk analysis.

As a consequence (this is my interpretation), manufacturers should include in their design procedure and risk-management procedure provisions to manage cybersecurity.

Cybersecurity Functions

In this section, the FDA recommends that medical device manufacturers consider the following cybersecurity framework core functions to guide their cybersecurity activities: Identify, Protect, Detect, Respond, and Recover.
This framework is the National Institute of Standards and Technology Framework for Improving Critical Infrastructure Cybersecurity.

The guidance then gives more information about the recommended actions related to these core functions, like Limit access to devices through the authentication of users, or Restrict software or firmware updates to authenticated code.
Needless to say that it is highly recommended to have rationale when some of these functions are not applicable to your device or when an alternative method or approach is used.

This list of recommended actions is a good set of input data for cybersecurity risk analysis. Like the questions found in annex C of ISO 14971, these recommendations could be rephrased in a set of questions used to come up against cybersecurity concerns.

Cybersecurity documentation

This section gives FDA expectations about documents and records bringing evidence that cybersecurity management process completion. To sum-up:

1. During software design: hazard analysis, cybersecurity controls, and traceability matrix between both,
2. During software use and maintenance: plans, controls, and instructions put in place to ensure device cybersecurity throughout its lifecycle.

The FDA expects especially a plan for providing validated software updates and patches as needed throughout the lifecycle of the medical device to continue to assure its safety and effectiveness. This makes the link with the previous guidance about Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software, hence the plan should include actions to monitor OTS software security concerns.
Note that this documentation should take place in the DHF. The cybersecurity plans, controls and instructions put in place to manage cybersecurity after design transfer should also be in the DMR.

Recognized standards

The guidance ends with a list of recognized standards dealing with IT security. IEC 80001-2-2 is here as well as other standards about IVD security, and about Industrial communication networks security.
The most notable absentee in this list of standards are: ISO 27001 and ISO 27005. These standards are about security of IT systems, usually the concern of health care providers. But the FDA states in the beginning of the guidance that cybersecurity is a shared responsibility between stakeholders. If so, why not adding ISO 27001 and ISO 27005? Manufacturers know that the HIPAA rules have an impact on medical device software design. Likewise, ISO 27001 and ISO 27005 may have an impact on medical device software design and manufacturers should be aware of it.

Conclusion

The conclusion was already in the first paragraph of this post: At last! A cybersecurity guidance! Once again the FDA is a giant leap further than ROW regulation authorities (Hello, European Commission!).