Legacy devices strike a delicate balance between being essential while also being highly vulnerable in today’s healthcare ecosystem. The International Medical Device Regulators Forum (IMDRF) has produced a new standard – Principles and Practices for the Cybersecurity of Legacy Medical Devices (N70) – to help device makers navigate the complexity of identifying and securing legacy devices.

Modern design processes typically incorporate due consideration for cybersecurity measures, however, legacy devices – some exceeding the manufacturers’ intended useful life – are incapable of providing reasonable protection from current cybersecurity threats.

This gap in continued use versus limited security capabilities has fueled a surge in vulnerable systems, increasingly targeted in recent years, that urgently need compensating security measures to ensure both patient safety and effectiveness. The IMDRF’s roadmap aims to guide Medical Device Manufacturers (MDMs), Health Care Providers (HCPs) and other stakeholders in fortifying these legacy devices.

The ensuing sections will shed light on pragmatic approaches to utilizing the best practices advocated for in this guidance to improve the security posture of health systems reliant on large populations of legacy devices.

What does ‘legacy’ mean, as defined by the IMDRF? 

In the medical device industry, the term ‘legacy device’ often leads to varying interpretations and can result in potential misunderstandings. In most regulatory contexts, a legacy device is one that has been approved under regulations set before a significant milestone date. In the realm of cybersecurity, however, the approval timeline is less relevant. Here, the focus shifts to the technical capabilities of the device, specifically whether the device can either defend against today’s threats or be updated to do so.

Medical Device Regulation (MDR) / In Vitro Device Regulation (IVDR) interpretation

As an example, in the context of MDR/IVDR regulations, legacy devices are those placed on the market after the MDR’s Date of Application (DoA), as of 26 May 2021. These are devices that hold valid EC certificates under previous directives like the Active Implantable Medical Devices Directive 90/385/EEC (AIMDD) or the Medical Device Directive 93/42/EEC (MDD).

Under the definition of the IMDRF Guidance on cybersecurity

In contrast, according to the IMDRF, the term legacy is used to denote “medical devices that cannot be reasonably protected against current cybersecurity threats.” This status could include both older and newer devices that have security limitations. If a device gets the right protection or added capability to handle efficient updates, it can be reclassified from a legacy device that is vulnerable to threats.

What are the IMDRF general principles for cybersecurity? 

Navigating the complex landscape of legacy medical device cybersecurity is no small feat. The IMDRF guidelines offer more than just operational advice; they provide valuable insights into the regulatory mindset and the expected trajectory for industry standards.

This framework comprises three cornerstone aspects – The Total Product Life Cycle (TPLC) Framework, Communication and Shared Risk Management – each formulated not just to enhance your cybersecurity posture, but to align it closely with current and future regulatory expectations.

TPLC Framework

  • Cybersecurity risks should be considered throughout a device’s life, from Development to End of Support (EOS).
  • EOS marks the transfer of cybersecurity responsibility to the HCP.
  • If used beyond EOS, clinical life may extend, with decommissioning occurring later.
  • A planned cybersecurity life cycle should include Development, Support, Limited Support, and EOS stages.


  • Open communication between stakeholders is essential for effective protection.
  • MDMs should plan for End of Life (EOL) and EOS, allowing users to prepare by obtaining necessary information for device maintenance.
  • This information helps the HCP decide whether to decommission the device or assume additional responsibility for its security.

Shared Risk Management

  • MDMs must design devices to optimize cybersecurity during support and minimize risk after EOS.
  • HCPs need to collaborate with MDMs to ensure appropriate safeguards, maintain them and plan for EOS.
  • Devices without MDM support are likely to become vulnerable, and HCPs should consider upgrading to supported models.

Understanding these principles is crucial; they reflect regulatory expectations and set the stage for future compliance. Now that we have discussed the core principles laid out by the IMDRF, let us venture deeper into one of its essential components: the TCLP Framework.

How can you apply the TPLC framework to legacy devices? 

This framework allows for comprehensive risk management, from development to EOS, addressing each stage’s unique considerations.


Stage 1: Development 

Stage 2: Support 

  • Defined as devices that are used for patient care, available on the market and contain supported major software or hardware components (e.g., CPU).
  • Full cybersecurity support, including patches and updates, should be provided.
  • Key practices include vulnerability identification through a Coordinated Vulnerability Disclosure process (CVD) and additional services (e.g., security monitoring) as needed.

Stage 3: Limited support 

  • Defined as devices used for patient care, declared EOL by the MDM, not currently marketed or containing unsupported software/hardware components whose risks are mitigated.
  • MDMs should continue cybersecurity support where possible, communicating to users any limitations and threats that may appear unmitigated and necessary security protections to be implemented by HCPs.
  • Stage 2 practices should continue where reasonably achievable.

Stage 4: EOS 

  • Defined as devices in use for patient care, declared EOS by the MDM, not currently marketed, or containing unsupported software/hardware components whose risks are not mitigated.
  • MDMs should notify users that they can no longer assure support before entering Stage 4, identifying potential inherited risks, mitigation strategies and upgrade opportunities.

How do you identify and mitigate risk factors throughout the device’s lifecycle? 

When a single device component becomes EOL/EOS, MDMs need to perform a risk assessment with the goal of determining whether patient safety risks can arise. To enhance the understanding of the IMDRF TPLC framework, we have added the following visual detailing the practical implementation of the framework, particularly concerning the transition between different life cycle stages.


What are the key considerations when implementing the framework?

  • Trigger event: If a component becomes EOL/EOS, it triggers the MDM to conduct a risk assessment to ascertain whether patient safety risks emerge.
  • Applicability: This framework is particularly relevant for unforeseen third-party component EOL/EOS declarations.
  • Device maintenance plan: Generally, the level of software support for device maintenance is clearly defined in the device maintenance plan, guiding actions in response to an EOL/EOS event.

As you make your way through the device’s life cycle, this decision tree serves as a vital tool to help navigate the complexities around trigger events and transitions. Under the context of the IMDRF N70 guidance, it should stand as a useful tool to implement compliance for legacy devices.

Can you tailor the IMDRF guidance to meet your unique needs? 

The IMDRF has provided a comprehensive set of principles and practices aimed at boosting the cybersecurity of legacy medical devices. This framework underscores the idea that all involved parties share the responsibility for device security. It also offers concrete steps for enhancing security measures via a TPLC approach.

As we move forward, adopting renewable security measures will be crucial for ensuring long-term protection against emerging threats. For specialized guidance tailored to your unique requirements, we offer personalized consultations.


Cybersecurity meets MedTech: Unveiling our new podcast ‘Cybersecurity Talks’