FDA Cybersecurity Approval Guidelines

Anyone who wants to approve a medical device in the USA has to go to the Food and Drug Administration (FDA – FDA in the USA) is not over. Medical devices are becoming increasingly interconnected and are collecting more and more data. This inevitably means that medical devices become targets of attackers. To counter this, the FDA has developed the guidance document Content of Premarket Submissions for Management of Cybersecurity in Medical Devices Published by [company name]. In this article, I would like to discuss this guide and present its key aspects. Important technical terms are used here in English, as many of them have no proper equivalent in German. This begins with the terms "safety" and "security." Both can be translated into German as "safety." "Safety" refers to functional safety, i.e., the protection of people from machines, while "security" refers to safety against external attacks, i.e., the protection of the machine, the environment, or people from other people.

Who does the guideline apply to?

Primarily, the guideline applies to all medical device manufacturers seeking approval for a product in the United States. This applies to premarket notifications (510k), de novo requests, premarket approval applications (PMAs), product development protocols (PDPs), and humanitarian device exemptions (HDE).

The FDA points out that cybersecurity is a shared responsibility between healthcare institutions, patients, healthcare providers, and medical device manufacturers. The directive aims to provide guidance to manufacturers to consider the following aspects:

1. Risk-based approach to developing medical devices with appropriate cybersecurity protections.
2. Holistic approach to device cybersecurity by assessing risks and mitigations throughout the entire product lifecycle.
3. Ensuring the maintenance and continuity of the safety of critical equipment and essential performance characteristics and
4. Promote the development of trustworthy, effective and safe devices.

In my view, the directive also makes sense for manufacturers who do not FDA-accreditation, as it provides a good guide on how to deal with the topic of cybersecurity.

The risk-based approach

The risk-based approach involves following a process to improve the cybersecurity of the medical device. The process consists of the following steps:

• Identification of assets, threats and vulnerabilities.
• Assessing the impact of threats and vulnerabilities on device functionality.
• Assessment of the likelihood that a threat and a vulnerability will be exploited.
• Determination of the level of risk and appropriate measures.
• Assessment of residual risk and risk acceptance criteria.

Not every device should be viewed equally. Medical devices that are more interconnected (Ethernet, Wi-Fi, USB, Bluetooth, or similar) are naturally more vulnerable than systems that don't have such interfaces. The FDA proposes two levels of devices: devices with high cybersecurity risk (Tier 1) and devices with a normal risk (Tier 2).

The cybersecurity classification is not related to the product classification. For example, a Class II medical device (e.g., an infusion pump) may correspond to the higher Tier 1 classification, while a Class III device (e.g., a pacemaker) without connectivity may correspond to Tier 2. The decision-making process described in the figure above is decisive.

Products that comply with Tier 1 have stricter documentation requirements. All recommendations of the directive must be followed for these products. For Tier 2 products, individual recommendations may be omitted if there is a risk-based justification for doing so.

How can devices protect themselves from attacks?

The overview below provides a checklist of measures you should consider when developing devices. All of these points are taken from the FDA guidelines. Here, we'll briefly outline them to give you an overview.

• Prevent unauthorized access
  • Access restrictions for trusted users and devices
    • Access restriction by user ID, password, smart card or biometric.
    • Automatically logs out the user after a timeout, if appropriate.
    • Use of different access rights
    • Authentication for administrators or service employees
    • Strong passwords. Not hard-coded, easy to guess, default password, same password for all devices, unchangeable passwords, difficult-to-change passwords, publicly accessible passwords.
    • Physical locks to reduce manipulation of communication interfaces.
  • Authentication and verification of security-critical commands
    • Use authentication to prevent unauthorized access to device functions.
    • User authentication before releasing software updates including operating system, applications or anti-malware software.
    • Use of cryptographically strong authentication stored on the device.
    • Authentication of all external devices (e.g. a connection to a server).
    • Authentication of firmware and software (signatures, message authentication, version number, or other metadata). Devices should be electronically identifiable.
    • Authentication should be based on credentials or other means that cannot be triggered by other devices.
    • The device should be implemented according to the "Deny by default" policy. Anything not explicitly permitted should be initially denied. For example, all unauthorized connections (TCP, USB, Bluetooth, serial interfaces) should be denied.
    • Grant rights as flexibly as necessary.
• Ensuring reliable content
  • Code Integrity
    • Only allow software updates that are cryptographically verified. Prevent downgrades.
    • Where possible, verify software integrity before execution (e.g. through digital signatures).
  • Data integrity
    • Check incoming data for integrity.
    • Secure data transfer to and from the device and, where appropriate, point-to-point encryption.
    • Protecting the integrity of data necessary for functional safety and essential performance characteristics.
    • Sufficiently strong encryption according to the state of the art.
    • Device-specific encryption so that if a key is lost, not all devices are affected.
  • Execution integrity
    • Where possible, use best practices to verify code integrity during execution.

Note: Security requirements may conflict with safety requirements! For example, authentication can lead to an unacceptable delay in treatment. In these cases, it's important to balance safety with security, and document the decision.

