FDA Pre-Market Medical Device Draft Guidance Review

by | Nov 8, 2018

Letter to the FDA FDA regarding their latest Medical Device Cyber Security Pre-Market Guidance

The FDA released draft guidance for cyber security of medical devices on October 18th, 2018, that if instituted, is going to be an enormous change for the industry, including both medical device manufacturers and healthcare providers.  The guidance is aimed at medical device manufacturers and gives recommendations for what the FDA states should be included documentation provided by the manufacturer to the FDA in the 510k certification process (the process required for a new medical device to be approved by the FDA for sale).


View PDF Here: Draft Guidance for Industry and Food and Drug Administration Staff 


The changes are substantial, and the document has some opportunities for improvement, which are expected of a draft.  SRA will be submitting questions for clarification and comments for improvement to the FDA, though there are some expectations that the final version of this document could be instituted by January of 2019.  We are going to focus on a few key changes, but we will be releasing more materials in the future, including some enhancements to VECTR (https://vectr.io) to support the documentation and security testing processes in a robust and repeatable manner!


Critical Developments


Devices must be classified as “Tier 1” or “Tier 2”  

Tier 1 indicates that it is 1) a networked device, that 2) if compromised, could directly result in harm to multiple patients. Tier 2 is essentially “everything else”, so non-networked, or would not result in direct harm to multiple patients.  The FDA hasn’t yet defined “direct harm”, but the working assumption is that “direct harm” implies that it could actually directly harm patients, without any intervention from a clinician.  If a device reports data in a decision-making process (ex: a medical imaging device) through a clinician, then any harm would be considered indirect, and possible to be detected and prevented by a human interpreting the results.

  • FDA questions: It was noted that the exact language used to describe Tier 1 references a single device harming multiple patients.  Was the singular device and plural patients reference on purpose?  For example, a networked pacemaker device could directly harm a single patient (because it was in Homeland!).  Would that qualify as a Tier 1 device, or a Tier 2 device?  Based on the exact wording, it would appear that it would qualify as “Tier 2” since it can only harm a single patient.


Based on the Tier of your device, you must do the following:

  • Tier 1: You must address all areas of design requirements and risk assessment process in your documentation
  • Tier 2: You must either address all design requirements or provide a risk-based analysis of why that design requirement is not appropriate or necessary for this device.


Device Design Requirements (the most notable ones)

  • No hardcoded credentials, and role-based access control
  • Devices should “deny by default” all connections (network, usb, etc)
  • Application Whitelisting by Signatures
  • Runtime application execution integrity checks
  • Devices should support security and virus scanning without impact to the device
  • Design should enable forensic data capture
  • Cyber security bill of materials (CBOM) for all hardware, firmware, and software
  • Have a certificated, built-in software patching / support mechanism
  • Provide logging to external logging systems
  • Be able to restore a compromised system to original configuration in a secure fashion
    • FDA Questions: For detective controls, there is much detail about how logging must be enabled for cyber security monitoring.  The way it is written is ambiguous about who is the responsible party for monitoring those logs.  Is there an expected responsible party for doing security monitoring?  Should logs be shipped to the healthcare provider, or is there an expectation that the manufacturer should be monitoring security of its devices in the field?


Risk Management Documentation Requirements (the most notable ones)

  • Threat Modeling – A system level threat model that takes into account all phases of the lifecycle of the device, to help identify security controls for implementation in the device design.
  • Risk Considerations – Documentation of all risks considered in the design process, including impact and likelihood / exploitability.
  • Controls List – a list of all verifiable controls identified and implemented in the final design.
  • Testing Evidence and Documentation – detailed test results showing efficacy of all controls implemented. (Contact us for a VECTR-enabled version for this)
  • Mapping of controls implemented to risks identified – tying together threats and risks, to those controls implemented in the device.


Labeling Recommendations

  • Hardening instructions
  • Network behavior (ports and services) manifest
  • Directions for restoration of original configuration
  • Cyber security bill of materials (machine readable)



We hope this was helpful.  Please take a read through the full requirement at the link above, as there is much more. Reach out to us with any questions at mike.pinch@sra.io, or directly to the FDA and provide your feedback and comments at https://www.regulations.gov/ or CyberMed@fda.hhs.gov

Stay tuned as we will be updating this as the guidance evolves, and will share any responses we get from the FDA.

Mike Pinch
CISM, CISA, CGEIT, PMP Interim CISO, Former CTO | Archive

Mike joined Security Risk Advisors in 2018 after serving 6 years as the Chief Information Security Officer at the University of Rochester Medical Center. Mike is nationally recognized as a leader in the field of cybersecurity, has spoken at conferences including HITRUST, H-ISAC, RSS, and has contributed to national standards for health care and public health sector cybersecurity frameworks.

Mike has built and operated enterprise public cloud environments for over a decade, with primary focus on AWS and Azure environments. He frequently advises clients in helping to adapt their cybersecurity programs to the new challenges that cloud adoption creates.

Mike focuses on security architecture and strategy, Zero Trust design, cloud security, emerging technologies, and electronic medical record protection programs.