LIS2 Communication and Stability Issues

Our internal cybersecurity expert Gwen contributed the following.

The Use of LIS2 In Medical Devices

LIS2-A2 is widely used in laboratory devices as a standard practice for Healthcare Delivery Organizations (HDOs). The LIS and LIS2 communication protocol standards published nearly two decades ago have often been used in medical device network systems due to their clarity regarding data transfer. This lack of complexity has led to the unverified assumption that employing LIS2 lowers vulnerability for a medical device to be attacked [5]. However, the LIS2 communication protocol is vulnerable to multiple forms of cybersecurity attack, requiring security measures to be put in to place to lower the risk for the medical device.

Potential Cybersecurity Issues Presented by LIS2

A growing concern is that LIS-A2 communication does not support encryption or authentication. Since these devices have become increasingly interconnected in recent years, a successful attack may have devastating consequences on many or all interconnected systems. Increased cybersecurity attacks in 2020 such as ransomware and IT targeting have sparked new interest in the medical community regarding the safety of LIS-A2 and its use. The prospect of an attacker tampering with test results is a primary concern due to the potentially direct effect on patient health. For example, a malicious attacker could modify test results within blood analysis or other laboratory equipment [5].

  • Other specific vulnerabilities regarding LIS2 communication protocols include [1,2]
  • 19 Theoretical vulnerabilities published from Homeland Security
  • TCP/IP flood/interception
  • IP issues resulting in DOS, tampering, etc.
  • Theft of data/property using raw attributes obtained, such as device MAC address

An attacker sweeping a LIS2 network may obtain a MAC address or other raw attributes with ease. If look-up tables are employed from a Device Profile Library, an attacker would need only the vendor name, OS fingerprints, and the function of the system to identify and exploit classified attributes of a system of networked devices [1].

A further potential vulnerability exists in the configuration of an LIS2 enabled device: the underlying embedded operating system. In an analysis in 2020, Dupont et al studied a sample set of two million HDO networked devices and discovered that approximately 41% of these devices were running Windows embedded underneath. Many devices were found to be using unsupported, outdated operating systems. Keeping an operating system up to date may be a potential security measure against LIS2 attacks, as this would avoid the use of vulnerable legacy drivers. Additionally, the study noted that networked services commonly employed in these devices included SMB, RDP, SSH, Telnet, and FTP [5].

One issue here is that if a device has been made vulnerable by its communication protocol, its underlying OS may lead to larger data breaches and more complex attacks. Using Server Message Block (SMB) protocol as an example, an extra threat is imminent for any device that has an underlying embedded operating system such as Windows. File sharing and remote access using Windows are common practices in medical laboratory devices. Attackers have taken advantage of SMB vulnerabilities by means of ransomware or exploiting known vulnerabilities.

Furthermore, these network services have many of their own vulnerabilities, both theoretical and actual. Using port-forwarding may be one potential security measure, as the networked services found by Dupont et al in their study identified solely by the proprietary port number, such as port 22 and 23 for SSH and Telnet, respectively. If an SSH service is seen to be on port 22, it becomes solely a brute-force target which may be logged into remotely.

A final reason for an elevated risk of attack is that Telnet, like other common protocols previously mentioned, does not support encryption for network sessions [1]. This allows information to be read easily when intercepted directly in transit, without the need for fancy encryption methods. A suggestion for avoiding this scenario is to use strong cryptographic protocols within high level transfers in an LIS2 network (i.e., HTTPS or FTPS) [5]. Another security measure is to ensure certificates are only issued by whitelisted issuers, and SSL/TLS certificates are not permitted to expire.

While one might be tempted to instead “hide” these ports from view, this security through obscurity holds elevated risk in a large group of networked systems. This is because if all devices are scanned and compared, an attacker may discover these open ports by noting that they are missing in all devices [2]. One alternative proposal for enhancing security within these networked devices is to break these systems into smaller segments by use of Virtual Local Area Networks (VLANs), something the data shows is currently in use in less than 20% of HDOs [1].

In summary, the LIS2 communication protocol commonly used in medical laboratory devices is vulnerable to several forms of cybersecurity attack. Employing the suggested security measures described within this article during device design and implementation may lower the risk of occurrence for these vulnerabilities.



