Anyone who manages a BACnet network across more than a handful of buildings knows the feeling: adding a new building should not be this difficult. Discovery breaks, broadcast traffic spikes, and the network configuration that worked reliably for ten buildings begins to fall apart at thirty. By the time a campus grows to dozens of subnets and thousands of devices, operators find themselves spending more time managing the network infrastructure than the building systems it was designed to serve.
When things go wrong, BACnet Broadcast Management Devices are usually the first place people look, and for good reason. Misconfigured Broadcast Distribution Tables, duplicate BBMDs on the same subnet, and stale BDT entries are real and common sources of network failure. These are legitimate problems that cause real outages. However, even on a campus where every BBMD is configured perfectly and every BDT is current, the broadcast discovery model that BBMDs serve still does not scale. The problems that operators experience at scale are not caused solely by misconfiguration. They are an inherent consequence of how BACnet discovers devices, and that distinction matters as the industry considers what comes next.
BACnet device discovery is broadcast-based by design. When a device needs to locate another device, it sends a Who-Is message, and every matching device responds with an I-Am. On a single subnet, this is efficient and elegant. Broadcast messages stay within the local broadcast domain, every device on the subnet hears the request, and the appropriate device responds. No additional infrastructure is required.
The challenge arises when discovery needs to cross subnet boundaries. Standard IP routers do not forward broadcast traffic, which means that a Who-Is sent on one subnet will never reach devices on another. This is not a flaw in IP networking; it is a fundamental design principle. In the IT world, broadcast containment within VLANs and subnets is considered a best practice because it prevents broadcast traffic from consuming bandwidth across the entire network. The BACnet protocol, however, relies on broadcast for discovery, and that creates a tension between how IP networks are designed to operate and how BACnet needs them to behave.
BBMDs were introduced to resolve this tension. A BBMD on each subnet maintains a Broadcast Distribution Table containing the addresses of BBMDs on other subnets. When a broadcast message arrives, the BBMD converts it to a directed message and forwards it to each address in its BDT, where the receiving BBMD rebroadcasts it locally. This effectively punches broadcast traffic through the subnet boundaries that IP networking was designed to enforce.
For small deployments, this approach can work. For a campus with dozens of subnets, the consequences become significant. Every discovery request is forwarded to every BBMD in every BDT, and rebroadcast on every subnet, meaning that every device on the entire campus network must receive and process every discovery request. When that single request is multiplied by every device issuing periodic discovery, every front-end polling for status, and every misconfigured controller sending global Who-Is messages on a timer, the result is the broadcast flooding problem that large campus operators know all too well. Furthermore, filtering mechanisms above layer 2 (VLAN) provide no benefit; all devices that receive broadcast frames must process them, regardless of UDP port, BACnet network number or otherwise.
There is an accelerating shift in the industry that is compounding this problem, and it deserves more attention than it is getting. Across campuses worldwide, serial-based MSTP controllers are reaching end of life and being replaced with BACnet/IP devices. On many large campuses, IP-based controllers still represent a small fraction of the total device population, with the majority of controllers still sitting behind BACnet routers on MSTP trunks. That ratio is changing rapidly.
What makes this relevant to the broadcast scalability conversation is that MSTP devices behind a BACnet router are naturally contained. The serial trunk is its own broadcast domain. A Who-Is on the MSTP side travels down the physical wire and is bounded by the limits of that trunk. The BACnet router forwards discovery messages between the MSTP network and the IP network, but the MSTP devices themselves are shielded from the full volume of IP-side broadcast traffic.
When those same devices are replaced with BACnet/IP controllers on a flat IP subnet, that natural containment disappears. Each new IP device becomes a full participant in the broadcast domain, generating and receiving discovery traffic from every other subnet via BBMD forwarding. A campus that is currently ten percent IP-based and managing its broadcast traffic may find the situation fundamentally different at fifty percent, and unworkable at full IP adoption, unless the underlying discovery architecture changes.
There are workarounds available today. BACnet routers, protocol gateways, and point servers can all be used to segment broadcast traffic and provide a degree of containment. However, each of these approaches introduces its own complexity, including additional points of failure, latency in device communication, ongoing configuration overhead, and limitations on direct device-to-device accessibility. The goal for the industry should be proper broadcast containment with direct IP accessibility to every device on the network, because that is what modern IP infrastructure was designed to deliver and what campus operators ultimately need for scalability, performance, and simplified management. Everything short of that is a compromise.
BACnet Secure Connect is an important advancement for the industry. It delivers TLS 1.3 encryption, X.509 certificate-based device authentication, and eliminates the need for static IP addresses and inbound firewall rules. For cybersecurity and IT department integration, it addresses real and pressing concerns. It also eliminates BBMDs entirely within the SC fabric, removing the operational burden of maintaining and synchronizing BDTs across subnets.
However, there is a growing misconception that eliminating BBMDs also eliminates the broadcast scalability problem, and this is not the case. BACnet/SC replaces the BBMD forwarding model with a hub-and-spoke topology. Every SC node connects to a central hub, and when a broadcast-class message such as a Who-Is arrives at the hub, the hub forwards it to every enrolled node. The hub does not cache discovery results, maintain a device registry, or filter broadcast messages. It is a relay. The delivery mechanism has changed from UDP broadcast forwarding to directed WebSocket connections, but the underlying discovery model remains broadcast-based. Every device on the network still receives and must process every discovery request, just as it did with BBMDs.
The ASHRAE IT Working Group’s whitepaper on BACnet/SC lists the design objectives as encryption, elimination of static IP addresses, elimination of BBMDs, and firewall compatibility. Broadcast traffic reduction is not among them. This is not a criticism. BACnet/SC was designed to solve the cybersecurity problem, and it does that well. It was not designed to solve the broadcast scalability problem, and the industry should not expect it to.
For campuses with large legacy BACnet/IP installations, the path to BACnet/SC runs through years of hybrid deployments where SC-to-IP routers bridge legacy devices into the SC fabric. In those hybrid environments, legacy broadcast traffic enters the SC network and is distributed to all SC nodes, combining the broadcast burden of both architectures. The scalability problem does not disappear during migration. It follows.
If broadcast-based discovery is the root of the scalability problem, then the industry needs to reframe the question. The goal is not to eliminate broadcast messages from BACnet entirely, as that would require changing the protocol specification itself. Broadcast-based discovery within a local subnet is efficient, well understood, and works exactly as intended. The goal is to contain those broadcasts where they belong—within their local broadcast domain—and resolve cross-subnet discovery without forwarding broadcast traffic across the entire campus.
The IT world solved an analogous problem decades ago with ARP, the Address Resolution Protocol. When a device on an IP network needs to find the MAC address of another device on the same subnet, it sends an ARP broadcast. That broadcast is contained within the local subnet by design; Layer 2 frames do not cross subnet boundaries, and no one would consider forwarding ARP broadcasts campus-wide to resolve addresses on remote subnets. Instead, IP routing handles cross-subnet communication through an entirely different mechanism that does not rely on broadcast at all.
BACnet discovery does not have an equivalent. When a device needs to find another device on a remote subnet, the only mechanism available is to forward the broadcast, via BBMD or SC hub, until it reaches every subnet or enrolled device on the network. The question the industry should be asking is: what if cross-subnet discovery could be resolved without forwarding the broadcast at all? What if a device could locate any other device on the campus while its discovery traffic never left the local subnet?
That is the question we set out to answer at Humber Horizons, and the result is a platform called BACsync (patent pending). BACsync replaces the broadcast forwarding model with a fundamentally different approach to cross-subnet discovery. Discovery requests are resolved locally, within the broadcast domain where they originate, without any broadcast traffic crossing subnet boundaries. The full technical architecture is beyond the scope of this article, but the practical implications at campus scale are significant.
Because BACsync operates at the discovery layer rather than the transport layer, it is agnostic to the underlying communication protocol. It works with BACnet/IP, MSTP, and BACnet/SC infrastructure, because the transport mechanism that carries BACnet messages between devices is largely irrelevant to how those devices are discovered in the first place. This also positions BACsync to address the hub scalability limitations that BACnet/SC introduces, by providing a distributed alternative to the centralized hub-and-spoke model.
| BBMDs | Secure Connect | BACsync | |
|---|---|---|---|
| Discovery model | Broadcast forwarded to all BBMDs in the BDT, rebroadcast on each subnet | Broadcast forwarded by hub to all enrolled nodes | Resolved locally within the broadcast domain |
| Adding a building | Every BDT on the campus must be updated | Hub accepts new node connections; may require additional hubs at capacity | Self-discovers and integrates automatically |
| Transport compatibility | BACnet/IP only; MSTP devices accessed via BACnet routers | BACnet/SC nodes only; legacy devices require SC-to-IP routers | BACnet/IP, MSTP, and BACnet/SC |
| Changes to existing devices | None, but every BBMD must be manually configured and maintained | Requires SC-capable firmware and X.509 certificates on each device | None required |
| Campus-wide device visibility | None natively; requires separate diagnostic tools | Hub has awareness of connected nodes only | Built into the platform |
| Failure impact | Single BBMD failure affects only that subnet’s cross-subnet communication | Hub failure affects all connected nodes (mitigated by optional failover hub) | Agent failure affects only the local subnet |
It is worth acknowledging that BACnet is not the only protocol in the building automation conversation today. MQTT, REST APIs, and other IoT-oriented protocols are increasingly discussed as alternatives or supplements to traditional BAS communication. Some of these protocols offer elegant solutions for specific use cases, particularly around cloud connectivity and data analytics.
However, the reality on the ground is that BACnet has enormous momentum in the HVAC and building automation industry, supported by three decades of adoption, a vast installed base, and deep familiarity among the integrators and facilities teams who maintain these systems every day. On large campuses, there are thousands of BACnet devices already deployed that represent millions of dollars of investment and cannot simply be replaced. Any practical solution to the broadcast scalability problem must work within those constraints, supporting the infrastructure that exists today while providing a path forward as campuses grow and modernize.
That is the position BACsync was designed to occupy. It does not ask campus operators to abandon BACnet, wait for a full protocol migration, or replace the devices already in the ground. It works with the network as it exists and solves the scalability problem that becomes more pressing with every building, every subnet, and every MSTP trunk that is retired in favour of IP.
None of the above is intended as an argument against BACnet/SC, which addresses a real and important cybersecurity gap, or against the diagnostic platforms that help operators identify and resolve network issues. Both serve essential roles in a well-managed campus network.
The argument is that the broadcast scalability problem is a distinct challenge that neither cybersecurity protocols nor diagnostic tools were designed to address. As more serial devices are retired and replaced with IP controllers, and as campuses continue to grow, this problem will only intensify. The BACnet community has done remarkable work over three decades, and the next chapter is not about replacing what has been built. It is about solving the one challenge that the protocol’s original architects could not have anticipated: what happens when a building automation network grows to the scale of an enterprise IT deployment, but still discovers devices by forwarding broadcasts to every corner of the network.
If this resonates with what you are experiencing on your campus, we would welcome the opportunity to discuss it further. More information about BACsync is available at bacsync.com.
About the Author — Mark Van Weert is the founder and director of Humber Horizons Limited, a building automation and cybersecurity consulting firm based in Ontario, Canada. With thirteen years of experience in BACnet systems integration, CCNA/CCNP certifications, and a background in large campus deployments, Mark specializes in IT/OT convergence and network infrastructure for universities, hospitals, and commercial facilities.