What protocols does SiteConduit support for building automation remote access?

SiteConduit supports BACnet/IP (UDP 47808), Modbus/TCP (TCP 502), Niagara Fox (TCP 4911, 5011), HTTP/HTTPS (TCP 80, 443), and ICMP. The protocol allowlist is configurable per site, and a default-deny bridge filter blocks everything not explicitly permitted.

How does SiteConduit prevent unauthorized lateral movement on building networks?

Every session runs behind a protocol-level firewall with a default-deny bridge filter. Only approved BAS protocols are permitted. Technicians can reach their BACnet controllers and Niagara stations but cannot access file servers, printers, or IT infrastructure. Sessions are also bandwidth-limited to prevent data exfiltration.

Does SiteConduit support compliance and audit requirements?

SiteConduit generates detailed compliance reports with full session history including technician identity, session times, protocols used, and data transferred. Reports export to CSV and are designed to support industry compliance frameworks, insurance renewals, and vendor risk assessments.

How long does it take to deploy SiteConduit at a building site?

Minutes, not months. SiteConduit ships a pre-configured CPE device to your site. Your facilities team plugs it into the building automation network. The device auto-provisions via Zero Touch Provisioning with no on-site IT support required.

Can building owners terminate remote access sessions immediately?

Yes. SiteConduit provides a one-click kill switch that terminates any session in seconds. The encrypted tunnel is disabled, credentials are revoked, and the network bridge is destroyed. Bulk termination is available per-site or across all sites in your organization.

BACnet Firewall Rules: What to Allow and What to Block

You just segmented your building automation network onto its own VLAN. Your BACnet controllers are isolated from corporate IT. The firewall is in place. And now nothing works — your BAS supervisor cannot discover any controllers. The integrator cannot connect remotely. The energy meters stopped reporting.

The problem is almost always the firewall rules. BACnet has specific networking requirements that generic "allow all outbound" rules do not cover. This guide provides the exact rules you need for BACnet/IP and BACnet Secure Connect (BACnet/SC), plus the supporting protocols that BAS controllers depend on.

Why BACnet traffic gets blocked after network changes

BACnet/IP uses UDP — not TCP. Many firewall default policies allow outbound TCP connections but drop UDP. BACnet also uses broadcast packets for device discovery, and most firewalls block broadcast by default. The combination means a standard corporate firewall configuration will block BACnet communication completely.

Additionally, BACnet uses a non-standard port (UDP 47808), which does not appear in most firewall templates. IT administrators who have never worked with BAS may not know this port exists, let alone that it needs to be open.

BACnet/IP firewall rules

BACnet/IP is the most common BACnet transport in modern buildings. All communication — device discovery, property reads, writes, subscriptions, and alarms — uses UDP port 47808 (hexadecimal 0xBAC0).

Rule 1: Allow UDP 47808, both directions

BACnet/IP communication is bidirectional. Controllers send I-AM responses, alarm notifications, and COV (Change of Value) subscriptions back to the BAS supervisor. A rule that allows only outbound UDP 47808 will break these return communications.

Source: BAS management subnet
Destination: BAS controller subnet(s)
Protocol: UDP
Port: 47808
Direction: Both (or create two one-way rules)

Rule 2: Allow broadcast on UDP 47808 within BAS subnets

BACnet device discovery (WHO-IS/I-AM) uses broadcast packets. If your BACnet devices are on a single subnet, the firewall needs to allow broadcast on that subnet. If BACnet devices span multiple subnets, you need BBMDs to forward broadcast (see our BBMD setup guide) and firewall rules to allow the BBMD unicast forwarding between subnets.

Rule 3: Allow BBMD traffic between subnets (if applicable)

If you have BBMDs configured on multiple subnets, allow UDP 47808 between the BBMD IP addresses. BBMD forwarding uses directed (unicast) packets, not broadcast, so standard firewall rules between specific IPs are sufficient.

Source: BBMD IP on subnet A
Destination: BBMD IP on subnet B
Protocol: UDP
Port: 47808
Direction: Both

BACnet Secure Connect (BACnet/SC) firewall rules

BACnet/SC is the newer, encrypted transport standard for BACnet. It uses TLS-encrypted WebSocket connections instead of plain UDP. BACnet/SC is defined in ANSI/ASHRAE Addendum BJ to Standard 135-2020.

BACnet/SC operates differently from BACnet/IP:

Transport: TCP (not UDP)
Port: TCP 443 (standard HTTPS port, using WebSocket upgrade)
Encryption: TLS 1.2 or 1.3 with X.509 certificates
Architecture: Hub-and-spoke through a BACnet/SC Hub, not broadcast

Rule 4: Allow TCP 443 to BACnet/SC Hub

BACnet/SC devices connect to a central Hub (which may run on a BAS supervisor or dedicated device). All BACnet/SC traffic flows through this Hub.

Source: BACnet/SC devices
Destination: BACnet/SC Hub IP
Protocol: TCP
Port: 443
Direction: Initiated by devices toward Hub

Important: BACnet/SC uses TCP 443 with a WebSocket upgrade (Sec-WebSocket-Protocol: hub.bsc.bacnet.org). If your firewall performs deep packet inspection or SSL decryption, it must not interfere with the WebSocket upgrade handshake or the TLS session. Allow TCP 443 to the Hub IP address and disable any DPI or SSL interception for that destination.

Certificate requirements

