Vulnerability Analysis of BACnet Protocol Implementations in Networked Fire Indicator Panel Deployments

The Building Automation and Control Networks (BACnet) protocol has become the dominant open standard for integrating fire indicator panels (FIPs) into building management systems across Australian commercial and institutional facilities. However, the protocol's original design prioritised interoperability over security, and the most widely deployed transport binding — BACnet/IP operating over UDP port 47808 — provides no inherent authentication, encryption, or message integrity verification. This paper presents a vulnerability analysis of BACnet protocol implementations across three representative deployment architectures: flat network, VLAN-segmented, and air-gapped configurations. Through controlled laboratory assessment, we demonstrate that an attacker with network access can inject false alarms via WriteProperty services to alarm point objects, execute denial-of-service attacks through Who-Is broadcast storms, and manipulate suppression system binary outputs — all without authentication credentials. While the BACnet Secure Connect (BACnet/SC) addendum introduces TLS 1.3 transport and X.509 certificate-based mutual authentication, our survey of 42 Australian fire system deployments reveals that the overwhelming majority remain on unencrypted BACnet/IP due to hardware limitations in pre-2020 panel firmware. We propose a layered mitigation framework combining network segmentation, deep packet inspection at the OT/IT boundary, and transitional certificate-based authentication for organisations seeking to reduce risk within existing infrastructure constraints.

Fire indicator panels were once standalone devices. A panel sat on a wall in the fire control room, connected to its detectors and sounders by copper loops, and its only interface to the outside world was a set of relay contacts wired to the fire brigade monitoring service. That world has largely disappeared. Modern building management systems (BMS) demand integration — facility managers expect to see fire system status on the same dashboard that displays HVAC setpoints and energy consumption data. The protocol that most commonly enables this integration is BACnet, standardised as ASHRAE 135 and adopted internationally as ISO 16484-5.

The difficulty is that BACnet was designed in the early 1990s for a networking environment that bore little resemblance to today's threat landscape. The protocol assumes a trusted network populated by cooperative devices. Its core services — ReadProperty, WriteProperty, Who-Is, I-Am — operate without authentication. Any device on the network segment can read alarm states, modify setpoints, or impersonate another device by simply sending well-formed BACnet packets. For building automation systems controlling lighting or HVAC, this represents an operational inconvenience. For fire life safety systems, it represents a genuine risk to occupant safety.

This paper grew out of practical work. During a series of network assessments conducted for clients upgrading their BMS platforms, we observed that fire system BACnet traffic was routinely traversing the same network segments as general IT traffic, with no segmentation, filtering, or monitoring. The question that followed was straightforward: what could an attacker actually do with access to that traffic? The analysis presented here attempts to answer that question systematically across the deployment architectures most commonly encountered in Australian commercial buildings.

2.1 Protocol Characteristics and Attack Surface

BACnet/IP operates as an application layer protocol carried over UDP port 47808 (0xBAC0). The transport is inherently connectionless and unauthenticated — there is no handshake, no session establishment, and no mechanism within the base protocol to verify the identity of a sending device. BACnet messages are broadcast or unicast depending on the service: Who-Is discovery requests are typically broadcast to the local subnet, while ReadProperty and WriteProperty requests are directed to specific device addresses. Critically, the receiving device has no means to distinguish a legitimate WriteProperty request from its BMS supervisor from an identical request crafted by an attacker on the same network segment.

We identified three primary attack vectors relevant to fire system deployments. First, unauthenticated ReadProperty and WriteProperty access permits an attacker to read current alarm states, detector analogue values, and system configuration parameters, and to write arbitrary values to writable objects including alarm point objects and binary output objects. Second, Who-Is broadcast spoofing enables device impersonation and network reconnaissance — an attacker can enumerate every BACnet device on the network by issuing a single Who-Is broadcast and collecting I-Am responses. Third, broadcast storm generation through rapid Who-Is flooding can consume device processing resources and degrade panel responsiveness, constituting an effective denial-of-service attack against the fire system network.

2.2 Threat Scenarios

Three threat scenarios were developed to represent realistic attack objectives against networked fire systems. The first involves false alarm injection: an attacker issues a BACnet WriteProperty request targeting an alarm point object (object type 0, instance number corresponding to a specific zone), setting its present value to an alarm state. Depending on the panel's configuration, this could trigger building-wide evacuation, fire brigade dispatch, and associated disruption costs. The second scenario targets availability: a sustained broadcast storm of Who-Is requests at high packet rates forces all BACnet devices on the network to respond with I-Am packets, saturating the panel's processing capacity and potentially causing it to drop legitimate detector communications. The third and most concerning scenario involves suppression system manipulation: an attacker writes to binary output objects controlling gaseous or sprinkler suppression release circuits, potentially causing an unwanted discharge or — more insidiously — inhibiting a legitimate release.

3.1 Flat Network Topology

The flat network topology — in which fire system BACnet devices share a network segment with general IT infrastructure — remains surprisingly common, particularly in smaller commercial buildings and older installations where the BMS was retrofitted without dedicated networking infrastructure. In this configuration, all three attack vectors are fully viable. An attacker who gains access to any device on the corporate LAN, whether through phishing, a compromised workstation, or physical access to a network port, can reach fire system BACnet devices directly. Lateral movement from the IT environment to the operational technology (OT) environment is trivial because there is no boundary to cross. During our assessment programme, we encountered flat network deployments in 17 of 42 surveyed sites — a proportion that, while concerning, is consistent with findings reported by industrial control system security researchers in analogous domains.

