Smart Medical Device Cyber Risk Management | Medical Aegis

The Continuing Challenge of Defending against Malicious Actors, Balancing Risk and Business Priorities, and Addressing Regulatory Requirements

Smart medical device cybersecurity professional fights off threats while confused about regulations

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:

  • state any assumptions about the system or environment of use (e.g., hospital networks are inherently hostile, therefore manufacturers are recommended to assume that an adversary controls the network with the ability to alter, drop, and replay packets); and
  • capture cybersecurity risks introduced through the supply chain, manufacturing, deployment, interoperation with other devices, maintenance/update activities, and decommission activities that might otherwise be overlooked in a traditional safety risk assessment.
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:

  • Class I – Non-sterile or no measuring function (low risk)
  • Class I – Sterile and a measuring function (low/medium risk)
  • Class IIa (medium risk)
  • Class IIb (medium/high risk)
  • Class III (high risk)

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:

  • Security feature testing
  • Fuzz testing
  • Vulnerability scanning
  • Penetration testing
  • Secure code analysis

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:

  • Independence and technical expertise of testers
  • Fuzz testing
  • Scope of testing
  • Duration of testing
  • Testing methods employed
  • Test results, findings, and observations
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:

  • Device instructions and product specifications related to recommended cybersecurity controls appropriate for the intended use environment (e.g., anti-malware software, use of a firewall, password requirements).
  • Sufficiently detailed diagrams for users that allow recommended cybersecurity controls to be implemented.
  • Specific guidance to users regarding supporting infrastructure requirements so that the device can operate as intended (e.g., minimum networking requirements, supported encryption interfaces).
  • A description of systematic procedures for users to download version-identifiable manufacturer-authorized software and firmware.
  • A description of how the design enables the device to respond when anomalous conditions are detected (i.e., security events).
  • • A high-level description of the device features that protect critical functionality (e.g., backup mode, disabling ports/communications, etc.).
  • Including a description of backup and restore features and procedures to restore authenticated configurations.
  • A description of the methods for retention and recovery of device configuration by an authenticated authorized user.
  • 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.
Software Validation and Verification

Both the EU MDR and the FDA regulations cover details including:

  • General Requirements
  • Validation and Verification Planning
  • Traceability
  • Documentation
  • Test Methods and Acceptance Criteria
  • Test Results
  • Revalidation and Reverification
  • Software Changes
Incident Reporting
FDA Report (Upon Awareness) FDA Timeline EU MDR Report (Upon Awareness) EU MDR Timeline
Manufacturers must report individual adverse events that include reportable death, serious injury, or malfunction Within 30 calendar days Manufacturers must report serious incidents which has led to a death, or a serious deterioration in someone’s health Within 10 calendar days
Manufacturers must report individual adverse events that require remedial action to prevent an unreasonable risk of substantial harm to public health or one in which the FDA made a written request Within 5 calendar days Manufacturers must report incidents which implies a serious threat to public health Within 2 calendar days
N/A N/A Manufacturers must report any serious incident Within 15 calendar days
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.