Building management systems are rapidly becoming a high-risk entry point into critical infrastructure networks as organizations connect previously isolated systems to IP-based environments. Research from Claroty’s Team82 highlights that the shift to standards such as CEA-852, which enables protocols like LonTalk to operate over IP, expands flexibility but also significantly increases the attack surface, exposing systems to risks such as unauthorized access, traffic manipulation, and remote exploitation when security controls are weak or absent.
In its ‘The Risky Road Bringing Building Management Systems Online: Exploring the CEA-852 Standard’ research, Claroty’s findings reinforce broader exposure trends across smart buildings, where insecure connectivity and legacy design weaknesses converge to create systemic cybersecurity gaps. At scale, these risks are already widespread, with three-quarters of organizations running building management systems affected by known exploited vulnerabilities and more than half exposing vulnerable systems to the internet, often linked to ransomware activity.
As these systems increasingly control essential functions such as HVAC (Heating, Ventilation, and Air Conditioning), energy, and physical security, their compromise could enable attackers to disrupt operations or pivot deeper into enterprise and critical infrastructure environments.
In February, Claroty Team82 warned of growing cybersecurity risks in legacy LonTalk protocols across BMS deployments. As the legacy LonTalk protocol moves from serial connections to IP networks through the CEA-852 standard, BMS installations gain flexibility and interoperability but also face increased cybersecurity risk. Exposing these systems over IP expands the attack surface, making them more vulnerable to unauthorized access, traffic manipulation, and remote exploitation if security controls are inadequate.
“During our research into LonTalk’s IP implementation we discovered serious vulnerabilities and design weaknesses that create remote attack vectors capable of compromising BMS gateway/server devices exposed to the Internet,” Amir Zaltzman, Claroty’s senior vulnerability researcher, wrote in the Wednesday post. “This is not only a LonTalk problem: once an attacker compromises a gateway (in our tests we demonstrated this on EnOcean and Loytec devices), they can manipulate the entire building-management ecosystem. Because these servers bridge and host multiple protocols and device types (BACnet, Modbus, HTTP, etc.), a single compromise can impact critical systems and sensors across the network.”
CEA-852 can be implemented in three variants defined by the protocol code in the CNIP header, including IP-852, RNI, and LPA. While all three share the same header structure, they differ in packet types, payload formats, and the HMAC signing algorithm used. RNI and LPA are largely similar, with only minor differences in accessible payload data and identical packet types and HMAC methods. IP-852, however, stands apart with distinct packet types and a different HMAC approach.
IP-852 packets, identified by protocol code 0x01, are split into two categories based on the vendor code in the CNIP header. Standard packet types, marked by a vendor code of 0x00, are vendor-neutral and must be consistently supported across implementations, handling functions such as encapsulating LonTalk data, querying device information, and monitoring channel health.
In addition to the standard IP-852 packets, vendors often implement proprietary packet types to support advanced, device-specific features. These packets are enabled when the vendor code field is set to a unique, vendor-assigned value. For example, the code is 0x01 for Echelon and 0x02 for Loytec. This allows for extended capabilities in device control and monitoring, such as enabling NAT, initiating a remote reboot, toggling web server access, and uploading firmware updates.
Both standard and proprietary IP-852 packet types can include a 16-byte HMAC signature and use the same HMAC algorithm, based on MD5 and a 16-byte pre-shared key, to ensure packet authenticity. In IP-852, the pre-shared key is manually configured on both endpoints and cannot be transmitted or changed dynamically over the network. When HMAC protection is enabled, the fifth bit of the protocol flags byte is set to 1.
RNI (Remote Network Interface) packets implement CEA-852 and use protocol code 0x03, while LPA or LSPA (LonTalk Protocol Analyzer, also known as LonScanner Protocol Analyzer) packets use protocol code 0x04. The underlying packet types are identical across both, with differences emerging only in how responses are handled.
Identifying these packet types requires working from compiled libraries used in EnOcean products, since no public source code exists for RNI and LPA. This contrasts with EnOcean’s open-source GitHub SDK for IP-852 client and server implementations. The analysis centers on the relevant binaries, libRNI[dot]so for RNI and libLSPA[dot]so for LPA, along with the standard packet types shared across devices supporting these implementations under vendor code 0x00.
At the core of the parsing logic is a switch-case structure that processes incoming packets and maps them to their respective RNI or LPA types. One of the clearest examples is packet type 0x00, which corresponds to KEEP_ALIVE. Incoming packets are first passed through a verification routine that checks the sequence number, CNIP header integrity, and HMAC signature to ensure validity.
The post identified that the KEEP_ALIVE handler then enforces payload constraints, specifically rejecting zero-length payloads and logging them as null packet responses. Two valid variants emerge based on the first byte of the payload. A value of 0x00 represents a simple periodic keep-alive without acknowledgment, while 0x01 indicates a keep-alive with acknowledgment, which triggers a timer on the server side until the next acknowledged message is received. Any other value is treated as malformed, signaling an invalid or potentially manipulated packet.
Zaltzman said that the authenticity mechanism relies on verifying a received message using a 16-byte HMAC signature. “The HMAC computation differs slightly between the IP-852 and RNI/LPA implementations, but both are primarily based on a 16-byte pre-shared key and the MD5 algorithm. Having uncovered the HMAC algorithm for both implementations, a single captured packet suffices to perform an offline brute-force search for the 16-byte pre-shared key.”
He added that “In case of RNI/LPA, the Neuron ID (UID) of the destination device is needed for computation of the HMAC. Fortunately, in RNI/LPA, the default response packet to an unrecognized message is of the IDENT packet type.”
“It is worth noting that many devices exposed online lack proper protection: numerous IP-852 endpoints have HMAC authentication disabled, and many RNI/LPA devices are signed with the default 16-byte all-zero pre-shared key,” according to Zaltzman. “In practice, this makes it trivial for an attacker to craft valid CEA-852 messages.”
However, the HMAC may be recovered offline by brute force from a single captured packet, without requiring any active interaction with the target device.
Zaltzman said that analyzing the undocumented Loytec-specific packet types (vendor code 0x02) revealed several important findings. “We identified packet features that can impact Loytec controllers, enabling an attacker to disrupt device operation through denial-of-service conditions. Moreover, we found a way to bypass internal security mechanisms, allowing modification of critical core device configurations.”
He added that Loytec has implemented a simple proprietary IP-852 reboot command (packet type 0x90) that triggers a controller restart. This message can be easily exploited to cause an arbitrary denial-of-service, without any additional authentication requirements beyond the previously discussed HMAC mechanism.
