Building automation systems on the agency network: BACnet, ownership, and remote access

Reference article · 6 min read

A building automation system, sometimes called a building management system, controls heating, cooling, ventilation, lighting, and often metering across a campus or a single facility. In most agencies it is bought by facilities, installed by a mechanical contractor, and maintained under a service agreement that never passes through IT. It is also, in nearly every modern installation, a collection of networked computers running web servers, databases, and remote access software on agency cabling.

That gap between how the system is purchased and what it actually is causes most of the trouble agencies run into later. The fix is not to move the system into IT wholesale. It is to write down which decisions belong to facilities, which belong to IT, and which conditions attach to the contractor before the first device is energized.

What a modern BAS is on the wire

Think of it in three layers.

• Field controllers. Small embedded devices at each air handler, VAV box, boiler, chiller, or lighting panel. They typically speak BACnet MS/TP over RS-485 twisted pair, Modbus RTU, or a proprietary bus. These are not IP devices and are rarely the security problem on their own.
• Supervisory controllers and gateways. Devices that bridge serial field buses to Ethernet. Niagara-based JACE-style controllers are the common example, but every major manufacturer sells an equivalent. These are real IP hosts running an embedded operating system, a web interface, and often a small database.
• Front end servers and dashboards. A Windows or Linux server hosting graphics, schedules, trend logs, and the alarm engine, reached by staff through a browser. This is the piece people mean when they say "the BAS."

On the network you will mostly see BACnet/IP, which by convention uses UDP port 47808, and Modbus TCP on port 502. Niagara installations add their own Fox protocol ports. Traditional BACnet/IP carries no authentication or encryption: any host that can reach a controller can read points and, in many configurations, write them. ASHRAE Standard 135 now includes BACnet Secure Connect, which uses TLS and certificates, but adoption depends on the age of the equipment and the vendor's firmware. Confirm what a specific product supports rather than assuming.

Why it ends up on the agency network

Facilities wants one front end for every building, which requires routed IP between sites. Staff want dashboards from their desks. Alarms need to reach email or text. Once those requirements exist, running a separate physical network to every mechanical room is expensive, so the contractor asks for a data drop, and the system joins the agency network.

Two wrinkles follow. BACnet/IP relies on broadcasts, so crossing subnets requires BBMD configuration or foreign device registration, which means IT has to be involved in the design rather than just providing a port. And if IT declines to provide connectivity at all, the system does not stay offline: a cellular modem appears in the mechanical room, outside every control the agency has.

Splitting responsibility between facilities and IT

Write this down before the argument happens, not during it.

• Control logic and sequences of operations. Facilities owns this completely. IT should not be changing setpoints or schedules.
• Network placement and segmentation. IT owns this. Put the BAS in its own segment with explicit rules for who may reach it and what it may reach outbound.
• Patching. IT patches the front end server operating system and browser-facing components, coordinated with facilities and checked against the vendor's supported versions. Controller firmware stays with the vendor, applied in scheduled windows with a rollback plan.
• Backups of controller programs. This is the one most agencies miss. Control programs, graphics, and point databases live in device flash and in station files, not in the file shares IT already backs up. Require exported station and program archives on a defined cadence, stored somewhere IT actually backs up, and test a restore.
• Accounts. Named accounts only, tied to the agency directory where the platform supports it. No shared operator login. Contractor accounts get an end date matched to the contract.
• After-hours alarms. Separate equipment alarms, which route to the facilities on-call rotation, from platform alarms such as a controller going offline or a server failing, which route to IT. Send both to a monitored queue rather than one person's mailbox.

Failure mode one: the system nobody in IT knew about

A contractor installs a supervisory controller during a renovation, plugs it into the nearest jack, and leaves. Nobody records it. It runs unpatched for years.

To find what you already have, scan internal ranges for UDP 47808, TCP 502, and the Niagara Fox ports, and cross-reference switch port descriptions, DHCP reservations, and recent capital project records. Walk mechanical rooms with facilities. Then attach conditions to the next project: no device connects to agency infrastructure without an IT-issued address and an inventory record, the contractor submits a device list with make, model, firmware, and MAC address before acceptance, and final payment depends on that submittal.

Failure mode two: vendor remote access with a shared password

The service agreement promises remote diagnostics, and the practical implementation is a single account with a password the vendor uses across many customers, or a remote support tool the contractor installed on the front end server.

Replace it with access the agency controls: agency-issued named credentials, multifactor authentication, connectivity through the agency's own VPN or remote access broker, and access enabled for a work window rather than standing open. Prohibit vendor-installed remote tools and unapproved cellular modems in writing. Require logging of who connected and what changed, and ask for the credential and connection inventory at each renewal.

What to require before signing

1. A network architecture drawing showing every IP device, protocol, and port.
2. A device and firmware inventory as a deliverable, updated at project closeout.
3. Ownership of the licenses, station files, program source, and graphics, with an exported copy delivered to the agency.
4. Named accounts with no shared or default credentials, and documented removal of installer accounts.
5. Remote access only through agency-controlled paths, with session logging.
6. A stated patch and firmware support commitment for the term, and what happens when a version reaches end of support.

HQT works with state and local agencies on systems engineering and network architecture questions of this kind, including how operational technology should be segmented and governed alongside enterprise IT.

Frequently asked questions