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.
With these, the standard will help you to
increase the chances of avoiding problems in licensing your product
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:
If you have a bit more time, jump most of the chapters and just read appendix B of the standard.
b) Why are other standards insufficient?
Safety versus Security
The first answer is found in the protection goals: In general IT security we differentiate among:
IEC 62443, which IEC 60601-4-5 extensively references, also includes:
However, these are rather subordinate goals to achieve the first three.
In medical devices, one must also consider safety.
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:
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.
a) Overview of types of security levels
The standard works with three types of security level (SL):
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.
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:
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:
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:
Multi-factor authentication at all interfaces
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.
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:
It would also be nice if the standards would have made the scope clearer:
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.