Getting building automation off your office network
HVAC and building controls often sit on the same network as office PCs, speaking a protocol with no authentication. Here's how to separate them without breaking the heat.
Walk into the mechanical room of a lot of courthouses, schools, and bank branches, and you’ll find a building automation controller plugged into the same switch as the office PCs. The HVAC contractor needed network access, somebody gave them a port, and nobody has looked at it since.
I spent years on the HVAC side of this before moving into IT, and the gap is real. The controls technician usually assumes the network is IT’s problem. The IT person usually assumes the controls are the contractor’s problem. The building automation system ends up owned by nobody.
Why it matters
Most building automation systems in small facilities speak BACnet/IP, the building-control protocol standardized by ASHRAE. It normally runs on UDP port 47808.
The classic version of BACnet has no built-in authentication or encryption. A device that can reach a controller on that port can usually read its points and, depending on the controller’s configuration, write to them: setpoints, schedules, and equipment commands. Newer controllers may support BACnet Secure Connect (BACnet/SC), which adds TLS-based security, but most installed equipment in small buildings doesn’t use it yet.
So a controller sitting on the office network is reachable by every PC on that network, including one that just opened a malicious attachment. And researchers scanning the internet have found tens of thousands of BACnet devices directly reachable from anywhere.
Step 1: Find what’s out there
Ask the HVAC contractor for a list of controllers, their IP addresses, and how they get remote access. Then check for yourself. A UDP scan of your internal ranges for port 47808 will find BACnet devices that answer:
nmap -sU -p 47808 --script bacnet-info 192.168.1.0/24
Run that only on networks you’re responsible for, and tell the facilities folks before you do. Some older controllers don’t love being scanned.
While you’re at it, confirm nothing on port 47808 is forwarded through the firewall from the internet. If it is, that’s the first thing to close.
Step 2: Give building controls their own network
Put the building automation system on its own VLAN and subnet, with a firewall or layer-3 switch between it and everything else. Then write rules for the traffic that actually needs to cross:
- The building automation front end (the workstation or server running the HVAC software) needs to reach the controllers. Either put it on the building-controls network or allow only that machine through.
- Office PCs generally don’t need to reach controllers at all. Block it.
- The controllers rarely need the internet. Block outbound by default and allow only what the vendor can justify, such as time sync or a specific cloud service.
One BACnet quirk to plan for: BACnet uses broadcast messages for device discovery, and broadcasts don’t cross subnets. If all your controllers land on the same new subnet, that’s usually fine. If they’re spread across subnets, the system may need a BACnet Broadcast Management Device (BBMD) configured so discovery still works. Talk to the controls contractor before you move anything, because a missed BBMD setting is an easy way for a segmentation project to “break the heat.”
Step 3: Fix remote access
Controls contractors need to get in remotely, and the traditional ways are often the worst: a port forward straight to the front-end PC, or a remote-desktop tool someone installed years ago with a shared password.
Replace these with something you control:
- A VPN account for the contractor that only reaches the building-controls network
- MFA on that account
- An individual account for each technician, not one shared login
- Access you can turn off in one place when the contract ends
Step 4: Write it down
Add the building-controls network to your network diagram, record which contractor supports it, and note how their remote access works. If your organization goes through CJIS, FFIEC, or cyber insurance reviews, this documentation shows you’ve accounted for a system that’s easy to overlook.
Sources
- SANS Internet Storm Center: checking for BACnet devices inside corporate networks: BACnet on UDP 47808 and discovery with Nmap
- DIVD case report: exposed BACnet devices (Dutch Institute for Vulnerability Disclosure): internet-wide scan findings for exposed BACnet systems