Christian Rosenzweig

IT security for “legacy devices”


Understandably, laws and standards also require IT security for “legacy devices." However, the way in which these requirements are formulated often leads to confusion.

For example, legislators and standard committees have been unable to agree on common definitions. One definition refers to the IT security of legacy devices, another to the IT security of old or existing devices, and another to the IT security of software in transition.

The IT security requirements for medical devices that contain software or are software are also not coordinated.

This article explains the situation and provides medical device manufacturers, notified bodies, and operators with an overview.

1. IT security - which devices are affected?

a) Context

This article is about medical devices,

The following situations can be distinguished:

  1. Conformity with current requirements has been demonstrated.
    The manufacturer has already determined and demonstrated compliance with the current IT security requirements.
  2. Conformity with current requirements has NOT yet been demonstrated.
    The manufacturer has developed the devices in compliance with the "old legislation." He has not yet demonstrated conformity with new regulatory requirements, e.g., because these are unknown or because resources are lacking.
  3. Conformity with current requirements cannot be demonstrated.
    The manufacturer has determined that it cannot achieve and, therefore, cannot demonstrate compliance with current regulatory requirements, for example, because
  • included software components (SOUP/OTS) are discontinued or no longer maintained by third-party providers,
  • the manufacturer at the time no longer exists, or
  • the design or technology of the device is so outdated that it is no longer possible to implement IT security measures.

b) Definitions of terms

Standards and guidelines also distinguish the above situations conceptually:

Transitional Health Software

IEC 81001-5-1 describes the software for situation 2 devices as "Transitional Health Software."


“HEALTH SOFTWARE, which was released prior to publication of this document, and which does not meet all requirements specified in Clause 4 through Clause 9 of this document.”

However, this definition does not exclude the software in situation 3. This is because it does not distinguish whether the requirements are not or not yet fulfilled.

Legacy Device

The IMDRF document N70 defines devices with software whose conformity with the current requirements could not be demonstrated (situation 3) as "Legacy Devices."

Definition “Legacy Devices“

“medical devices that cannot be reasonably protected against current cybersecurity threats”

This definition refers to "legacy" only in the context of "cybersecurity.” In its document, the IMDRF only addresses "cybersecurity threats" that have an impact on patient safety. A negative impact solely on security, for example, is not within the scope of the document.

Further information

General requirements for legacy devices are listed in our article "What manufacturers need to know about legacy devices."

Unfortunately, the definition of the term "Legacy Device" in the IMDRF does not match the definition in IEC 62304.

Definition “Legacy Software“

“MEDICAL DEVICE SOFTWARE which was legally placed on the market and is still marketed today but for which there is insufficient objective evidence that it was developed in compliance with the current version of this standard.”

IEC 62304:2015, Chapter 3.36

This definition (in contrast to the IMDRF definition) does not distinguish whether IT security and, thus, compliance can be restored (see also Fig. 1). It also does not consider the age of the device. However, IEC 62304 assumes that the device will continue to be marketed.

Note: IEC 62304 and legacy devices

With the introduction of IEC 62304, discussions arose about whether the standard had to be automatically applied to legacy devices on the market. An amendment or the second edition of the standard provided clarity:

A corresponding normative paragraph required risk-based specific activities. Not all standard requirements have to be met retrospectively in all cases. However, no general "grandfathering" exists for legacy devices.

This article uses the term "legacy device" as an umbrella term for all situations in which the IT security of medical devices that were placed on the market before the current regulatory requirements came into force has not been demonstrated or has not yet been demonstrated.

c) Question and its relevance

The question now arises as to how legacy devices must be treated with regard to IT security, namely for situations 2 and 3 above (conformity with current requirements has not yet been demonstrated or cannot be demonstrated). The question is:

Is there "grandfathering," i.e., unrestricted continued use of the devices on the market for existing devices in the sense of "transitional health software" or "legacy devices"?