BACnet/SC requires X.509 certificates on both the Hub and the connecting devices. These certificates must be provisioned before BACnet/SC communication works. If your building is transitioning from BACnet/IP to BACnet/SC, plan for certificate management as part of the migration. This is a configuration task, not a firewall task, but it is the most common reason BACnet/SC connections fail after firewall rules are correctly configured.

Supporting protocols

BACnet controllers do not operate in isolation. They depend on several supporting protocols that must also be allowed through the firewall:

HTTP/HTTPS (TCP 80, 443)

Most BACnet controllers have web-based configuration interfaces. Technicians use these to view device status, change settings, and update firmware. Allow TCP 80 and 443 from the BAS management subnet to controller subnets.

NTP (UDP 123)

Time synchronization is critical for BAS. HVAC scheduling, lighting scenes, alarm timestamps, and audit logs all depend on accurate time. Allow BAS controllers to reach an NTP server (either on the BAS management subnet or an external NTP server through a defined path).

DNS (UDP/TCP 53)

If any BAS controllers use hostnames (some newer controllers do), allow DNS resolution. If all devices use static IP addresses (which is common in BAS), DNS may not be required.

ICMP

Allow ICMP (ping) between BAS subnets for network diagnostics. Blocking ICMP creates troubleshooting headaches without meaningful security benefit on an isolated BAS network.

Modbus TCP (TCP 502)

If your BAS network includes Modbus devices (energy meters, VFDs, sensors), allow TCP 502 between the BAS supervisor and Modbus devices. For more on Modbus security considerations, see our Modbus remote access guide.

Niagara FOX (TCP 1911, 4911)

If your building uses Niagara controllers (JACEs, FX supervisors), allow TCP 1911 (unencrypted FOX) and TCP 4911 (TLS-encrypted FOX) between Workbench stations and Niagara controllers. TCP 4911 is preferred for security.

Common misconfigurations

Blocking broadcast within the BAS VLAN

Some firewalls or switch ACLs block broadcast traffic even within a VLAN. BACnet/IP device discovery fails completely without broadcast on UDP 47808. Verify that broadcast is allowed within each BAS VLAN.

Allowing only inbound or only outbound

BACnet/IP is bidirectional over UDP. Unlike TCP, there is no connection handshake. Each BACnet message is an independent UDP packet. The firewall must allow UDP 47808 in both directions between BAS subnets. A "stateful" firewall that tracks UDP sessions may partially work, but explicitly allowing both directions is more reliable for BACnet.

Forgetting the return path for I-AM

The BAS supervisor sends a WHO-IS broadcast. Controllers respond with I-AM unicast to the supervisor's IP. If the firewall allows outbound broadcast but blocks inbound unicast on UDP 47808, discovery appears to fail even though the WHO-IS was sent successfully. The I-AM responses are being dropped.

Blocking ephemeral ports for UDP responses

Some BACnet implementations use the source port 47808 for all communication (standard-compliant). Others use ephemeral source ports (non-standard but common). If your firewall filters on both source and destination port, it may block responses from devices that use ephemeral source ports. The safest rule allows destination UDP 47808 from any source port.

SSL/TLS interception breaking BACnet/SC

Corporate firewalls that perform SSL interception (man-in-the-middle decryption for inspection) will break BACnet/SC connections. BACnet/SC devices verify the Hub's certificate against their provisioned trust store. An intercepting firewall replaces the certificate, causing the TLS handshake to fail. Exempt BACnet/SC Hub addresses from SSL interception.

Testing your firewall rules

After configuring firewall rules, test systematically:

WHO-IS/I-AM test: From the BAS supervisor, run a WHO-IS scan. All controllers on all allowed subnets should respond with I-AM.
ReadProperty test: Read a BACnet property (Object_Name or Present_Value) from a controller on each subnet. This verifies unicast communication, not just broadcast.
COV subscription test: Subscribe to a Change of Value on a controller. Verify that COV notifications arrive at the subscriber. This tests the return path from controller to supervisor.
Web interface test: Access a controller's web interface (HTTP or HTTPS) from the management subnet.
Ping test: Ping controllers on each BAS subnet from the management subnet.
Negative test: From a device on the corporate IT VLAN, attempt to ping or connect to a BAS controller. This should fail — confirming that the IT/OT firewall rules are working.

The protocol firewall approach

Traditional IP firewalls operate at Layer 3-4: they filter based on IP addresses, ports, and protocols (TCP/UDP). They can allow or block BACnet/IP traffic based on the port number (47808), but they cannot distinguish between a legitimate BACnet ReadProperty request and arbitrary data stuffed into a UDP packet on port 47808.

A protocol firewall operates at the bridge level (Layer 2) and filters based on the actual traffic content. For BACnet remote access, a protocol firewall can:

Allow BACnet/IP traffic on UDP 47808 while blocking non-BACnet traffic that attempts to use the same port
Apply default-deny at the Ethernet frame level, allowing only whitelisted protocols and ports
Monitor per-protocol traffic volumes in real time, identifying anomalous patterns
Cap bandwidth per session to prevent data exfiltration through allowed protocols

This is the difference between an IP-level rule ("allow UDP 47808") and a protocol-aware rule ("allow BACnet/IP communication, monitor traffic volumes, cap bandwidth, and drop everything else"). For segmented BAS networks where third-party technicians need remote access, the protocol firewall approach provides security controls that IP-level rules cannot match.

SiteConduit provides protocol-level firewalling for building automation remote access. Default-deny bridge filters that allow only BACnet, Modbus, and Niagara traffic through encrypted tunnels, with per-protocol traffic monitoring and time-limited sessions.

Join the waitlist for early access, or visit our FAQ for technical details.