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,

• that have already been placed on the market,
• that contain software or are standalone software, and
• where there may be risks due to a lack of IT security.

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 he 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.”

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.”

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 data security, for example, is not within the scope of the document.

Unfortunately, the definition of the term “legacy device” in the IMDRF does not match the definition in IEC 62304.

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.

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.

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 legal 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

a) MDR/IVDR

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

e) IMDRF guidelines

The IMDRF has published two guidelines on cybersecurity:

• IMDRF WG/N60 FINAL2020 Principles and Practices for Medical Device Cybersecurity
• IMDRF WG/N70 FINAL:2023 Principles and Practices for the Cybersecurity of Legacy Medical Devices

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

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.