The answer to this question is crucial. It is often no longer (economically) possible to update the software of very old devices because

  • the technologies used no longer exist or have not been updated (programming environments, libraries),
  • an update would no longer run on the old hardware,
  • no mechanisms for simple (remote) maintenance were provided during development,
  • the operators are not prepared to pay for this software maintenance.

If the grandfathering is dropped, many manufacturers could be forced to withdraw the devices from the market.

2. No general grandfathering for existing devices

The answer to the question posed above is clear:

In the context of IT security, there is no general grandfathering of "legacy devices"!

The economic consequences for manufacturers and even the threat of poorer patient care are not arguments for dispensing with the IT security of legacy devices.

Note for operators

There is a regulatory requirement for manufacturers to continuously analyze and ensure the IT security of the devices they have already placed on the market. However, this does not mean that operators are prohibited from continuing to use such devices.

For example, an operator cannot decommission the programming device of a pacemaker, even if the manufacturer discontinued it years ago. This is because the operator must continue to supply the patients who use the pacemakers programmed with it.

Conversely, the MITRE requirements allow manufacturers to transfer tasks relating to "IT security for legacy devices" to the operators. More on this below.

a) Reason 1: Specificity of IT security risks

The motivation for sufficient IT security measures lies in the threat posed by cyberattacks.

There are several reasons why the requirements for IT security are (or at least appear to be) particularly high:

  1. high risks due to malicious misuse
    Vulnerabilities in IT security are associated with high risks: The devices can come under the full control of attackers who, for example, import manipulated device software and access other devices in the same network or collected patient data in very large quantities.
  2. high speed of misuse relativizes the benefit of PMS data
    Assessing the current "resilience" of devices to cyberattacks based on post-market data is difficult. In the very fast-moving cyber world, attack vectors, attack tools and attackers' capabilities are constantly changing. It must be expected that attacks - if they have not yet taken place - are only a matter of time.

It, therefore, does not make sense to certify "legacy devices" as having sufficient IT security simply because there is no information to the contrary. Rather, "security by design" must be continuously improved, and corresponding IT security activities must be implemented in the device's life cycle.

b) Reason 2: Regulatory requirements

Manufacturers must comply with the statutory and normative requirements. The special requirements for "end-of-life products" are presented in the next chapter.

3. Regulatory requirements for the IT security of "legacy devices"


In the general safety and performance requirements in their respective Annex I, the MDR and IVDR determine that medical devices must have IT security under the state of the art.

As with all essential requirements, they do not distinguish between legacy and non-legacy devices. However, they do require manufacturers to provide operators with specifications in the context of IT security.

b) IEC 62304

IEC 62304 requires conformity with all normative requirements to be reviewed, and thus, also the requirements for the IT security of legacy devices.

Chapter 4.4 of the standard requires manufacturers to analyze the risks and carry out a gap analysis. Depending on these outputs, the activities prescribed by the standard for "new devices" must be carried out.

The standard does NOT differentiate whether these requirements are related to IT security or not.

c) ISO 14971

The risk management standard obliges manufacturers to carry out "activities in the production and post-production phase." This also includes the review of whether

  • new hazards (and thus new risks) are present, and
  • the general state of the art is still fulfilled.

This means that it must be continuously analyzed whether all IT security-related risks are known and controlled according to the state of the art.

d) IEC 81001-5-1

IEC 81001-5-1 is more specific to IT security for legacy devices, and the normative Annex F on "Transitional Health Software" is particularly relevant. This type of software is not to be equated with "legacy software" in the sense of IEC 62304.

Annex F obliges manufacturers to:

  • conducting a gap analysis with the requirements of the standard
  • developing a plan to bring the software into a compliant state
  • post-market activities in accordance with the standard


IEC 81001-5-1 wants manufacturers to achieve conformity with its requirements (over time). The standard does not allow a general statement that the risks are controlled.

e) IMDRF guidelines

The IMDRF has published two guidelines on cybersecurity:

