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.
This article is about medical devices,
The following situations can be distinguished:
Standards and guidelines also distinguish the above situations conceptually:
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.
The IMDRF document N70 defines devices with software whose conformity with the current requirements could not be demonstrated (situation 3) as "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.
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.
“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.
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.
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
If the grandfathering is dropped, many manufacturers could be forced to withdraw the devices from the market.
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.
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.
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:
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.
Manufacturers must comply with the statutory and normative requirements. The special requirements for "end-of-life products" are presented in the next chapter.
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.
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.
The risk management standard obliges manufacturers to carry out "activities in the production and post-production phase." This also includes the review of whether
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.
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:
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.
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
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:
The document thus appears to be a useful addition to IEC 81001-5-1, which only lists the manufacturer's tasks in Annex F.
The regulatory requirements are sufficiently clear, and manufacturers know what needs to be done. The Johner Institute can provide support for many measures:
creating a culture in the company that anchors IT security in the minds of all employees
build up and maintain staff qualifications in the area of 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
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)
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.
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.