Every commercial building depends on outside technicians. HVAC integrators, fire alarm contractors, lighting programmers, access control specialists — they all need remote access to the systems they install and maintain. And for the past two decades, the default answer has been the same: give them a VPN.
It made sense at the time. VPNs were already deployed for IT remote work. The infrastructure was there. The IT team understood the technology. And for years, nobody questioned whether a tool designed for corporate office workers was appropriate for accessing physical building systems that control heating, cooling, fire suppression, and security.
That era is ending. Gartner, the insurance industry, and a growing list of building owners are arriving at the same conclusion: VPNs are the wrong tool for building automation remote access, and the risk they create is no longer acceptable.
Why VPNs became the default for BAS remote access
The adoption path was straightforward. When a BAS integrator needed remote access to a job site, the building's IT team already had VPN infrastructure in place. Adding another user was simple — create a credential, hand it to the contractor, and move on.
This worked well enough when building automation systems were simple, isolated, and low-stakes. But three things changed:
- Building systems became networked. BACnet/IP, Modbus TCP, and Niagara stations now sit on IP networks alongside other building infrastructure. A BAS controller is no longer a standalone device on a serial bus — it's a networked endpoint.
- Third-party access proliferated. A typical commercial building has 5 to 15 different contractors who need remote access. Each one gets a VPN credential. Most of those credentials never expire.
- The threats caught up. 70% of OT security incidents involve third-party access. Ransomware groups have discovered that building systems are soft targets — Johnson Controls lost 27 TB of data and spent $27 million on remediation after a 2023 breach.
The VPN was never designed for this. It was designed to give a corporate employee secure access to their office network. It assumes trust, grants broad access, and has no concept of what the user is doing once they're connected.
What Gartner's 2026 CPS Market Guide says about VPNs and OT
In February 2026, Gartner published its first standalone Market Guide for CPS (Cyber-Physical Systems) Secure Remote Access. This is significant. Gartner now recognizes that remote access to operational technology — the systems that control physical processes in buildings, factories, and utilities — requires a fundamentally different approach than IT remote access.
Their assessment of VPNs is direct:
“VPNs, jump servers, and IT-centric access tools create unacceptable risk because they lack asset-level, protocol-aware, and operational controls.”
Three phrases in that quote matter for building automation professionals:
- Asset-level controls. A VPN grants access to a network. It cannot restrict access to a specific BACnet controller, a specific Niagara station, or a specific Modbus device. Every device on that subnet is reachable.
- Protocol-aware controls. A VPN passes all traffic. It cannot distinguish between BACnet/IP on UDP 47808 and an attacker scanning for open SMB shares. It has no concept of building automation protocols.
- Operational controls. A VPN has no built-in session time limits, no per-protocol traffic monitoring, no one-click termination. The operational controls that building owners and security teams need simply do not exist in a VPN.
Gartner is not saying VPNs are insecure in general. They are saying that VPNs lack the specific controls required for environments where remote access connects to physical systems — systems that heat, cool, pressurize, lock, and illuminate buildings where people live and work.
Five specific ways VPNs fail for building automation
The Gartner assessment is broad. Here is how those gaps play out specifically in BAS environments.
1. No protocol awareness
When an HVAC technician connects via VPN to troubleshoot a BACnet controller, the VPN has no idea what protocols are flowing through the tunnel. BACnet/IP on UDP 47808, Niagara Fox on TCP 1911, Modbus TCP on port 502 — these are all just IP packets to a VPN.
This means the VPN cannot enforce a policy like “this technician is only authorized for BACnet traffic.” It cannot block a compromised workstation from scanning the network for SQL databases, file shares, or other services that have nothing to do with building automation. Every protocol is allowed. Every port is open. The VPN is protocol-blind.
2. No session limits
A BAS maintenance task typically takes 30 minutes to 4 hours. But VPN sessions do not auto-expire after the work is done. Most VPN deployments use persistent credentials — a username and password that works indefinitely. The technician connects, finishes their work, and the session stays open. Sometimes for hours. Sometimes for days. Sometimes the credential is shared across an entire integrator team.
There is no concept of “this session should last 2 hours and then automatically terminate.” There is no mechanism for the building owner to grant access for a specific maintenance window and have it revoke itself. The VPN is either on or off, and it defaults to on.
3. Full network exposure
When a contractor connects to a building's VPN, they typically land on the same subnet as the BAS controllers. But they also land on the same subnet as everything else on that network segment — security cameras, access control panels, energy meters, and in too many buildings, the corporate IT network.
The contractor only needs to reach two BACnet controllers. Instead, they can reach everything. If their laptop is compromised — and contractor laptops are routinely shared, poorly patched, and used across dozens of client sites — the attacker inherits that same unrestricted network access.
VPN split tunneling and ACLs can reduce this exposure, but they operate at the IP and port level. They cannot restrict access to “only BACnet traffic to these specific controller IPs.” They lack the protocol-level granularity that building automation environments require.
4. No protocol-level audit trail
When your insurance provider, your risk team, or a forensic investigator asks “what did that contractor do on your building network last Tuesday,” a VPN gives you one answer: they connected at 2:14 PM and disconnected at 5:47 PM. That is the extent of the VPN audit trail.
It cannot tell you which protocols the technician used. It cannot tell you whether they accessed BACnet controllers, Modbus devices, or something else entirely. It cannot tell you how much data was transferred per protocol. It cannot distinguish between a 30-minute BACnet troubleshooting session and three hours of lateral network scanning.
For compliance frameworks like NIST 800-82 and IEC 62443, “someone connected to the VPN” is not an adequate audit record. Assessors and insurers want per-session, per-protocol evidence of what was accessed and for how long.
5. No device monitoring or health visibility
A VPN is a tunnel. It connects a user to a network and then gets out of the way. It has no awareness of the devices on the other end — whether the BACnet controllers are online, whether the CPE device maintaining the tunnel is healthy, whether a device has gone offline or is behaving abnormally.
This means the building owner has no continuous visibility into their BAS network between maintenance sessions. They find out a controller is offline when a tenant complains about the temperature, not when the device actually fails. The VPN provides a pipe, but zero operational intelligence.
The real risk: what happens when a VPN session goes wrong
The five failures above are not theoretical. They compound in practice. Consider a scenario that plays out in commercial buildings regularly:
A controls contractor has a persistent VPN credential for a 200,000-square-foot office building. They use it for quarterly HVAC maintenance. The credential is shared among three technicians on the integrator's team. One of those technicians leaves the company. Nobody revokes the credential because nobody tracks who has it.
Six months later, the former technician's laptop — still configured with the VPN client and saved credentials — is used for another job. Or it sits on a shelf, unpatched, accumulating vulnerabilities. Or it gets sold on the secondary market with the VPN profile still intact.
Meanwhile, the VPN provides the same access it always has: full subnet connectivity to the building's BAS network, which in this case shares a VLAN with the building's access control system and IP security cameras. The building owner has no alert, no monitoring, and no audit trail that would show an unauthorized connection.
This is not a sophisticated cyberattack. It is a credential management failure that VPNs make easy and inevitable. Every building with a persistent VPN and a shared contractor credential is carrying this risk right now.
The consequences in a BAS environment are physical. An attacker — or even a disgruntled former employee — with access to HVAC controllers can manipulate temperatures in a data center, disable ventilation in an occupied space, or interfere with fire suppression systems. These are not data breaches. They are safety events.
What protocol-aware remote access looks like
The alternative to a VPN is not a better VPN. It is a purpose-built remote access platform that understands building automation protocols and enforces controls at the protocol level, not just the network level.
SiteConduit was built specifically for this problem. Here is how protocol-aware BAS remote access differs from a VPN across the five failure points:
Protocol firewalling instead of open tunnels
When a technician connects through SiteConduit, a protocol firewall at the bridge level inspects every frame. Only explicitly permitted protocols pass through — BACnet/IP on UDP 47808, Modbus TCP on port 502, HTTP/HTTPS for controller web interfaces, ICMP for diagnostics. Everything else is dropped by default. The technician cannot scan the network, reach file shares, or access services outside their authorized protocol set.
Time-limited sessions instead of persistent credentials
Sessions are scoped to a specific duration — from 2 to 24 hours, configured by the building owner or integrator admin. When the session expires, access terminates automatically. No standing access between maintenance windows. No credentials that linger for months. If the technician needs more time, a new session is explicitly granted.
Per-device, per-protocol access instead of full subnet
Access is granted to a specific building site with specific protocol permissions. The technician reaches the BAS controllers they need and nothing else. The encrypted tunnel terminates at a CPE device on the building network, with the protocol firewall enforcing what traffic is allowed between the technician and the building network.
Per-protocol traffic accounting instead of connection logs
SiteConduit records per-protocol traffic volumes updated every 60 seconds. The building owner can see that a technician used 2.3 MB of BACnet/IP traffic and 450 KB of HTTPS traffic during a 90-minute session. If unexpected protocols appear or traffic volumes spike, it is visible in real time — not buried in a firewall log that nobody checks.
24/7 device monitoring instead of blind tunnels
Between maintenance sessions, SiteConduit continuously monitors the BAS network through the CPE device — device reachability, uptime, LTE signal quality for cellular-connected sites. The building owner sees the health of their BAS network at all times, not just when a technician happens to connect.
Migration path: from VPN to purpose-built BAS remote access
Replacing a VPN does not require ripping out existing infrastructure overnight. A practical migration follows three phases:
Phase 1: Deploy alongside the existing VPN
Start with one or two building sites. A pre-configured CPE device ships to the building and connects to the BAS network. Technicians begin using protocol-aware sessions for routine maintenance while the VPN remains as a fallback. This phase typically takes one to two weeks and requires no changes to the existing network.
Phase 2: Migrate technicians and establish policy
As integrators adopt the new workflow, establish session policies — maximum duration, permitted protocols, required audit records. Move additional building sites onto the platform. Each site deployment takes under an hour with Zero Touch Provisioning: plug in the CPE device and it auto-configures. During this phase, the VPN is still available but usage should decline as technicians prefer the faster, simpler session-based workflow.
Phase 3: Decommission the VPN for BAS access
Once all building sites are covered and all integrators are using session-based access, disable VPN credentials for BAS network access. The VPN infrastructure can remain for other corporate uses — this is specifically about removing it as the access method for building automation systems.
The result: every technician session is time-limited, protocol-restricted, and fully audited. The building owner has a complete record of who accessed their BAS network, what protocols they used, and for how long. For organizations working toward compliance with NIST 800-82 or IEC 62443, this audit trail is directly applicable. If you are also evaluating IT/OT network separation as part of the same initiative, a managed remote access platform handles both requirements simultaneously.
Evaluation checklist: what to look for in a VPN replacement
Not every “OT remote access” product is built for building automation. Many were designed for manufacturing or industrial control systems and lack BAS-specific protocol support. When evaluating a VPN replacement for your building automation network, ask these questions:
- Does it support BAS protocols natively? BACnet/IP, Modbus TCP, Niagara — these should be explicitly supported with protocol-level firewalling, not just “any TCP/UDP traffic.”
- Does it provide Layer 2 connectivity? BACnet relies on broadcast discovery (WHO-IS/I-AM). A Layer 3 solution that cannot forward broadcast traffic will break BACnet device discovery. Layer 2 connectivity is essential for real BACnet remote access.
- Are sessions time-limited by default? Auto-expiry should be a core feature, not an add-on. Look for configurable session durations from 2 to 24 hours with automatic termination.
- Does it provide per-protocol traffic monitoring? Connection logs are not enough. You need visibility into which protocols were used, how much data was transferred per protocol, and the ability to detect anomalies in real time.
- Can the building owner terminate a session instantly? One click, immediate disconnection. No coordinating with the integrator, no waiting for a session timeout.
- Does it monitor devices between sessions? A remote access tool that only works when someone is connected provides zero visibility the other 99% of the time. Look for continuous device monitoring — uptime, reachability, and health status.
- Is deployment practical for building sites? If it requires on-site IT staff, network reconfiguration, or a virtual machine, it will not scale across a portfolio of buildings. Look for a CPE device with Zero Touch Provisioning that can be deployed by facilities staff.
- Is it multi-tenant? If you manage multiple buildings — or if you are an integrator managing multiple client sites — the platform should provide per-tenant isolation, per-technician authentication, and per-site compliance reporting.
- Is the audit trail compliance-ready? Ask specifically about NIST 800-82 and IEC 62443. The platform should produce audit reports that map directly to these frameworks without requiring manual log aggregation.
- What does pricing look like? OT remote access vendors are notorious for opaque enterprise pricing. Transparent, per-site pricing makes the platform accessible to building owners and integrators of all sizes.
The bottom line
VPNs served a purpose. They gave building automation teams remote access when no better option existed. But the risk profile has changed. Buildings are more connected, threat actors are more sophisticated, and compliance requirements are more demanding.
Gartner's 2026 CPS Market Guide confirms what building owners and integrators have been experiencing: VPNs lack the protocol awareness, session controls, and operational visibility that building automation environments require. For a data-driven look at what is driving this shift, see our breakdown of BAS cybersecurity threats in 2026. The question is no longer whether to move beyond VPNs. It is when and how.
The technology exists today to provide time-limited, protocol-restricted, fully audited remote access to BAS networks — without the security gaps that come with a VPN. For building owners carrying the risk of persistent VPN credentials and unmonitored contractor access, the migration path is clear and incremental.
SiteConduit is a managed remote access and monitoring platform purpose-built for building automation. Protocol firewalling, time-limited sessions, per-protocol traffic monitoring, and 24/7 device visibility — designed for BAS integrators, facility managers, and OT 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.