.png)
In April 2022, the FDA released a new draft replacing the 2018 draft guidance. While the 2018 version was never released as a final guidance, it was clear (based on feedback from the agency to our clients) that it was being enforced. I do not expect that the new concepts of the 2022 guidance will be explicitly enforced until it is released. That said, much of the guidance provides clarification of expectations, and that is helpful for current submissions.
Before I start, I need to give a disclaimer. There are 45 pages of the 2022 draft, versus 24 in the 2018 guidance. This blog post is no way inclusive of all the changes, but is a summary of some of the impactful changes from my perspective. I expect even my own perspective and interpretation to change as I use the guidance to build our templates and processes.
At the highest level, the new guidance is clearly about the total product lifecycle (TPLC), and not just premarket. For example, it clarifies that postmarket Vulnerability Management Plans should be in the premarket submission materials. The new guidance also emphasizes that reducing cybersecurity risks in the use environment requires transparency and sufficient information from the manufacturer.
The concept of a Security Product Development Framework (SPDF) is introduced to help reduce vulnerabilities throughout the product lifecycle. While indicating that required controls are still risk-based, gone are the two “tiers” that let unconnected or low-risk devices off the hook with a risk-based rationale. The expressed hope is that even unconnected devices will not need to be re-engineered to later get connected. Also, with the SPDF, all devices will be ready to manage post market vulnerabilities. Preventing manufacturers from tacking on security as an afterthought is clearly the goal - however, the burden for lower risk devices seems untenable.
The 2018 guidance described the need for documentation of the security design, followed by risk management documentation. With the concept of the SPDF, risk management is inclusive of both, and the order has changed. First the manufacturer needs to identify the risks, then show how those risks are addressed with appropriate controls and security architecture. While it may be a subtle difference, it does make more sense to me.
Threat Modeling, while listed in the 2018 version, gets more clarity in the 2022 guidance. Device manufacturers are used to the ISO 14971 approach to risk management (spreadsheets), but the threat model includes more of the process for identification of threats/risks. AAMI TIR57 is referenced in both versions which, in my opinion, is a very good prescriptive guide. We have been using its recommendations for a few years now with our clients, and its example processes for identifying threats are very helpful.
As part of the SPDF, the risk management report is expected to include measures and metrics tracked both for premarket submission and post-market, including (at a minimum):
· Percentage of identified vulnerabilities that are updated or patched (defect density)
· Time from when a vulnerability is identified, to when it is updated or patched
· Time from when an update or patch is available, to when it is completely implemented in devices deployed in the field
A footnote clarifies that this information may not be available if the product has not already been in the market. I initially missed that footnote and was very confused.
Another concept introduced in the document is “Security Architecture Views.” Views are expected to be documented with both diagrams and text. The “views” they expect, at a minimum, are:
· Global System View – Describe interconnections of the system
· Multi-patient Harm View – Describe the defenses and responses in place
· Updateability/Patch-ability View – Provide end-to-end process of deployment of updates and patches
· Security Use Case View(s)
Security use case views should be provided for all system functionality through which a security breach could impact the safety/efficacy of the device. For each use case, diagrams and text are expected, detailing a long (18 items) list for “every communication path that exists between any two assets.” Assets include the device hardware, applications, configurations, health care facility assets, communications assets, and manufacturer-controlled assets (servers). Breaking that down like software:
for each system function that could be impacted:
for every path that exists between any two assets in the view:
Provide 18 detailed descriptions
This is comically burdensome. I really don’t think that is the intent, but it is what is written. Also, hidden deep in that list is a new requirement - traceability to the SBOM.
The postmarket guidance covers vulnerability disclosure, but now, as part of Cybersecurity Transparency, a detailed list of what needs to be in a Vulnerability Communication Plan is provided. The prescriptive list provided is very helpful.
The bill of materials for cybersecurity no longer includes hardware components, hence the name change from CBOM (CybersecurityBill of Materials) to SBOM. The specifics of what needs to be included (ex: name, version) are now provided, integrating information from the Off-the-Shelf (OTS) guidance with the SBOM. The problem that industry-accepted formats may not include everything is addressed with the recommendation that the additional information be an addendum. That sounds painful to me, especially since some of the additional information (ex: level of support and end-of-support date) could be very hard to get, and simply may not be available.
While the 2018 guidance only vaguely mentioned that cybersecurity may be considered for IDEs in a footnote, the new guidance spells out exactly what is needed. This is also nice prescriptive information for anyone doing an IDE.
While wordier and more cumbersome to get through, the new draft guidance appears to provide more clarity on some of the concepts introduced in the 2018 guidance. I like prescriptive guidance, as it leaves no doubt as to what the auditor is expecting. After some digging, I found that this guidance delivers clarity for many aspects. But for some of the new concepts (ex: SPDF and views), new ambiguities arise. The documentation burden required of the “views” appears formidable. Hopefully some tuning of the guidance is coming.
