Cybersecurity: What’s expected by the FDA?
How to ensure security and demonstrate compliance
Before diving into the regulatory framework and its requirements, a quick recap of the importance of securing medical devices. Last year (in 2023) the medical device industry has seen one of the biggest breaches in the industry so far, where Henry Schein, as a distributor of medical devices, was held hostage through the use of ransomware, consequently over 35 terabytes of sensitive data was allegedly stolen from Henry Schein. A quick review of the US Department of Health and Human Services Office for Civil Rights portal for breaches within healthcare shows that breaches occur nearly on a daily basis. The amount of health records breached in the United States for only July 2024 already runs up to more than 900,000 individual records. Clearly, many of these breaches do not originate directly from medical devices, however, digital medical devices do require IT infrastructure, and store information on such infrastructure. This is where the FDA cybersecurity requirements require manufacturers of medical devices to consider the cybersecurity aspects beyond the traditional borders of their own developed components.
Clearly, the confidentiality of healthcare information needs to be preserved and breaching thereof is an enormous problem today. At the same time, the entry of malicious parties into the systems of hospitals can likewise affect the authenticity of data within medical devices and availability of such devices. Such consequences are potentially far more severe, where such attacks could directly affect patient safety. Consider the example of a threat actor threatening to shut down heart monitors in an Intensive Care Unit (ICU) if their demands are not met within a short timeframe. At the same time, threats may not be limited to malicious actors, for example, the recent flawed update of Crowdstrike managed to significantly disrupt the healthcare systems, including medical devices on a global scale.
In this blogpost, we’ll run you through the cybersecurity requirements set out in guidance and eSTAR version 5 that are to be met when aiming to launch in the United States, and how these requirements fit into the larger security frameworks.
FDA’s Regulatory Framework
Cybersecurity requirements are not new in the United States, FDA already released their cybersecurity guidance back in 2014 both for pre and post market purposes. Yet, the FDA has recently started to enforce the guidance through new regulations. In 2023 the Consolidated Appropriations Act (2023) entered into force, which added section 524B to the FD&C Act, which aims to enforce cybersecurity requirements. It specifically enforces the requirements on ‘Cyber Devices’, explained below.
"cyber device" is a device that
includes software validated, installed, or authorized by the sponsor as a device or in a device,
has the ability to connect to the internet, and
contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to the cybersecurity threats.
If manufacturers are unsure as to whether their device is a cyber device, they may contact the FDA.
Many software medical devices will fall into this definition, as many devices will include or be software, have an ability to connect to the internet (directly or indirectly), and nearly all software has the ability to be vulnerable to cybersecurity threats. The scope of application may be broader than you would expect, e.g. considering the following example.
Recently, a company that has been manufacturing in-vitro diagnostic tests for years, has been challenged in their PMA process by the FDA. The manufacturer of the diagnostic test provides the full test system including third party equipment and operating software. FDA has requested the manufacturer to provide the Cybersecurity documentation for the full test setup, including the third party components, such as test equipment, off-the-shelf PC and the software to operate the test equipment. This case highlights that as a manufacturer of a non-software component, you will be challenged on the full set up of the entire system, even though that equipment might not fall under your direct remit.
Consequently, the FDA released the Premarket and Quality Management System guidance regarding cybersecurity in September 2023, and is developing further guidance to amend the document from 2023 to align with section 524B. At the same time, the FDA released eSTAR Version 5, that further tightens the framework, by hardcoding the need to upload cybersecurity elements as part of a 510(k), De Novo or PMA submission.
The requirements set out by the FDA closely align with those set out in the IEC 81001-5-1, which any manufacturer should consider as the State of the Art ‘Security Lifecycle’ standard. It closely aligns with IEC 62304 and also applies to Healthsoftware (rather than medical devices only). Note that the standard is recognised by the FDA.
Cybersecurity Requirements
While the cybersecurity guidance set out by the FDA is extensive, it may not be the starting point for a manufacturer. Instead, manufacturers should focus on setting up a Security Lifecycle Plan for their products early in the development process. The plan should specify the Security Objectives for the development of the product, aim to establish a full overview of all applicable guidance and legislation with regards to Cybersecurity and define the interaction with the Software Development processes. For example, in the United States in addition to FDA’s product requirements, additional requirements for the product and related procedures and documentation may come forth from other legislation, e.g. HIPAA if the product handles Personal Health Information (PHI). Additionally, it should consider the roles and responsibilities for cybersecurity, which may require the need for hiring new staff members or external support.
The Security Lifecycle Plan should further define the Security Lifecycle File to be developed, which should include at the minimum the items specified below.
| eSTAR defined deliverable | Notes |
|---|---|
| Security Risk Management Report | Security and Safety Risk Assessments should not be combined. For guidance refer to AAMI/TIR 57 for explanation on the interaction with Safety Risk Management. Hint: Reflect on the Security Plan, and attach appendices such as the Threat Model (including Data Flow Diagram), the Risk Assessment, Cybersecurity Metrics. |
| Threat model | This should include a Data Flow Diagram, chosen assessment method for the threats, threat mitigations, and links to the Security Testing needs. The Data Flow Diagram is intended to reflect the full end-to-end set up, and not just the device itself. Hint: Include the above in the Security Plan as appendix or within the body of the plan. FDA has worked with MITRE to develop comprehensive guidance on Threat Modeling for Medical Devices specifically. Further useful guidance is provided by OWASP.org. |
| Risk Assessment | Execute the Threat Model exercise, document the threats, mitigations, and reduction of threats. Ensure traceability between threats, mitigations, testing and testing results. Hint: Methods of executing the Threat Model can be based on AAMI/TIR 57 as guidance, e.g. assessing risks per asset. Instead of using ‘probability’ assess risks per the concept of ‘exploitability’. |
| Software Bill of Materials | To determine vulnerabilities, FDA requires the set up of a Software Bill of Materials. It should specify all software components (including SOUP/OTS) and assess their level of support and potential vulnerabilities. Vulnerabilities should be assessed for their risk. Hint: Consider assessing the known vulnerabilities within the Threat Model Risk Assessment, to determine their acceptability. There are tools available that can support the generation of an SBOM. FDA refers to useful guidance on the set-up of an SBOM. |
| Unresolved Anomalies | Generate a list of the Unresolved Anomalies, and assess their potential risk and implications on safety and performance and security of the medical device. Hint: Clearly, this should include known vulnerabilities which may be followed-up on in post market stages. |
| Cybersecurity Metrics | FDA requests to specify the Security Metrics which the manufacturer will measure in post market stages, and if known results for prior models should be included in the submission. Hint: FDA provides three measures and metrics that should be monitored by manufacturers, consider adding additional metrics in view of the security risk associated with the device. |
| Cybersecurity Controls | A list of the Cybersecurity Controls is to be generated based on the Threat Model exercise. The Cybersecurity controls should consider the following controls (as relevant): Authentication, Authorization, Encryption, Code, Data & Execution integrity, Confidentiality, Event Monitoring and Logging, Resilience and Recovery, Firmware and Software Updates. Hint: In the Threat Modeling approach, when designing Threat MItigations, per Threat consider the controls indicated above, and specify their category. All Security Controls should come forth from identified threats. |
| Architecture Views | Within the Architecture documentation, the manufacturer needs to consider architecture views to explain how the system is set up, how it fits into the larger environment and should include Global System Views, Multi-Patient Harm View, Updateability/Patchability and Security Use Case Views. Hint: These may be created as part of the Threat Model exercise. |
| Cybersecurity Testing | All threat mitigations (controls) require testing to ensure their effectiveness. Testing should be risk-based, and may require the involvement of an independent party to perform Penetration testing. Hint: When considering penetration testing as irrelevant, provide a rationale as part of the final Risk Management Report as to why it is considered irrelevant. |
| Cybersecurity Labeling | FDA doesn’t demand separate Security Labeling (e.g. a security manual), it may however be useful as a manufacturer if the audience is different from the final user (e.g. IT versus physicians). Otherwise requirements can be included for example in an Instructions for Use. Hint: Security Mitigations may be included in instructions to the user, such as installing a firewall or anti-malware software. Have a close look at the eSTAR document and guidance provided by FDA to understand what may be relevant. |
| Cybersecurity Management Plan | Last but not least, develop a Cybersecurity Management Plan, which should include explanations of the post market activities to be executed from a cybersecurity management perspective. Include any follow-up from pre-market vulnerabilities and timelines for resolution. Hint: Implement Security Patching procedures into your QMS, along with Post Market Monitoring procedures for security purposes. These can be linked from the Cybersecurity Management Plan and be used for multiple devices out in the field. |
At the heart of the full Security Lifecycle is the threat modeling exercise, which closely aligns with, but is not the same as Safety Risk Management. To enable effective Threat Modeling, manufacturers start with the creation of a Data Flow Diagram (DFD). Various flowchart tools are available to create such as DFDs, e.g. using Microsoft Visio, LucidChart, Draw.io or Miro. Based on the DFD organizations can embed the threats as a separate category within Matrix Requirements, e.g. as per the image below.
Within the configuration settings of Matrix Requirements, organizations can fine-tune their chosen methodology in order to demonstrate compliance through setting the category settings and configuring the traceability rules (e.g. a Threat Mitigation MUST originate from a Threat). It may look like the image displayed below. It can be useful to include a reference to which STRIDE (or similar) threat category each threat belongs to ensure implementation of mitigations that address the specific threat.
Consequently, each ‘Threat’ can be linked to mitigations (requirements), test cases and executed test runs to demonstrate full traceability towards the FDA in the final report. Having a structured approach as per the above will support in demonstrating compliance with the FDA requirements, and similarly with IEC 81001-5-1, which is currently considered state of the art.
Security within the QMS
Cybersecurity aspects are not limited to the product, but also affect Quality Management Systems. Ideally requirements regarding Cybersecurity are embedded within the: (a) Product Development procedures, (b) Product Change procedures, (c) Post Market Surveillance processes, (d) Customer Feedback / Complaints, (e) Servicing and Maintenance, (f) Purchasing and Supplier Control and ultimately (g) Incidents and Breach procedures.
These procedures should reflect considerations with regards to the identification of security requirements, testing, monitoring, updates and investigations. The results of the full security process should be monitored and their results discussed, e.g. during management reviews.
As a side-note, compared to the device’s safety environment in which the device is used, the security environment (‘threats’) is changing at a much faster pace, and monitoring of security risks is crucial once a device is released onto the market. Continuous monitoring of new threats, vulnerabilities (CVE’s, CWE’s) of both in-house developed software components and OTS / SOUP components is important to ensure the device continues to be secure when released onto the market.
Therefore procedures of a manufacturer should facilitate releasing security updates at a fast pace without compromising safety or performance.
Conclusions
While Cybersecurity requirements are not new, the framework has clearly tightened to a large extent with these new regulations, guidance and the eSTAR format being put in place by the FDA. The current pending guidance may introduce further changes in what is expected from the end of the FDA, as it has raised quite a few comments for input from manufacturers and organizations.
As raised in the introduction of the article to date the main security concerns today in the field seem to relate to unauthorized disclosure of confidential information. There have been no reported deaths or injuries as a result of the Crowdstrike outage, however, medical devices relying on operating systems which were down due to the issue clearly were affected. Manufacturers should consider how security can affect product safety, and protect their devices in relation to the risks involved. Having knowledgeable staff and security experts is of key importance in keeping medical devices secure. Clearly, this all comes with raised costs, however considering the implications this may have for patients, manufacturers should probably have made the investment already prior to the FDA introducing these requirements.
In comparison to the EU, the FDA is extensive in providing guidance to manufacturers, it is strongly recommended to read up on the guidance that FDA has made available over the recent years, and monitor for new developments.