The scope of the second document is legacy software as defined by the IMDRF (“medical devices that cannot be reasonably protected against current cybersecurity threats”).

As the most important tasks of the manufacturer, the second guideline requires

  • from development:
    • to take into account third-party software and its support duration by providers
    • to develop devices as securely as possible in order to be able to guarantee IT security for a long period of time
  • from support:
    • to continue to monitor and communicate vulnerabilities and risks
    • to clearly communicate the planned and actual end of support to operators, including for third-party software

f) MITRE guidelines

The MITRE document shows ways to improve the cybersecurity of these devices. It sees itself as a supplement to the IMDRF document and picks up on its Total Product Lifecycle Process (TPLC).

As "security by design" is difficult to achieve retrospectively, the measures are shifted more to the operator. The interaction between the operator and manufacturer and their respective tasks are elaborated in the document and translated into eight specific recommendations:

  1. Pilot data collection to support decision making for legacy device risk management
  2. Develop information sharing agreement templates to increase transparency
  3. Establish security architecture working group
  4. Develop research program in modular design for medical devices
  5. Conduct study on vulnerability management coordination
  6. Development of competency models for roles related to legacy cyber risk
  7. Identify resources for workforce development
  8. Participation in mutual aid partnerships. The aspect of shared responsibilities and tasks in the medical device ecosystem is, therefore, at the forefront and corresponds to the complexity of legacy challenges.

The document thus appears to be a useful addition to IEC 81001-5-1, which only lists the manufacturer's tasks in Annex F.

4. Necessary measures by manufacturers

The regulatory requirements are sufficiently clear, and manufacturers know what needs to be done. The Johner Institute can provide support for many measures:


necessary measure

possible support

creating a culture in the company that anchors IT security in the minds of all employees

in-house trainings

build up and maintain staff qualifications in the area of IT security

seminar on IT security

video training at the Medical Device University

catch up on "security by design" by working through Annex F of IEC 81001-5-1 for all "legacy devices" on the market

workshop to create the plan required by IEC 81001-5-1

support in the definition, review and documentation of IT security measures

for new devices, ensure that they have already been sufficiently developed according to the state of the art and continuously adapt them to the state of the art in the post-market phase

workshop to create the plans required by IEC 62304 and IEC 81001-5-1

adaptation of the standard operating procedures in the QMS

support in the definition, review and documentation of IT security measures

create transparency for the point at which a device loses its "IT secure" status and thus becomes a legacy device (to this end, search for previously unknown vulnerabilities in devices and systems with regular penetration tests at the current state of the art level.)

communicate this status change to operators at an early stage (end of support)

analysis of whether IT security corresponds to the state of the art

carry out penetration tests

work with operators to operate legacy devices with maximum IT security (e.g., through measures taken by the operator, by switching off functions and components)

risk analyses


Tab. 1: The Johner Institute can help with many of the tasks that manufacturers have to perform in the context of IT security for legacy devices.

5. Summary and conclusion

The "fire-and-forget" approach is not possible with medical devices. Standards and laws oblige manufacturers to assess the risks posed by their devices over their entire life cycle and to ensure the safety of their devices. This applies, in particular, to cybersecurity.

In many cases, manufacturers are faced with a decision: in order to manage these risks, they can stop marketing the devices or achieve cybersecurity by redesigning the devices.

The obligation to revise is not limited to devices that the manufacturer continues to market. It can also apply to devices that have already been placed on the market.

MITRE gives manufacturers the opportunity to manage cybersecurity risks together with operators. IEC 81001-5-1 does not describe this approach. It is, therefore, helpful to use both documents together.


The Johner Institute will be happy to help you with any questions about your legacy medical devices. You can find out how this works in a free expert consultation.

Find out what Johner Institute can do for you

A quick overview: Our


Learn More Pfeil_weiß

Always up to date: Our


Learn More Pfeil_grau

Privacy settings

We use cookies on our website. Some of them are essential, while others help us improve this website and your experience.