[1] Dupont et al. A Matter of Life and Death: Analyzing the Security of Healthcare Networks. IFIPSec 2020.

[2] HIMSS. 2020 vision: A review of major IT and cybersecurity issues affecting healthcare. HIMSS Global Health Conference. 2020.

[3] Markey, B., Berry, D. (2010). A quiet success story in the laboratory: survey of 30 implementations of the ASTM 1394 standard for analyser interfaces. 15th Annual Conference of the Health Informatics Society of Ireland, Stillorgan Dublin, November. doi:10.21427/ D7RC97.

[4] Marko Hölbl, Kai Rannenberg, and Tatjana WelzerICT. Systems Security and Privacy Protection: 35th IFIP TC 11 International. Reproduced with permission, from NCCLS publication LIS2-A2—Specification for Transferring Information Between Clinical Laboratory Instruments and Information Systems; Approved Standard—Second Edition (ISBN 1-56238-550-X). Copies of the current edition may be obtained from NCCLS, 940 West Valley Road, Suite 1400, Wayne, Pennsylvania 19087-1898, USA.

[5] NCCLS. Specification for Transferring Information Between Clinical Laboratory Instruments and Information Systems; Approved Standard—Second Edition. NCCLS document LIS2-A2 [ISBN 1-56238- 550-X]. NCCLS, 940 West Valley Road, Suite 1400, Wayne, Pennsylvania 19087-1898 USA, 2004.

[6] Parl, Hyung, and Heo. Design and Realization of Integrated Management System for Data Interoperability between Point-of-Care Testing Equipment and Hospital Information System. Healthc Inform Res. Healthcare Informatics Research. 2013 Sep; 19(3): 222–228.


Other cybersecurity posts: Customer Facing Cybersecurity DocumentationThe FDA’s Role in Medical Device CybersecurityCybersecurity vulnerabilities in medical devices: a complex environment and multifaceted problem

About the author

Amy enjoys researching and writing about developments in medical technology and how that intersects with US law. She received her J.D. from the University of Florida Levin College of Law in 2020 and now works as a Regulatory Associate for SoftwareCPR®, a general-purpose regulatory consulting firm that is recognized globally for their expertise with standards and national regulations pertaining to medical device, mobile medical app, and HealthIT software.

SoftwareCPR Training Courses:

IEC 62304 and other emerging standards for Medical Device and HealthIT Software

Our flagship course for preparing regulatory, quality, engineering, operations, and others for the activities and documentation expected for IEC 62304 conformance and for FDA expectations. The goal is to educate on the intent and purpose so that the participants are able to make informed decisions in the future.  Focus is not simply what the standard says, but what is meant and discuss examples and approaches one might implement to comply.  Special deep discount pricing available to FDA attendees and other regulators.

3-days onsite with group exercises, quizzes, examples, Q&A.

Instructor: Brian Pate

Next public offering:  June 5-7, 2024
Boston, MA

Email to request a special pre-registration discount.  Limited number of pre-registration coupons.

Registration Link:

Register Now



Being Agile & Yet Compliant (Public or Private)

Our SoftwareCPR unique approach to incorporating agile and lean engineering to your medical device software process training course is now open for scheduling!

  • Agile principles that align well with medical
  • Backlog management
  • Agile risk management
  • Incremental and iterative software development lifecycle management
  •  Frequent release management
  • And more!

2-days onsite (4 days virtual) with group exercises, quizzes, examples, Q&A.

Instructors: Mike Russell, Ron Baerg

Next public offering: February 12-15, 2024

Virtual via Zoom

Registration Link:

Register Now



Medical Device Cybersecurity (Public or Private)

This course takes a deep dive into the US FDA expectations for cybersecurity activities in the product development process with central focus on the cybersecurity risk analysis process. Overall approach will be tied to relevant standards and FDA guidance documentation. The course will follow the ISO 14971:2019 framework for overall structure but utilize IEC 62304, IEC 81001-5-1, and AAMI TIR57 for specific details regarding cybersecurity planning, risk characterization, threat modeling, and control strategies.

2-days onsite with group exercises, quizzes, examples, Q&A.

Instructor: Dr Peter Rech, 2nd instructor (optional)

Next public offering:  TBD

Corporate Office

15148 Springview St.
Tampa, FL 33624
Partners located in the US (CA, FL, MA, MN, TX) and Canada.