With the new Consolidated Appropriations Act approved in December 2022 outlining the requirements for Medical Device Cybersecurity, the FDA’s Draft Guidance released in April of 2022, the FDA RTA released in March of this year, and the updates made to the EU MDR it can be confusing to figure out how and where to address Medical Device Cybersecurity. Add to that the continuing challenge of the ever-changing security issues that already exist and it becomes overwhelming.
Following is a comparison between the FDA draft guidance “Cyber Security in Medical Devices: Quality System Considerations and Content of Premarket Submissions” and the EU Medical Device Regulation (MDR) content with a focus on cyber security and aspects of applied technology. This is not meant to be comprehensive, it’s an overview that should motivate someone needing more information to look at the full documentation provided by the referenced regulatory bodies. The focus of this comparison is the content of the EU MDR and the FDA draft guidance. There are many supporting resources such as the MDCG “Guidance on Cybersecurity for medical devices” and AAMI TIR57 “Principles for medical device security – risk management” that can / should be leveraged when determining what to do with a smart medical device to ensure you’re meeting regulatory guidelines.
| Aspects | EU MDR and FDA Comparison | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Connected Devices or “Smart” Devices | The EU MDR defines an “active device” as any device that depends on a source of energy other than that generate by a human body and further a “system” as a combination of products, either packaged together or not, which are intended to be inter-connected or combined to achieve a specific medical purpose. The FDA considers devices that contain software including firmware and Software as a Medical Device (SaMD) to be “smart” devices and does not limit the definition to just being network-enabled or devices with connected capabilities. |
||||||||||||||||
| Risk Analysis and Management | The EU MDR follows ISO 14971 and takes it a step further adding that it; requires risks to be reduced As Far As Possible (AFAP) whereas ISO allows three acceptable approaches: ALARP (As Low As Reasonably Practicable), ALARA (As Low As Reasonably Achievable) or AFAP (As Far As Possible) The FDA recommends following a Secure Product Development Framework (SPDF) that may include a NIST CSF framework-based risk assessment since it focuses on cyber security risks. The FDA also recommends following ISO 14971 to assess device safety and risk management. |
||||||||||||||||
| Threat Modeling | The EU MDR does not specifically require manufacturers to conduct threat modeling. However, it does require manufacturers to identify and analyze the risks associated with their devices, including cybersecurity risks, as part of the risk management process which implies evaluating threats. The FDA references specific activities related to threat modeling including:
|
||||||||||||||||
| Device Classification | The EU MDR has four device categories and five risk-based classifications which work together to classify a device. The categories are: non-invasive devices, invasive medical devices, active medical devices, and special categories. The risk classifications are:
Like the FDA, the risk classification assigned will determine the depth and amount of data required under MDR to get the approval of the medical device. The FDA’s classification system is based upon device risk with three classes of risk: Class I (low risk), Class II (moderate risk) and Class III (high risk). Class III devices require the PMA pathway, along with a substantial amount of data beyond Class I and II that validates and demonstrates the risk-benefit of the device. Currently there are not unique cyber security requirements for the different classes. |
||||||||||||||||
| Device Identification | The EU MDR states that each component that’s considered to be a device and is commercially available must have a distinct UDI. It also states that a UDI must be assigned at the system level of software and only software which is commercially available on its own or that is a device itself will be subject to this requirement in which case the UDI shall be displayed on a readily accessible screen. The FDA requires a UDI for every version or model of a device. The UDI must be readable to humans as well as in the “AutoID” format. This includes SaMD which must display the UDI each time the SaMD is started. |
||||||||||||||||
| Security Architecture |
The EU MDR does not have specific security architecture requirements, but it does require that manufacturers establish and maintain a quality management system (QMS) that includes the application of risk management principles, which includes security considerations. The MDR emphasizes a risk-based approach to device design and manufacturing, which should include consideration of security architecture aspects as part of the overall risk management plan. The FDA describes a “Call-Flow Diagram” and refers to security architecture as “a system architecture, defining the system and all end-to-end connections into and/or out of the system.” It also mentions architecture requirements under Title 21 CFR 820.30 (Design Controls) specific to all device classes that are automated or use software. |
||||||||||||||||
| Cybersecurity Testing and Documentation |
Both the EU MDR and FDA require cybersecurity testing and documentation with specifics that include:
The FDA specifies details to outline what type of testing and documentation should be included in premarket submissions. Penetration test reports should be provided and include the following elements:
|
||||||||||||||||
| Cybersecurity Transparency |
The EU MDR requires that medical device manufacturers disclose to users: The minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorized access, necessary to run the software as intended. The FDA goes into a lot of detail in this area and recommends but is not limited to:
|
||||||||||||||||
| Software Validation and Verification |
Both the EU MDR and the FDA regulations cover details including:
|
||||||||||||||||
| Incident Reporting |
|
||||||||||||||||
| Vulnerability Management |
The EU MDR with its focus on risk management mandates that all manufacturers have a documented risk management plan that will identify and analyze known and foreseeable hazards with a plan in place for mitigation. The FDA recommends the same as the MDR to be executed throughout the entire Total Product Life Cycle (TPLC) and includes a vulnerability communication plan to communicate and address vulnerabilities to users after launch. |
||||||||||||||||
| Software Bill of Materials (SBOM) |
The EU MDR does not specifically mention SBOMs or BOMs. It does detail requirements related to the procedures for monitoring and verifying the design of the products, including the corresponding documentation, and in particular; a general description of the product, including any variants planned, and its intended use(s), the design specifications, including the standards which will be applied and the results of the risk analysis. The FDA discusses an SBOM as critical to address vulnerability management in smart devices. They must be created in accordance with an industry accepted format to effectively manage assets, to understand the potential impact of identified vulnerabilities to the device (and the connected systems), and to deploy countermeasures to maintain the device’s safety and effectiveness. Manufacturers should provide or make available SBOM information to users on a continuous basis. |