BACnet is the backbone of modern building automation. From HVAC controllers to lighting systems and access control panels, millions of BACnet devices run critical infrastructure in commercial buildings worldwide. But when these devices need maintenance, firmware updates, or troubleshooting, how do technicians access them remotely — without opening your building network to unnecessary risk?
This guide covers the security challenges of BACnet remote access, why traditional approaches fall short, and how to implement protocol-level controls that give technicians what they need while keeping your network locked down.
Why BACnet Remote Access Is Different
BACnet/IP runs on UDP port 47808 and relies heavily on broadcast discovery. When a technician opens their BACnet workstation software, it sends broadcast packets to discover controllers on the local network. This means simple IP routing isn't enough — BACnet remote access requires Layer 2 connectivity so the technician's device appears to be on the same network segment as the BACnet controllers.
This is fundamentally different from accessing a web interface or SSH terminal. You can't just forward a port and call it done. The technician needs to be Layer 2 adjacent to the BACnet network — which historically meant either being on-site or having a full, unrestricted VPN connection.
The Problem with Traditional BACnet Remote Access
Most buildings today handle BACnet remote access through one of three approaches, all of which have significant security gaps:
Persistent VPNs
The most common approach: give the integrator a VPN credential and leave it active permanently. The technician connects whenever they need to. The problem? That VPN typically provides unrestricted access to the entire building network — not just the BACnet controllers. And the credential never expires. A technician who connected six months ago may still have a live tunnel to your building. We cover why VPNs fail for building automation in detail in a separate article.
TeamViewer / AnyDesk
Some buildings set up a dedicated PC on the BAS network running TeamViewer or AnyDesk. The technician remote-desktops into that PC and accesses BACnet controllers from there. This creates a persistent, always-on access point with minimal audit trail. If that PC is compromised, the attacker has a foothold on your building network.
Open SSH Tunnels
More technically sophisticated, but equally problematic. SSH tunnels can provide BACnet access, but they're difficult to scope (the technician can tunnel any traffic), hard to monitor, and leave no protocol-level audit trail. Revoking access means hunting down SSH keys and hoping no one made a copy.
All three approaches share the same fundamental flaw: they give the technician more access than they need, for longer than they need it, with no visibility into what they're actually doing.
What Secure BACnet Remote Access Looks Like
Secure BACnet remote access should meet five criteria:
- Layer 2 connectivity — the technician must be able to discover and communicate with BACnet controllers using broadcast-based protocols, as if they were physically on the building network.
- Protocol restriction — only BACnet/IP (UDP 47808) and necessary support protocols should be allowed through. Everything else — SMB, RDP, SQL, FTP — should be blocked by default.
- Time limitation — access should expire automatically after a defined window (2-24 hours). No standing access between maintenance sessions.
- Traffic visibility — the building owner should be able to see exactly what protocols the technician is using, in real time, with historical records for audit.
- Instant termination — if anything looks wrong, the building owner should be able to kill the session in seconds, without coordinating with the integrator.
How Protocol Firewalling Works for BACnet
A protocol firewall for BACnet remote access operates at the bridge level (Layer 2), inspecting every frame that crosses the network bridge between the technician and the building network. Unlike a traditional IP firewall, it can filter based on Ethernet frame type, IP protocol, and transport port — all at the bridge forwarding layer.
A properly configured BACnet protocol firewall uses a default-deny approach:
- BACnet/IP (UDP 47808) — allowed, both directions
- HTTP/HTTPS (TCP 80, 443) — allowed, for BACnet controller web interfaces
- ICMP — allowed, for network diagnostics
- ARP — allowed, required for Layer 2 address resolution
- Everything else — dropped silently
This means the technician can discover BACnet controllers, read and write BACnet objects, access controller web interfaces for configuration, and ping devices for diagnostics. But they cannot browse file shares, connect via Remote Desktop, query databases, or reach any service not explicitly permitted. The attack surface drops from "everything on the network" to "BACnet controllers and their web interfaces." This approach aligns with the IT/OT network separation principles that NIST, IEC 62443, and cyber insurers now require.
Bandwidth Limiting: The Anti-Exfiltration Layer
Even with protocol firewalling, a compromised session could potentially exfiltrate data through the allowed protocols. BACnet traffic is lightweight — a typical BACnet controller exchange generates less than 50 Kbps. By capping session bandwidth at 10 Mbps (configurable per site), you make bulk data extraction impractical within a time-limited session window.
This is a defense-in-depth measure. Protocol firewalling prevents unauthorized protocol access. Bandwidth limiting prevents abuse of authorized protocols. Time limitation constrains the window of exposure. Together, they reduce the risk surface dramatically.
The Audit Trail: Answering "What Did the Technician Do?"
When your auditor, insurer, or risk team asks who accessed the BACnet network and what they did, you need a complete answer. A proper BACnet remote access platform should record:
- Who connected (technician identity)
- When they connected and for how long
- Which protocols they used (and how much traffic per protocol)
- How much total data was transferred
- Why the session ended (expired, manual termination, or revoked)
Per-protocol traffic accounting — updated every 60 seconds — gives you visibility into whether the technician was doing what they were supposed to be doing. If a BACnet maintenance session suddenly generates significant HTTP traffic, that's visible immediately, not buried in a firewall log that no one checks.
Deployment: Making It Practical
The best security controls are useless if they're too complex to deploy. Secure BACnet remote access should be deployable at any building site without an IT project:
- A small CPE device ships to the building site, pre-configured
- The facilities team plugs it into the BACnet network
- The device auto-provisions through Zero Touch Provisioning — no on-site IT required
- Technicians connect using a lightweight desktop app, with their session file
- Connection is established in seconds, Layer 2 adjacent to the BACnet network
The connection works over any internet path — broadband, LTE cellular, or satellite. Many remote building sites rely on LTE, and a well-designed encrypted tunnel protocol handles the latency and packet loss that come with cellular connections.
The Bottom Line
BACnet remote access is a necessity for building automation maintenance. But it doesn't have to mean unrestricted network access with no visibility. The technology exists today to provide:
- Layer 2 BACnet connectivity through encrypted tunnels
- Protocol-level firewalling that blocks everything except BACnet and support protocols
- Time-limited sessions that auto-expire with no standing access
- Per-protocol traffic monitoring with 60-second resolution
- One-click session termination for immediate incident response
- Compliance-ready audit reports for every session
Your technicians get the access they need. Your security team gets the controls they demand. Your auditors get the evidence they require. That's what building automation remote access should look like. For a broader look at the threat landscape driving these requirements, see our breakdown of BAS cybersecurity threats in 2026.
SiteConduit is a managed remote access and monitoring platform purpose-built for building automation. We provide time-limited, protocol-restricted, fully audited BACnet remote access — plus 24/7 device monitoring — for BAS integrators, facility managers, and security teams.
Join the waitlist at siteconduit.com for early access.
Hayden Barker
Founder, SiteConduit — Idea Networks Inc.
Hayden has spent over a decade designing and deploying network infrastructure for building automation environments. He built SiteConduit after seeing firsthand how traditional VPNs and remote access tools fail to meet the security and operational needs of BAS integrators and building owners.