We meet and go beyond the cybersecurity guidance provided by the FDA. See how we map our offerings to the FDA premarket cybersecurity guidance (Draft, April 2022).
Device manufacturers must establish and follow quality systems to help ensure that their products consistently meet applicable requirements and specifications.
As part of design controls, a manufacturer must “establish and maintain procedures for validating the devices design,” which “shall include software validation and risk analysis, where appropriate.
An SPDF is a set of processes that help identify and reduce the number and severity of vulnerabilities in products. An SPDF encompasses all aspects of a product’s lifecycle, including design, development, release, support, and decommission. Additionally, using SPDF processes during device design may prevent the need to re-engineer the device when connectivity-based features are added after marketing and distribution, or when vulnerabilities resulting in uncontrolled risks are discovered. An SPDF can be integrated with existing processes for product and software development, risk management, and the quality system at large.
FDA will assess the adequacy of the device’s security based on the device’s ability to provide and implement the security objectives below throughout the system architecture.
Because exploitation of known vulnerabilities or weak Cybersecurity controls should be considered reasonably foreseeable failure modes for systems, these factors should be addressed in the device design.
As Cybersecurity is part of device safety and effectiveness, Cybersecurity controls should take into consideration the intended and actual use environment.
A lack of Cybersecurity information, such as information necessary to integrate the device intothe use environment, as well as information needed by users to maintain the medical devicesystem’s Cybersecurity over the device lifecycle, has the potential to affect the safety andeffectiveness of a device.
Device Cybersecurity design and documentation are expected to scale with the Cybersecurity riskof that device. Manufacturers should take into account the larger system in which the device maybe used.
Helm, Medcrypt's vulnerability management solution, enables management of a system's software bill of materials, including determining when vulnerabilities are relevant.
Medcrypt has developed a Cybersecurity-enabled Quality Fabric (CeQ) that provides an easy-to-follow template and model implementation of a Secure Product Development Framework (SPDF), enabling medical device manufacturers to demonstrate compliance with evolving security regulations as well as ultimately produce safer devices.
Medcrypt solutions are accompanied by documentation to support FDA documentation and QMS requirements.
"FDA recommends that security risk management processes, as detailed in the QS regulation, be established or incorporated...regulation which may be relevant in this context include, but are not limited to design controls (21 CFR 820.30), validation of production processes (21 CFR 330 820.70), and corrective and preventive actions (21 CFR 820.100) to ensure both safety and security risks are adequately addressed.”
“FDA recommends that device manufacturers conduct both a safety risk assessment and a separate, accompanying security risk assessment to ensure a more comprehensive identification and management of patient safety risks.”
As part of the risk assessment, FDA recommends threat modeling be performed throughout the design process and be inclusive of all medical device system elements.
The threat model should:
...Cybersecurity risks are difficult to predict, meaning that it is not possible to assessand quantify the likelihood of an incident occurring based on historical data or modeling (alsoknown as a “probabilistic manner”).
FDA recommends that manufacturers assess identified risks according to the level of risk posed from the device and the system in which it operates.
Vulnerabilities identified in Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities Catalog should be designed out of the device, as they are already being exploited and expose the medical device system and users to the risk.
As part of a medical device system, a device may have Cybersecurity considerations
from interoperable functionality, including but not limited to interfaces with:
When common technology and communication protocols are used to enable interoperability (e.g., Bluetooth, Bluetooth Low Energy, network protocols), device manufacturers should assess whether added security controls beneath such communication are needed to ensure the safety and effectiveness of the device (e.g., added security controls beneath Bluetooth Low Energy to protect against risks if vulnerabilities in the Bluetooth Low Energy protocol or supporting technology are discovered).
Device manufacturers should document all software components of a device and address or otherwise mitigate risks associated with these software components.
In addition, under 21 CFR 820.50, a manufacturer must put in place processes and controls to ensure that its suppliers conform to the manufacturer’s requirements.
"...manufacturers should include plans for how third-party software components could be updated or replaced if support ends or other software issues arise in premarket submissions"
A robust SBOM includes both the device manufacturer-developed components and third party components, including purchased/licensed software and open-source software, and the upstream software dependencies that are required/depended upon by proprietary, purchased/licensed, and open-source software.
an SBOM or an equivalent capability should be maintained as part of the device’s configuration management, be regularly updated to reflect any changes to the software in marketed devices, and should support documentation, such as the types detailed in 21 CFR 820.30(j) (Design History File) and 820.181 (Device Master Record).
FDA’s guidance documents “Off-The-Shelf (OTS) Software Use in Medical Devices” and “Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software” describe information that should be provided in premarket submissions for software components for which a manufacturer cannot claim complete control of the software lifecycle. In addition to the information recommended in those guidances, manufacturers should provide machine readable SBOMs consistent with the minimum elements (also referred to as “baseline attributes”) identified in the October 2021 National Telecommunications and Information Administration (NTIA) Multistakeholder Process on Software Component Transparency document “Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM).”
In addition to the minimum elements identified by NTIA, for each software component contained within the SBOM, manufacturers should include in the premarket submission:
As part of the premarket submission, manufacturers should also identify all known vulnerabilities associated with the device and the software components, including those identified in CISA’s Known Exploited Vulnerabilities Catalog.
For components with known vulnerabilities, device manufacturers should provide in premarket submissions:
As a part of ensuring a complete security risk assessment under 21 CFR Part 820.30(g), the assessment for impacts to safety and effectiveness may include an assessment for the potential security impacts of anomalies. The assessment should also include consideration of any present Common Weakness Enumeration (CWE) categories.
FDA recommends that vulnerabilities be assessed for any differing impacts for all fielded versions to ensure patient risks are being accurately assessed.
At a minimum, FDA recommends tracking the following measures and metrics, or those that provide equivalent information:
Averages of the above measures should be provided if multiple vulnerabilities are identified and addressed. These averages may be provided over multiple time frames based on volume or in response to process or procedure changes to increase efficiencies of these measures over time.
A security architecture definition process includes both high-level definitions of the devices and/or systems that interact, and detailed information on the implementations for how those interactions occur and are secured. It contains information that demonstrates that the risks considered during the risk management process are adequately controlled, which, in turn, supports the demonstration of the safety and effectiveness of the medical device system.
FDA recommends that these plans and procedures include design processes, design requirements, and acceptance criteria for the security architecture of the device such that they holistically address the Cybersecurity considerations for the device and the system in which the device operates.
The security architecture should include a consideration of system-level risks, including but not limited to risks related to the supply chain (e.g., to ensure the device remains free of malware, or vulnerabilities inherited from upstream dependencies such as third-party software, among others), design, production, and deployment (i.e., into a connected/networked environment).
If corrective and preventive actions are identified, these views can be used to help identify impacted functionality and solutions that address the risks.
FDA recommends providing, at minimum, the following types of views in premarketsubmissions:
These views should be sufficiently detailed such that engineers and reviewers should be able to logically and easily follow data, code, and commands from any asset (e.g., a manufacturer server) to any other associated asset (e.g., a medical device), while possibly crossing intermediate assets (e.g., application).
This should include detailed diagrams and traces for all communication paths as described below. Security-relevant analysis requires the ability to construct and follow a detailed trace for important communication paths, which describes how data, code, and commands are protected between any two assets in the medical device system.
A precise, detailed list of how each type of credential (e.g., password, key) is generated, stored, configured, transferred, and maintained, including both manufacturer- and healthcare facility-controlled assets (e.g., key management and public key infrastructure (PKI))
Effective Cybersecurity relies upon security being “built in” to a device, and not “bolted on” after the device is designed. FDA recommends that device manufacturers’ design processes include design inputs for Cybersecurity controls.
FDA recommends that an adequate set of security controls should include, but not necessarily be limited to, controls from the following categories:
FDA recommends the requirements and acceptance criteria for each of the above categories beprovided in premarket submissions to demonstrate safety and effectiveness
FDA recommends verification and validation include sufficient testing performed by the manufacturer on the Cybersecurity of the medical device system through which the manufacturer verifies and validates their inputs and outputs, as appropriate.
FDA recommends the following types of testing, among others, be provided in the submissions
A. Security requirements;
B. Threat mitigation;
C. Vulnerability testing;
D. Penetration testing
For all testing, manufacturers should provide their assessment of any findings including rationales for not implementing or deferring any findings to future releases.
For issues that will be addressed in future releases (i.e., remediation deferred for a future software release because current risk was assessed to be acceptable), the premarket submission should contain plans for those releases.
FDA recommends that Cybersecurity testing should occur throughout the SPDF.
FDA also believes that informing users of security information through labeling may be an important part of design and development activities to help mitigate Cybersecurity risks and help ensure the continued safety and effectiveness of the device.
Specific guidance to users regarding supporting infrastructure requirements so that the device can operate as intended (e.g., minimum networking requirements, supported encryption interfaces). Where appropriate, such guidance should include technical instructions to permit secure network deployment and servicing, and instructions for users on how to respond upon detection of a Cybersecurity vulnerability or incident.
A revision-controlled, Manufacturer Disclosure Statement for Medical Device Security (MDS2)66 and Customer Security Documentation as outlined in the Medical Device and Health IT Joint Security Plan (JSP)67 may address a number of the above recommendations.
FDA recommends that manufacturers establish a plan for how they will identify and communicate to users vulnerabilities that are identified after releasing the device in accordance with the 21 CFR 820.100. This plan can also support security risk management processes that are described throughout the QS regulation.
Cybersecurity management plans should include the following elements:
There are generally two types of authentication controls—information and entities—and a properly-secured system is able to prove the existence of both.
A medical device system that appropriately accounts for authenticity can evaluate andensure authenticity for:
Within an adequately designed authorization scheme, the principle of least privileges should be applied to users, system functions, and others, to only allow those entities the levels of system access necessary to perform a specific function.
While authentication schemes based on cryptographically proven designs are generally considered more robust and are therefore preferred, meaningful authorization checks can be performed based on other compelling evidence
When choosing an authentication scheme, manufacturers should keep in mind the following
generally applicable characteristics of different types of schemes:
Cryptographic algorithms and protocols are recommended to be implemented to achieve the secure by design objectives outlined in Section IV. While high-quality, standardizedcryptographic algorithms and protocols are readily available, several commercial products that include cryptographic protections have been shown to have exploitable vulnerabilities due to improper configurations and/or implementations.
Design a system architecture and implement security controls to prevent a situation where the full compromise of any single device can result in the ability to reveal keys for other devices.
Allow installation of cryptographically authenticated firmware and software updates, and do not allow installation where such cryptographic authentication either is absent or fails. Use cryptographically signed updates to help prevent any unauthorized reductions in the level of protection (downgrade or rollback attacks) by ensuring that the new update represents an authorized version change;
Cryptographic authentication schemes verify data integrity, but do not verify data validity. Therefore, the integrity of all incoming data should be verified to ensure that it is not modified in transit or at rest;
Carefully design and review all code that handles the parsing of external data using automated (e.g., static and dynamic analyses) and manual (i.e., code review) methods.
Manufacturers should ensure support for the confidentiality of any/all data whose disclosure could lead to patient harm (e.g., through the unauthorized use of otherwise valid credentials, lack of encryption). Loss of confidentiality of credentials could be used by a threat-actor to effect multi-patient harm. Lack of encryption to protect sensitive information and or data at rest and in transit can expose this information to misuse that can lead to patient harm. For example, confidentiality is required in the handling and storage of cryptographic keys used for authentication because disclosure could lead to unauthorized use/abuse of device functionality.
Event detection and logging are critical capabilities that should be present in a device and the larger system in which it operates in order to ensure that suspected and successful attempts to compromise a medical device may be identified and tracked.
While many of the following recommendations are tailored for workstations, the concepts presented also apply to embedded computing devices.
Implement design features that allow for security compromises and suspected compromise attempts to be detected, recognized, logged, timed, and acted upon duringnormal use.
Ensure the design enables forensic evidence capture.
Devices should be designed to be resilient to possible cyber incident scenarios (also known as“cyber-resiliency”) and maintain availability.
Implement features that protect critical functionality and data, even when the device has been partially compromised.
Devices should be capable of being updated in a secure and timely manner to maintain safety andeffectiveness throughout the product’s lifecycle.
Design devices to anticipate the need for software and firmware patches and updates to address future Cybersecurity vulnerabilities. This will likely necessitate the need foradditional storage space and processing resources.