Sooner or later someone from IT asks the question: "So how does the controller know the command came from the supervisor?" The honest answer, for BACnet/IP and Modbus TCP, is that it doesn't. If a packet arrives, correctly formed, on the right port, the device acts on it.
That surprises people who've grown up with logins and encryption on everything. It shouldn't surprise us, and once you understand why it's true, you can explain the risk calmly and put protection where it actually works. This article covers both, and stays on the defensive side: what the exposure is and how to close it.
The design era
Modbus was created in the late 1970s for serial links between a controller and the devices wired to it. BACnet was developed through the late 1980s and 1990s, and first published as an ASHRAE standard in 1995. Both were designed for a world where the network was a cable in a plant room or a riser. The only people who could touch it were the people who installed it, and the threat anyone worried about was noise, not an adversary.
In that world, authentication would have cost memory and processing on hardware that had very little of either, and bought nothing. So neither protocol checks who's asking. When Modbus moved to TCP and BACnet moved to IP, the messages stayed the same. They just travelled further, over networks shared with everything else.
What that means in the building
Put plainly: the protocol isn't the lock. On a typical BACnet/IP network, any machine on the same network, or with a route to it, can discover the devices, read their points, and write to commandable points such as setpoints, schedules and outputs. With Modbus TCP, any machine that can open a connection to port 502 can read registers and write the writable ones.
The practical consequences for a building:
- A compromised office PC on a flat network can reach every controller. No password to guess, no exploit needed. This is why segmentation matters so much more for building systems than for most IT systems.
- A misbehaving tool can do real damage without anyone intending it. A discovery scan from the wrong software, a test script pointed at the wrong subnet, an integration writing to the wrong priority — the device can't tell mistake from malice.
- Traffic is readable. Point names, values and schedules cross the network in the clear. On its own that's usually low-sensitivity data, but it tells anyone watching exactly how the building is laid out.
- Exposed to the internet, it's exposed to everyone. A controller reachable from the internet on 47808 or 502 is available to every automated scanner in the world. That's why the "supervisor on the internet" finding is always top of the list.
None of this is an argument that BACnet or Modbus are bad protocols. They're good at what they were built for. It's an argument that their protection has to come from around them rather than from within.
What about BACnet's own security?
BACnet did try. The standard added a network security architecture (Clause 24 in ASHRAE 135) intended to authenticate and protect BACnet messages. In practice it saw very little adoption: few products implemented it, and you're very unlikely to meet it on a site. I'd treat it as a historical footnote rather than something to plan around.
Some BACnet devices also accept an optional password on certain device-management services, such as communication control or reinitialisation. Where it's supported, set it. But it only protects those particular services, not ordinary reads and writes, and plenty of devices don't implement it.
BACnet/SC: the path forward
The practical answer from the BACnet side is BACnet Secure Connect. It's a new BACnet datalink, defined in Annex AB of the standard, that carries BACnet messages over secure WebSockets using TLS 1.3. Both ends present X.509 certificates, so each device proves who it is before any BACnet traffic flows, and everything on the wire is encrypted.
Crucially, the BACnet objects and services don't change. A setpoint is still an analog value with a priority array. What changes is who's allowed onto the network: a device without a certificate the site trusts can't connect to the hub at all. How BACnet/SC works covers the mechanics, and rollout planning covers getting there on a real site.
Compensating controls: what you do about it
Since the protocol won't protect itself, you put the protection in layers around it. None of these is new, and each one is within reach on an existing site.
Segmentation
Put BACnet/IP and Modbus TCP devices in their own network zone, separated from corporate and guest networks by a firewall. This is the control that turns "anyone on the network" into "only the things that should be there". It's covered in detail in segmentation and firewall rules.
Check: from a laptop on the office network, can you reach a controller? You shouldn't be able to.
Firewall allow-lists
At the zone boundary, allow only named flows: this supervisor to that subnet on UDP 47808; this energy gateway to that meter on TCP 502. Deny everything else. The narrower the source list, the fewer machines can issue a write. Where a device or router supports its own IP allow-list, use that too — it keeps working if the network design changes around it.
Check: could you name the source address for every rule that permits 47808 or 502 into the BAS zone?
Write protection where devices offer it
Some gateways and meters can be set to read-only on their Modbus or BACnet side, or allow writes only to specific registers. Some controllers let you restrict which points are commandable over the network. If an integration only needs to read — an energy dashboard, a monitoring-based commissioning tool — configure it as read-only at the device end if you can, not just in the software doing the reading.
Check: list which systems need to write, and to what. It's usually a much shorter list than the systems that read.
Keep it off the internet
No port forwards, no controllers on public addresses, remote access only through a VPN or approved gateway with MFA. See remote access without opening the building to the internet.
Monitoring
Because the protocol won't tell you who sent a write, you want to notice when something unexpected happens. The supervisor's audit log records changes made through the supervisor. For changes made around it, look at alarms on setpoints or modes that move outside normal ranges, trend reviews, and — on larger sites — network monitoring by IT that can flag new devices or unexpected sources talking BACnet or Modbus into the BAS zone.
Check: if a setpoint changed at 3 a.m. and nobody used the supervisor, would anything tell you?
Explaining it to IT and owners
This conversation goes better when you get ahead of it. A version I use:
"BACnet/IP and Modbus TCP were designed for isolated networks and don't authenticate requests. So we treat the network boundary as the lock: the BAS lives in its own zone, only named systems can reach it, nothing's exposed to the internet, and remote access goes through your VPN. For new work we're moving to BACnet/SC, which adds certificates and encryption, but we'll have legacy devices for a while, so the segmentation stays either way."
It's honest, it doesn't oversell, and it gives IT something concrete to agree to. What costs credibility is claiming the BAS is "secure because it's on its own VLAN" when the VLAN routes freely to the office, or claiming BACnet/SC makes segmentation unnecessary.
Seeing it for yourself
The best way to make this concrete is to look at a capture. BACnet/IP in Wireshark shows every point name and value in the clear; BACnet/SC shows a TLS handshake and then nothing but "Application Data". The BACnet/SC Capture Lab puts the two side by side, and it's a useful thing to show an owner who wants to understand the difference.
The takeaway
BACnet/IP and Modbus TCP trust whoever can reach them. You can't change that on installed devices, so you change who can reach them: segmentation, allow-lists, read-only where possible, nothing on the internet and someone watching for surprises. Then, where the budget and the devices allow, you move the IP layer to BACnet/SC.
Go deeper
BACnet and Modbus, from the wire up
How the services work, what a write at priority 8 really does, how Modbus registers map to points, and how to prove it in a capture. BAS Communication is the protocol layer these compensating controls are protecting.
Get BAS Communication — A Field ReferenceFound a wrong number or a broken link? Tell me and I’ll fix it.