The International Medical Device Regulators Forum (IMDRF) recently published several cybersecurity-related guidances, one of which offers insights into the management of legacy device cybersecurity. One of the essential elements of this guidance is that the end-of-life/end-of-service (EOL/EOS) declaration for a software or firmware component can precipitate the same state for the medical device manufacturer’s (MDM’s) product, a problem that must be dealt with in advance to ensure that the MDM is not forced to prematurely withdraw its medical device.
Among the cybersecurity-related guidances released by the IMDRF is a guidance on the use of a software bill of material (SBOM), which we described here. The legacy cybersecurity guidance proposes four stages of the total product life cycle (TPLC) for cybersecurity purposes, along with several standards for the first of these four stages. These are:
- The development stage (for example, see IEC 62443-3-2 for cybersecurity risk assessment);
- The support stage, during which devices receive full cybersecurity support from the MDM;
- The limited support stage, during which the MDM provides mitigations for firmware and software components that are no longer supported by the developer of those components; and
- The end-of-service stage, during which MDM mitigations are unavailable for firmware and software components that are no longer supported by the developer of those components.
The IMDRF guidance recommends the MDM perform a patient safety risk assessment when a component reaches EOL/EOS for a device in the support or limited support stage. If the MDM concludes there is no effect on patient safety, that device can remain in its current life cycle stage. The MDM should advise healthcare providers (HCPs) of the status of any component that has reached EOL/EOS.
Swift Action May be Required to Avoid Device EOS
However, the IMDRF guidance states that the device itself may have to be transitioned to EOS if a component reaches EOL/EOS when the device is in the limited support stage and the associated risks cannot be reasonably mitigated. If the risks can be reasonably mitigated, the MDM can retain the device in the limited support stage, but the customer/user should be advised of the MDM’s determination in either scenario.
The picture is somewhat more complicated for a device in the support stage and there are identified patient safety risks. Ideally, the MDM will either provide an update for the component or undertake a design change to replace the function of the unsupported component. The device may then remain in the support stage when using a supported replacement component, assuming the device can be reasonably protected.
However, the MDM should use an unsupported component to replace the EOL/EOS component only as a last resort. This may force a shift of the device from the support stage to the limited support stage, even if this new unsupported component adequately mitigates the risk associated with EOL/EOS component. An MDM that is forced to resort to this kind of solution should make public notification of the change, including to regulatory agencies. In any event, the software/firmware component’s expected EOS date should be included in the updated SBOM to aid in TPLC risk management.
Non-Device Firewall of Limited Value
IMDRF provides three sections for each of the four stages of the cybersecurity TPLC, which are communication, risk management, and transfer of responsibility (see chart below). In the development stage, risk management requires that security be designed to be sustainable throughout the expected product life cycle, although the section of the guidance on risk management during the support stage acknowledges that compensating controls offer some measure of relief for a component’s emergent vulnerability.
The example given in the guidance is the use of a network firewall that could reduce the chances that a new vulnerability for a network port on the medical device will fall prey to an exploit. IMDRF recommends, however, that the MDM remain mindful that reliance on a network firewall – or segmentation of the network in which the device operates – to address such shortcomings carries its own potential problems.
| Development Stage | Support Stage | Limited Support Stage | EOS/EOL Stage | |
| Communications | Feedback from HCPs should be made systematic | MDM should provide security disclosures, SBOM | Advise HCPs and public of a shift to limited support | Provide HCPs with information for sustained security |
| Risk Management | Baseline, other controls should extend through TPLC | Manage third-party risks, conduct adverse event reporting | HCPs begin to consider relative risks, benefits of replacing legacy device/system | MDM’s post-market surveillance responsibilities may still apply |
| Transfer of Responsibility | N/A | MDM advises HCPs of transfer of responsibility 2-3 years prior to onset of limited support stage | Ensure all HCP software is updated, advise HCPs of potential network security options | Transfer of responsibility complete: Device may be decommissioned/replaced |
HCPs will have several things to think about when considering risk management for a device that has reached the limited support stage, such as the risk to patients when the device is compromised, and when the organization’s IT system is compromised. The MDM’s responsibilities to HCPs diminish somewhat in the limited support stage, although news of a breach that originates with a medical device at any stage is not just bad news for HCPs: It also reflects poorly on the MDM, regardless of which party to the transaction is at fault.
HCPs are ultimately responsible for the cybersecurity of a device when the MDM has formally notified the customer of the EOS status of the device. It is important to bear in mind, however, that a manufacturer’s post-market surveillance responsibilities continue to apply even when the device is no longer manufactured, as a recent FDA warning letter confirms.
Every Device Becomes a Legacy Device
Each new medical device will eventually become a legacy device, and thus is it vital to adopt a forward-looking stance with regard to cybersecurity TPLC management, particularly in an age in which artificial intelligence is fast becoming the cyberthreat tool of choice for many bad actors. The threat to medical devices is vastly greater than it was 10 years ago, and significantly elevated from even 1 year ago.
The terms of this new IMDRF guidance may not be compulsory for device manufacturers and developers of software as a medical device (SaMD), but this guidance reinforces the notion that an ounce of prevention is worth much more than a pound of cure. It’s important to take cybersecurity for legacy devices seriously, and this new IMDRF guidance provides a well-crafted method for doing precisely that.