The directive also mentions data confidentiality, although this topic is not explicitly addressed. As a manufacturer, you have to consider the protection of patient data. The GDPR and other guidelines and laws apply here, for example.

How can devices deal with attacks?

Cybersecurity attacks should, of course, be prevented whenever possible. However, if an incident does occur, it is essential to detect and report the attack, and, if possible, reverse the damage. To do this, the following points should be observed.

• Design of devices so that a cybersecurity attack can be detected promptly.
  • The device is designed to detect attacks during operation and log them with a timestamp.
  • The device should enable routine checks and antivirus scans to be carried out without affecting the essential performance characteristics of the device.
  • The device should be able to create and store logs of cybersecurity-relevant events. It is important to document how and where the data is to be stored, archived, and analyzed.
  • The device should specify secure configurations that limit potential vulnerabilities as much as possible.
  • The device should be designed to support configuration management, allowing authorized users to track software changes.
  • The product life cycle is intended to make it easier to analyze vulnerabilities across different product lines and product variants.
  • The device should contain a CBOM (Cyber Security Bill of Material) in an electronic, machine-readable format. More on this later in the blog post.
• Design of devices to report a cybersecurity attack and assess the impact of an attack.
  • The device is designed to notify the user of a potential attack.
  • The device should be designed so that future software patches and updates can be installed to eliminate vulnerabilities.
  • It should be possible to quickly verify and validate patches and updates.
  • The architecture must make it easy to quickly deploy patches and updates.
• Design of the devices so that functionality can be restored quickly.
  • Implement critical functionalities in such a way that they are not affected even if the device is compromised.
  • A user with special rights should be able to restore device configurations.
  • It must be specified how autonomously the device can continue to operate in the event of a communication failure (resilience).
  • The device should be resilient against possible attacks such as network outages, denial-of-service attacks, excessive bandwidth usage, jitter or other disruptions.

What needs to be taken into account when labeling?

Informing end users can also improve security and thus reduce the risk of attacks. The FDA guidelines mention the following points:

1. Instructions regarding measures to improve cybersecurity when using the product (e.g. use of anti-virus software or a firewall).
2. A description of the features that remain functional even in the event of a compromise.
3. A description of how to perform a backup/restore or reset the configuration (e.g. factory defaults).
4. Instructions for the user regarding the necessary infrastructure to use the device.
5. A description of how the product can be securely configured.
6. A list of network ports and other interfaces that are sending or receiving data. A note indicating that unused ports should be disabled.
7. A description of how a user can safely receive a software update.
8. A description of how a device reports unauthorized access (e.g. failed login attempts, configuration changes, network anomalies and unauthorized communication).
9. Description of the product's logging mechanisms.
10. A description of how an authorized user can restore data and configurations.
11. A detailed description for the end user through system diagrams.
12. A cybersecurity bill of material to enable users to identify vulnerabilities and implement countermeasures.
13. If applicable, instructions on how to establish a secure connection for service purposes. Furthermore, instructions on how users can report security incidents.
14. Information about this should the manufacturer discontinue support. In this case, the risks are expected to increase over time.

Risk management documentation

The Risk management Connects design with the hazard model, clinical risks, controls, and verification. Adequately managing risks requires secure design. The principles for cybersecurity risk management are defined by AAMI TIR57 (Principles for Medical Device Security – Risk Management). Developing trustworthy products requires the following:

1. A system-level hazard model that considers system risks.
2. A list of all cybersecurity risks that apply to the system.
3. A list of all implemented cybersecurity measures, including their justification. The measures must be formulated in the form of verifiable requirements.
4. Documentation of test results.
5. A traceability matrix that links cybersecurity risk control measures with risks and verification.
6. A Cybersecurity Bill of Material (CBOM). More on this in the following chapter.

The following topics need to be addressed for verification:

1. Testing device functionality
2. Proof that third-party software (off-the-shelf software) is cybersecurity secure.
3. Static and dynamic code analysis with testing of access data (hard-coded passwords, default passwords or passwords that are easy to guess or easily bypassed.
4. Vulnerability scan
5. Robustness tests
6. Limit analysis
7. Penetration testing
8. Test reports from outsiders.

What is the Cybersecurity Bill of Material (CBOM)?

The CBOM is a complete list of all components, including commercial software, open source software, off-the-shelf software, and hardware, that may have cybersecurity vulnerabilities. When compiling the CBOM, databases such as the National Vulnerability Database (NVD) or other similar databases for vulnerabilities and known incidents. Criteria for addressing vulnerabilities must be established and reasons documented if vulnerabilities are not remediated.

Conclusion

Protecting devices against attacks is becoming increasingly important. There are numerous regulations and sources that medical device manufacturers can consult. The FDA guideline discussed here is certainly a very important one and provides some important guidance to consider during design. And not only if you want to obtain approval for the product in the US. We are increasingly noticing that cybersecurity is playing an increasingly important role in our projects, and we support our customers in developing trustworthy and secure medical devices. If you have any questions, please feel free to contact us.

Best regards
Goran Madzar