The New 2022 FDA Draft Cybersecurity Guidance: What has Changed?

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.

The High Level Differences

Total Product Life Cycle (TPLC)

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.


Risk Management

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.


Security Architecture Views

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.

Vulnerability Communication Plan

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.


Software Bill of Materials (SBOM)

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.


Investigational Device Exemptions - IDEs

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.

Need help on this topic?
Contact Us
Frances Cohen

Frances Cohen is President of Promenade Software Inc., a leading software services firm specializing in medical device and safety-critical system software. Frances has more than 20 years of experience leading software teams for medical device software. Starting with heart defibrillators for Cardiac Science and following with Source Scientific LLC and BIT Analytical Instruments Inc., Frances has overseen dozens of projects through development and the FDA, including IDEs, 510(k)s, and PMAs.  

Frances has a B.S. in computer engineering from the Technion, Israel Institute of Technology.

linkedin logo
16 Technology Drive, Suite 100
Irvine, CA. 92618, U.S.A.
linkedin logo
linkedin logo
facebook logo
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Promenade Software, Inc. specializes in software development for medical devices and other safety-critical applications.
Promenade is ISO 13485, and CyberMed • Cloud is SOC2 Type II certified.