Team82 explores the LonTalk networking protocol which is often optimized for control applications within building management and automation systems. We will examine the protocol’s fundamentals and trace its evolution from serial communication to IP-based deployments.
The LonTalk networking protocol, developed in the early 1990s, was once a popular staple in device-to-device communication, especially for building automation and building management systems (BAS and BMS). Today in many implementations, it has been replaced by BACnet, a more modern and secure open standard that enables communication between smart building assets manufactured by a diverse set of vendors. LonTalk, however, still exists deep under the covers of many proprietary BMS implementations.
As with any proprietary deployment of protocols such as LonTalk, there may be undocumented security issues that could pose a risk to organizations. Those risks are especially worrisome as more and more BMS are being connected to IP networks, and managed on the network and via the cloud. Organizations will have to contend with a new host of vulnerabilities and configurations being introduced as a side effect of this connectivity.
Therefore, despite its age, LonTalk should not be underestimated as an attack vector for hacktivists and criminal entities, especially as BMS is enabled over IP networks. LonTalk is certainly still relevant to BMS cybersecurity discussions, especially as BMS finds its way online for a number of strategic and bottom-line reasons. Commercial real estate, retail, hospitality, and data center sectors rely on BMS systems such as HVAC (heating, ventilation, and air conditioning), lighting, energy management and security. Previously, these systems were operated independently by facility management, but they are now increasingly connected and integrated through advanced BMS and BAS capabilities.
BMS and BAS can also be linked to other smart, connected sensors and devices within a facility. These systems generate analytics data that can be reviewed to monitor energy consumption trends and meet certain regulatory standards around environmental controls and sustainability. Some organizations are realizing not only efficiency improvements, especially across multiple sites, but are also able to tweak processes in order to cut utility costs and other hits against the bottom line.
Any disruption to these essential services because of a security issue in a decades-old legacy protocol is unacceptable, and is driving Team82’s current research initiative around LonTalk and BMS security weaknesses overall. In this blog, we will examine the LonTalk protocol and provide an overview of its versatility, use cases, and the security implications of its transition from serial connectivity to the IP layer.
Developed by the Echelon Corp., of Massachusetts, LonTalk is standardized as CEA-709, also known as ISO/IEC 14908 which enables devices to communicate over CEA-709 networks. LonTalk’s introduction provided a vendor-neutral solution for building automation systems at a time when these systems were proprietary, isolated, and communicated over serial connections.
Many legacy LonTalk systems, including sensors and controllers, rely on dedicated integrated circuits called Neuron Chips to implement the physical, network, and application layers of the LonTalk protocol in hardware. The chip combines three local processors (applications, network management, and packet I/O), an architecture that enables LonWorks devices to communicate, process control logic, and handle network services independently, without relying on external microcontrollers. As Echelon’s company lineage changed several times through acquisitions, the Neuron Chip line was officially declared end-of-life in 2025, marking the end of dedicated LonTalk silicon.
LonTalk functionality continues, however, through EnOcean software stacks and network interface products. Modern systems may integrate legacy LonWorks networks into contemporary IoT and edge architectures. EnOcean manages tools for Lon functionality, as well as the interface hardware connecting LonTalk devices to IoT and edge infrastructures. LonMark, meanwhile, maintains the LonTalk and LonWorks standards, including SNVT management, device certification, and interoperability guidelines.
The LonTalk protocol is versatile, capable of operating over multiple physical topologies using media such as twisted pair wiring, power lines, and radio frequency. Later implementations standardized LonTalk over IP through the CEA-852 standard.
Beyond data exchange, LonTalk provides network management and diagnostic services, enabling integrators to commission devices, assign addresses, monitor node status, and clear error logs directly through the protocol.
Here is an example of LonTalk CEA-709 network diagnostic and management packet type codes:
The screenshot above shows an example of LonTalk network diagnostics, network management, and router configuration packet type codes, as defined in the LtNetworkManagerLit.h file from EnOcean’s official LonTalk Stack SDK repository on GitHub.
Together, these features make LonTalk not just a communication protocol, but a comprehensive framework for maintaining and controlling complex automation networks.
Further details on the legacy LonTalk protocol, its implementation, supported network topologies, and practical applications, can be found in the LonTalk Protocol Specification published by Echelon.
A typical use case might involve coordinating Heating, Ventilation, and Air Conditioning (HVAC) controllers, lighting dimmers, and occupancy sensors from different manufacturers on a single LonWorks network without custom integration. Thanks to its wide adoption and long lifespan, LonTalk remains common in existing infrastructures where full system replacement is costly. Today, it continues to bridge legacy installations with modern IP-based BMS solutions, ensuring continuity and smooth migration to newer standards.
In a LonTalk network, devices exchange information using Network Variables (NVs), which are shared data points representing values such as temperature, fan speed, occupancy and more. There are two types of NVs:
NVO (Network Variable Output): used to send or publish data to the network.
NVI (Network Variable Input): used to receive or subscribe to data from the network.
Each NV is based on a Standard Network Variable Type (SNVT), a predefined data type that ensures consistent interpretation of values across devices from different manufacturers (the full list of SNVTs is available in the official LonMark SNVT Master List).
In the image above, we can see a simple example where the current temperature is sent from the HVAC controller to the BMS server, while the new temperature setpoint, controlled by the BMS, is sent back to the HVAC system.
The following table illustrates how Network Variables (NVs) are used to exchange data between an HVAC controller and a BMS server in a LonTalk network.
Step | Device | NV Name | Direction | SNVT Type | Description |
1 | HVAC | nvoRoomTemp | Output (NVO) | SNVT_temp_p | Current room temperature in °C (for example, 22.5°C). |
BMS server | nvoRoomTemp | Input | |||
2 | HVAC | nviSetpoint | Input | SNVT_temp_p | Desired temperature setpoint in °C from the BMS (for example, 25°C). |
BMS server | nvoSetpoint | Output |
The HVAC device publishes the current room temperature using the network variable nvoRoomTemp, which is defined as SNVT_temp_p (a standard temperature type in °C). The BMS server subscribes to this variable through its nviRoomTemp input to monitor the actual room temperature, for instance, 22.5°C.
Conversely, the BMS server sends the desired temperature setpoint using nvoSetpoint, also of type SNVT_temp_p, while the HVAC controller receives it via nviSetpoint. This allows the HVAC to adjust its operation to match the target temperature, for example 25.0°C.
The transition of LonTalk-over-IP (operating over both TCP and UDP) significantly improves flexibility and interoperability, it also introduces new security considerations. Exposing LonTalk over IP expands the attack surface and introduces common IP-network risks, including unauthorized access, traffic manipulation, and remote exploitation in the absence of proper security controls.
The transition of the legacy LonTalk protocol to the IP layer has significant implications for its applicability. By removing the dependency on the proprietary Neuron chip, LonTalk can now be implemented more flexibly and deployed across a broader range of platforms. Beyond replicating the core features of the original protocol, the IP-based standard introduces enhanced capabilities such as device registration and configuration, channel and membership management, and channel statistics monitoring.
In addition, the specification defines vendor-specific packet types that extend control and configuration beyond the baseline CEA-852 standard. These privileged commands enable authorized users to manage gateway devices, which often support multiple protocols and whose configuration may influence the entire BMS network. The following sections provide a deeper look at CEA-852 proprietary packet types, exploring how vulnerabilities can be exploited and examining general implementation drawbacks.
Exploring these extended capabilities and management paths, as well as identifying potential bypasses and vulnerabilities, is both technically valuable and strategically important.
To make LonTalk more accessible to developers, EnOcean has released an official GitHub repository containing the LonTalk protocol stack source code for both client and server implementations of the IP-852 standard (explained in detail in the Exploring the CEA-852 Standard section). These sources are compiled into the core libraries that manage LonTalk communication within EnOcean’s i.LON and SmartServer product lines, following EnOcean’s acquisition of Echelon’s product line.
When conducting a quick search for Internet-accessible LonTalk devices using the CENSYS service, we identified a significant number of exposed controllers, both EnOcean (formerly Echelon) and Loytec devices, that are directly connected to the Internet. Further analysis revealed that many of these devices expose the CEA-852 LonTalk-over-IP service on its default ports (1628 and 1629). In addition, a large portion of these controllers either rely on default MD5 keys when signature-based protection is enabled or do not implement any security mechanisms at all.
Moving LonTalk to the IP layer with CEA-852 makes BMS networks more flexible and easier to integrate, but also opens new security risks through vendor-specific commands. In future reports, we’ll take a closer look at real-world EnOcean and Loytec gateway controllers, examining how these packets operate and uncovering potential weak spots in CEA-852 implementations within modern BMS deployments.
Vulnerability Researcher
Amir Zaltzman is a vulnerability researcher on Team82.
This vulnerability allows remote attackers to execute arbitrary code on affected installations of ALGO 8180 IP Audio Alerter devices. Authentication is required to exploit this vulnerability.
The specific flaw exists within the web-based user interface. The issue results from the lack of proper validation of a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of the device.
Given the nature of the vulnerability, the only salient mitigation strategy is to restrict interaction with the product.
CVSS v3: 7.2
This vulnerability allows remote attackers to execute arbitrary code on affected installations of ALGO 8180 IP Audio Alerter devices. Authentication is required to exploit this vulnerability.
The specific flaw exists within the web-based user interface. The issue results from the lack of proper validation of a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of the device.
Given the nature of the vulnerability, the only salient mitigation strategy is to restrict interaction with the product.
CVSS v3: 7.2
This vulnerability allows remote attackers to execute arbitrary code on affected installations of ALGO 8180 IP Audio Alerter devices. Authentication is required to exploit this vulnerability.
The specific flaw exists within the web-based user interface. The issue results from the lack of proper validation of a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of the device.
Given the nature of the vulnerability, the only salient mitigation strategy is to restrict interaction with the product.
CVSS v3: 7.2
This vulnerability allows remote attackers to execute arbitrary code on affected installations of ALGO 8180 IP Audio Alerter devices. Authentication is required to exploit this vulnerability.
The specific flaw exists within the web-based user interface. The issue results from the lack of proper validation of a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of the device.
Given the nature of the vulnerability, the only salient mitigation strategy is to restrict interaction with the product.
CVSS v3: 7.2
This vulnerability allows remote attackers to execute arbitrary code on affected installations of ALGO 8180 IP Audio Alerter devices. Authentication is required to exploit this vulnerability.
The specific flaw exists within the web-based user interface. The issue results from the lack of proper validation of a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of the device.
Given the nature of the vulnerability, the only salient mitigation strategy is to restrict interaction with the product.
CVSS v3: 7.2