3.2 VLAN-Segmented Topology

VLAN segmentation represents the most commonly recommended mitigation and was present in 19 of the 42 surveyed sites. The principle is sound: fire system BACnet traffic is isolated on a dedicated VLAN, and inter-VLAN routing is controlled by firewall rules that restrict which devices and protocols may cross the boundary. In theory, this prevents an attacker on the corporate IT network from reaching BACnet devices on the OT VLAN. In practice, the picture is considerably less tidy. Of the 19 VLAN-segmented sites, we identified inter-VLAN routing misconfigurations in seven — rules that were either overly permissive (allowing all UDP traffic rather than restricting to specific source addresses) or that had been modified during troubleshooting and never reverted. In three cases, the BMS head-end workstation had interfaces on both the IT and OT VLANs, creating a bridging point that bypassed the firewall entirely. VLAN segmentation reduces the attack surface meaningfully, but only when the implementation is rigorous and subject to ongoing audit.

3.3 Air-Gapped Topology

Air-gapped deployments, where the fire system network has no physical or logical connection to the IT network, were present at six sites, predominantly in critical infrastructure facilities. This architecture eliminates network-based attack vectors entirely — an attacker cannot send BACnet packets to devices they cannot reach. However, the air gap comes at a significant operational cost. Fire system data cannot flow to the central BMS, depriving facility managers of integrated monitoring capabilities. Alarm notifications must be handled through separate, parallel pathways. Firmware updates and configuration changes require physical presence at the panel rather than remote deployment. For organisations that have invested in centralised building management platforms, the air-gapped approach is operationally impractical, which explains its limited adoption outside high-security environments.

4.1 BACnet Secure Connect

The ASHRAE 135-2020 standard introduced BACnet Secure Connect (BACnet/SC) through Addendum BJ, representing the first fundamental security enhancement to the protocol since its inception. BACnet/SC replaces the UDP transport with a WebSocket connection over TCP port 443, secured by TLS 1.3. Mutual authentication is achieved through X.509 certificates, and all traffic is encrypted in transit. The architecture employs a hub-and-spoke topology through designated BACnet/SC hubs, eliminating the broadcast-based discovery mechanisms that enable Who-Is enumeration and spoofing attacks. In principle, BACnet/SC addresses every vulnerability identified in our threat model.

The practical obstacle is adoption. BACnet/SC requires TLS processing capability at each device endpoint — a requirement that exceeds the hardware capabilities of most fire indicator panels manufactured before 2020. Of the panels surveyed in our assessment programme, only three supported BACnet/SC, and none had it enabled in production. The installed base of fire panels in Australian buildings has a typical service life of 15–20 years, meaning that the majority of deployed panels will not support BACnet/SC without hardware replacement. This is not a criticism of the standard — BACnet/SC is well designed and its adoption should be encouraged in all new installations. It is simply a recognition that the transition will be measured in decades rather than years, and that interim mitigation strategies are essential.

4.2 Layered Defence Framework

For organisations operating BACnet/IP fire systems that cannot practicably migrate to BACnet/SC, we recommend a layered defence approach. Network segmentation remains the foundation: fire system BACnet traffic should reside on a dedicated VLAN with firewall rules that explicitly whitelist permitted source and destination addresses, restrict protocols to BACnet/IP only, and deny all other inter-VLAN traffic by default. These rules must be subject to periodic audit — our findings demonstrate that configuration drift is the primary failure mode in segmented deployments.

At the OT/IT boundary, deep packet inspection (DPI) capable of parsing BACnet application layer data provides a second line of defence. DPI systems can enforce policies such as blocking WriteProperty requests from unauthorised source addresses, alerting on Who-Is broadcast volumes that exceed normal discovery patterns, and logging all BACnet service requests for forensic analysis. Several industrial firewall products now include BACnet-aware rule sets, though configuration requires familiarity with both the BACnet object model and the specific fire system's point addressing scheme.

Where panel firmware supports it, certificate-based authentication at the application layer — even outside the full BACnet/SC framework — provides meaningful additional protection. Some panel manufacturers have implemented proprietary authentication mechanisms that verify the identity of BMS head-end connections using pre-shared certificates or API keys. These are not standardised and their security properties vary, but they raise the barrier to exploitation above the trivially low threshold presented by unauthenticated BACnet/IP.

The security posture of networked fire indicator panels in Australian buildings is, to put it plainly, poor. The majority of deployments rely on BACnet/IP without authentication, operating on networks where segmentation is either absent or inadequately maintained. The attack vectors are well understood, the tools to exploit them are freely available, and the potential consequences — ranging from nuisance alarm disruption to suppression system manipulation — are serious enough to warrant urgent attention from building owners, fire system integrators, and regulatory bodies.

BACnet Secure Connect offers a technically sound long-term solution, but the reality of the installed base means that unencrypted BACnet/IP will remain the norm for many years. In the interim, organisations should prioritise network segmentation with rigorous access control, deploy BACnet-aware deep packet inspection at the OT/IT boundary, and adopt certificate-based authentication wherever panel firmware permits. Fire system cybersecurity is not a problem that can be deferred until the next panel replacement cycle. The threat landscape has already arrived; the question is whether the industry's defences will catch up before an incident forces the conversation.