IEC 60601-4-5: The standard for IT security, is it also for stand-alone software?

The standard family IEC 60601 is actually only applicable to medical electrical devices. But IEC 60601-4-5 is an exception: This standard for IT security has all medical products in the scope that they are integrated into IT networks. This also affects software as a medical device.

Learn which requirements IEC 60601-4-5 places on manufacturers and operators. This standard gives you concrete instructions on which measures you must implement to improve IT security and on which factors this obligation is dependent.

  Content Overview

Must it be? »

Security Levels »

References to standards »

Conclusion»

With these, the standard will help you to

  • develop safe products,
  • and at the same time, avoid unnecessary expenses and

increase the chances of avoiding problems in licensing your product

1. EC 60601-4-5: Another standard? Must it be?

a) Should you even read the standard?

IEC 60601-4-5 is currently available as a draft. You currently can't buy it. You should read it if you want to know where the standards path is going. If you don't have much time, then don't read it and proceed as follows:

  1. Read this article to get an overview and to be able to talk about it.
  2. Use it in the Guideline for IT security for medical products development and surveillance of the medical devices on the market. The guideline gives you concrete instructions and is used by the notified bodies in a revised form.

If you have a bit more time, jump most of the chapters and just read appendix B of the standard.

Fig. 1: Chapter structure of IEC 60601-4-5 (click to enlarge)

b) Why are other standards insufficient?

There are already many standards on IT security. The standard family IEC 62443 and the IEC 15408 are examples of this. Why do we need extra specific standards for medical products?

Safety versus Security

The first answer is found in the protection goals: In general IT security we differentiate among:

  • (Resource) Availability
  • (System / Data) Integrity
  • (Data) Confidentiality

IEC 62443, which IEC 60601-4-5 extensively references, also includes:

  • Identification and authentication control
  • Restricted data flow
  • Timely response to events

However, these are rather subordinate goals to achieve the first three.

In medical devices, one must also consider safety.

 Caution!

The protection goals of safety and security may also be in conflict with each other, if, for example, rapid access of a person to patient data is required, especially in medical emergencies. This would compromise IT security (confidentiality), but increase safety.

As a member of the IEC 60601 standard family, IEC 60601-4-5 encourages the implementation of safety:

  • Basic Safety
  • Essential Performance
  • Minimum of necessary clinical functionality
  • Availability of the medical device

Prioritization

Contrary to IEC 60601-4-5, many other standards have so-called security levels that will be presented in the next chapter. With these security levels, you can set actions for IT security depending on the “need for protection” and thus save unnecessary expenses.

2. Security Levels – The central concept of IEC 60601-4-5

a) Overview of types of security levels

The standard works with three types of security level (SL):

  1. SL-T: The Target Security Level, that one must achieve for the network including the networked medical devices, to achieve the set protection goal.
  2. SL-C: The Capability Security Level, that can actually achieve for the medical product and the network, if one takes measures to improve IT security.
  3. SL-A: The Achieved Security Level, the level one actually achieves.

For each security level, the IEC 60601-4-5 proposes five levels, from SL 0 (nothing implemented) to SL 4, the highest level. Naturally, high security levels must be achieved for high risks.

Fig. 2: High risks (e.g. due to high degree of damage, high degree of threat or valuable “assets”) require higher security levels

The SL-T must ultimately be determined by the operator or integrator, because only they can decide which network environment a medical device will be used in. A programming device for a heart pacemaker, which would be openly accessible to the internet, requires a higher security level than an anesthesia workplace, in a completely closed network of an operating room.

However, the manufacturer determines the SL-C, that can be achieved if the operator configures and operates the device according to specification. The SL-C depends on which measures the manufacturer has implemented and reviewed.

Which actual security level (SL-A) the operator achieves, depends on multiple factors:

  • Has the operator correctly configured within the network and the network itself?
  • Has the operator implemented measures to increase IT security outside of the device?

For example, "integration tests” determine the actual SL-A achieved, wherein “integration” means the integration of the device into the associated networks.

b) Determination of SL-T

ICE 60601-4-5 recommends individually determining the SL-Ts for these various environments. But not only the network environment should have an influence, but also:

  • Value of the product
  • Amount of damage if the basic security or significant performance features are no longer present
  • Presence of patient data
  • User profile
  • Home network versus hospital network
  • Working surface, e.g. number of devices, number of available ports, number of interfaces
  • Number of the medical products on the market

c)Benefits and use of Security Levels

The security levels help control the requirements of and the expenses of IT security. For this, the standard in appendix B creates a mapping between thee aspects of IEC 62443 and the security levels based on the following example:

requirements

SL1

SL2

SL3

SL4

User authentication

X

X

X

X

Multi-factor authentication at all interfaces

   

X

X

Role-based authorizations

 

X

X

X

Malware protection

X

X

X

X

3. References to other standards

IEC 60601-4-5 normatively refers to IEC 62443-4-2:2019 (Security for industrial automation and control systems – Part 4-2: Technical security requirements for IACS components), also to the IEC 80001-1 family.

It repeats the requirement for the regular protective measures and principles such as “least privilege”, minimization of data, adhering to a software development process and protection through hardware measures (e.g. physical access protection).

The standard only extends a few requirements of IEC 62442-4-2 or slightly modifies them. In addition, it lists specific requirements for support materials.  These range from the determination of the intended user, specifications on the configuration of the product to measures for which the operators and users are responsible.

4. Conclusion

a) Possible critical points

It shouldn't be disputed that we require a standard for IT security specific to medical devices. Even the estimation of IEC 60601-4-5 needs endorsement that the IT security is comprehensively regulated, meaning for both manufacturers and operators.

Whether IEC 60601-4-5 will do this, is up for discussion. Possible critical points are:

  1. Through the references and integration of other standards, IEC 60601-4-5 is hard to read and not clearly transparent.
  2. The standard often appears inconsistent, with regard to the concreteness of the requirements. By reference to IEC 62443, these requirements are sometimes very concrete. Other requirements, such as that a DoS attack should not hinder "safety related” functions, are “high level”, however.
  3. There is a lack of a clear code of conduct, e.g. along the development process, how it does Guidelines for IT Security that. This is also taken into consideration in IEC 62443.
  4. The interplay and cooperation between manufacturers and operators is insufficiently addressed in IEC 60601-4-5, and above all via references to the IEC 80001-1 family. There are (nearly) no Post-Market Surveillance requirements for this. This is alarming considering the requirements of the MDR.

b) Scope?

It would also be nice if the standards would have made the scope clearer:

  • “ME Equipment” is in the title. Thus it would not be applicable to stand-alone software.
  • In the preamble, it states: “This document provides IT security specifications for medical devices connectable to medical IT-networks as network components, including medical software applications.“ Does “including medical software applications“ apply to “network components“ or to “medical devices“?
  • The "scope” states “This document provides detailed technical recommendations for security features of medical devices used in medical IT-networks […]“. So there is no longer talk of “ME Equipment”.

Conclusion: IEC 60601-4-5 is usable for software as a medical device.

c) What is nice

That IEC 60601-4-5 does not reinvent the wheel, but references existing standards, above all IEC 62443, is commendable.

Also helpful is the approach of determining various protection goals and the security levels (SL-T, SL-C and SL-A). This enables us to prioritize measures in medical products and in the network.

It is exactly this focus that is necessary: Because an increasing amount of standards and requirements does not lead to (IT) security, but only to an overtaxing of all of those involved.