Software in Medical Devices, by MD101 Consulting

This is a long guidance, like every FDA guidance, you’d say. However, every word counts. This guidance is 45 pages long and contains 40 pages of recommendations in every other paragraph. That makes a lot of recommendations. A hell lot of recommendations.
(Translation for beginners: recommendations = requirements, unless you’re feel wiser than the FDA to overlook these recommendations).

These recommendations are very precise and were obviously written by cybersecurity experts, making this guidance of a quite high technical level. Meaning that you’ll need people qualified enough to understand these recommendations. That was not exactly the case with the previous guidance, where software design teams could evade the issue.

If you want to implement this guidance the right way, you’d better take every recommendation seriously. A good option is to put the paragraphs of the guidance in a traceability table to your QMS procedures / instructions, DHF / DMR / DHR and 510(k) templates. Needless to say, it will take a hell lot of man-hours to implement it seriously.

Secure Product Development Framework (SPDF)

The keyword of this guidance is: SPDF. The FDA gives this definition: An SPDF is a set of processes that reduce the number and severity of vulnerabilities in products throughout the device lifecycle.
In short, a manufacturer has to integrate cybersecurity provisions in the QMS procedures covering the software lifecycle. E.g.: Software risk management, design, V&V, installation, support, maintenance, decommission. The SPDF also spreads its branches to customer complaints, and CAPA. The procedures generate cybersecurity documentation output recorded in the DHF, DMR, and DHR, as well as premarket submissions like section 16 of a 510(k) file.
To do so, the FDA relies on the National Institute of Standards and Technology Framework Cybersecurity Framework (NIST CSF) and the Medical Device and Health IT Joint Security Plan (JSP). Both have the virtue to be freely accessible. This way, the FDA respects the basic cybersecurity principle to have free access to relevant cybersecurity information.

Security risk management process

Among all topics addressed by the guidance, the security risk management is probably the first one to implement. Relying of the AAMI TIR 57, the FDA recommends to conduct and document a security risk management file separated from the safety risk management file. Note that documents shall be separated, but not the safety and security risk management processes. Those two processes interact one another.

There are also quite good discussions about Security Assessment of Unresolved Anomalies and TPLC Security Risk Management. E.g.: the magnitude of effects of unresolved anomalies in terms of security can be far higher than safety.

Security architecture

The draft guidance is prescriptive about what it expects in terms of documentation about security architecture. It recommends to document 4 specific types of architectural views:

• Global System View
• Multi-Patient Harm View;
• Updateability/Patchability View; and
• Security Use Case View(s)

It also recommends to document traceability between the elements found in these views and security requirements.

That confirms the exit of Low Level of Concern / IEC 62034 class A documentation.

Link with European harmonized standards.

Fortunately, the guidance also quotes the ISA 62443-4-1 standard as a possible framework to implement cybersecurity provisions throughout the SW life cycle.

IEC 81001-5-1

This allows us to bridge this draft guidance with the future European Harmonized standard: IEC 81001-5-1. That standard actually stems from ISA 62443-4-1 and its structure is similar to the one of IEC 62304. Thus, IEC 81001-5-1 defines a SPDF over the software lifecycle framework of IEC 62304.
That makes possible to have procedures encompassing both this FDA guidance and the EU harmonized standard at the same time. Especially, the section V.C Cybersecurity Testing defines a testing strategy very similar to IEC 81001-5-1.
But some gaps remain. The draft guidance goes further than the standard on some subjects like architecture documentation, and vice-versa in IEC 81001-5-1, like secure software documentation acceptance criteria and reviews.

IEC 60601-4-5

The draft guidance doesn’t quote neither ISA 62443-4-2, nor IEC 60601-4-5. They’re not recognized standards. So that’s not surprising.
Alternatively, the draft guidance contains a section V.B.1 Implementation of security controls and Appendix 1 on Security Control Categories and Associated Recommendations. We retrieve in this appendix a content roughly similar to ISA 62443-4-2. But in a more condensed manner. This content is also focused on medical devices, whereas the ISA standard comes from another industry.

On the labeling side, IEC 60601-4-5 defines in clause 6 Technical Description a long list of information to communicate to users. The draft guidance does the same in the section A Labeling Recommendations for Devices with Cybersecurity Risk. Beware of the possible gaps between the two.

We can wonder why neither ISA 62443-4-2, nor IEC 60601-4-5 are recognized standards. It's true that these two standards are applicable to medical devices with some drawbacks:

• IEC 60601-4-5 cannot be used without ISA 62443-4-2,
• ISA 62443-4-2 itself references ISA 62443-3-3, the latter is needed to fully understand some security requirements,
• The wording of ISA 62443-4-2 is oriented to industrial systems. This makes necessary a clumsy interpretation of its requirements body text to apply them to medical devices.

I don't have the true reason with the FDA doesn't recognize these two standards. But these drawbacks are enough to explain the situation.

And UL 2900-x?

UL 2900-x are recognized standards. However, the draft guidance quotes them only in a footnote: The following standards may partially meet the security testing recommendations in ANSI/UL 2900 Software Cybersecurity for Network-Connectable Products (...).
The draft guidance just reserves a small folding seat to UL 2900. ISA 62443-4-1 takes the lion's share, quoted twice in the guidance. Especially in introduction to section V: Frameworks from other sectors may also comply with the QSR, like the framework provided in ANSI/ISA 62443-4-1 (...).
UL 2900 was in 2017 the first recognized standard about cybersecurity. It has been the reference about cybersecurity since them. The draft guidance changes the situation and fosters more the use of ISA 62443-4-1. UL 2900 is reduced to testing recommendations.

Conclusion

Recognized standards or not recognized standards, this draft guidance open the Pandora's box to an SPDF. It will require a hell lot of work to be implemented in a correct manner. Prepare your Secure Software Design procedure, your Security Risk Management procedure, and all their siblings!