Zero Trust for Building Automation: What It Actually Means

Zero trust has become the default security framework in enterprise IT. Every firewall vendor, identity provider, and security consultant claims to deliver it. But for building automation — where the assets are physical controllers running 15-year-old protocols — zero trust means something specific and practical. It is not a product. It is a set of principles applied to BAS access controls.

This article translates zero trust from IT abstraction to BAS reality: what each principle means for building automation, what it looks like in practice, and where most buildings fall dangerously short.

Zero trust in 60 seconds

The core principle is simple: never trust, always verify. No user, device, or connection is trusted by default, regardless of whether it originates inside or outside the network perimeter.

In IT, this means things like identity verification before every request, micro-segmentation of network traffic, and continuous monitoring of device posture. In building automation, the same principles apply but the implementation must account for how BAS technicians actually work.

Why traditional BAS access is the opposite of zero trust

The typical BAS remote access setup violates every zero trust principle:

• Shared credentials: The HVAC integrator has one VPN account shared across all their technicians. There is no way to identify which individual accessed the building.
• Full network access: The VPN provides access to the entire subnet — not just the BACnet controllers the technician needs, but file shares, printers, databases, and every other device on the network.
• Standing access: VPN credentials do not expire. A technician who worked on the building six months ago still has a working connection. There is no session lifecycle.
• No protocol restriction: The VPN passes all traffic. RDP, SMB, FTP, SQL — all traverse the same tunnel as BACnet. There is no protocol-level control.
• No monitoring: Nobody knows what the technician did during the session. There is no protocol-level traffic record, no per-session audit, and no alerting on anomalous behavior.

This is not a failure of the people involved. It is a failure of the tools. Traditional VPNs were designed for IT users who need broad network access. BAS technicians need narrow, protocol-specific access for defined time periods. The tool does not fit the task.

Five zero trust principles applied to BAS

Principle 1: Verify identity for every session

Every technician should authenticate individually — no shared accounts, no shared credentials. When your building owner asks "who accessed the HVAC network on Tuesday," the answer should be a specific person, not "someone from the integrator's company."

In practice: Individual technician accounts with multi-factor authentication. Session requests tied to a named individual. Audit logs that record who, not just what.

Principle 2: Validate the device

The technician's workstation should meet minimum security requirements before accessing the building network. Is the OS patched? Is endpoint protection running? Is the machine managed by the integrator's IT?

In practice: Device posture checks before session establishment. At minimum, verify the device identity through pre-distributed session files rather than accepting connections from any machine with VPN credentials.

Principle 3: Limit the session window

Access should exist only for the duration of the maintenance task. A BACnet troubleshooting session does not need 24/7 standing access. It needs 2-8 hours with automatic expiry.

In practice: Time-limited sessions with configurable windows (2, 4, 8, or 24 hours). Automatic termination when the window closes. No renewal without re-authentication. Zero standing access between sessions.

Principle 4: Restrict to required protocols

A BACnet technician needs BACnet/IP on UDP 47808, maybe HTTP/HTTPS for controller web interfaces, and ICMP for diagnostics. They do not need SMB, RDP, SQL, or FTP. A default-deny protocol firewall should block everything except the specific protocols required for the maintenance task.

In practice: A bridge-level protocol firewall that inspects every frame crossing the remote access connection. Allow BACnet (UDP 47808), Modbus (TCP 502), Niagara FOX (TCP 1911/4911), HTTPS (TCP 443), and ICMP. Drop everything else silently.

Principle 5: Monitor continuously

Every session should be monitored in real time with per-protocol traffic visibility. If a BACnet maintenance session suddenly generates 500 MB of HTTP traffic, that anomaly should be visible immediately — not discovered during a forensic review three months later.

In practice: Per-protocol traffic accounting updated every 60 seconds. Real-time session visibility for building owners. One-click kill switch for immediate termination if anomalous behavior is detected. Full session records for audit and compliance.

Default-deny in practice

Default-deny is the single most important zero trust control for BAS remote access. It inverts the traditional model: instead of allowing everything and hoping the technician behaves, you block everything and explicitly allow only what is needed.

For a building running BACnet, Modbus, and Niagara, a default-deny protocol firewall allows:

• BACnet/IP — UDP 47808, both directions
• Modbus TCP — TCP 502, both directions
• Niagara FOX — TCP 1911 and 4911, both directions
• HTTPS — TCP 443, for controller web interfaces
• HTTP — TCP 80, for legacy controller web interfaces
• ICMP — for network diagnostics
• ARP — required for Layer 2 address resolution

Everything else — RDP (TCP 3389), SMB (TCP 445), SSH (TCP 22), SQL (TCP 1433/3306), FTP (TCP 21) — is dropped. The technician can interact with building controllers using standard BAS protocols and nothing else.

This does not limit the technician's ability to do their job. BACnet maintenance, Modbus register reads, Niagara Workbench connections, and controller web access all work normally. What it prevents is lateral movement, data exfiltration, and accidental exposure of non-BAS systems.

What zero trust does NOT mean for BAS

Zero trust does not mean making remote access so restrictive that technicians cannot do their work. Some common misconceptions:

• "Zero trust means no remote access." — Wrong. It means controlled, verified, monitored remote access. Technicians still connect remotely. The difference is that every session is authenticated, time-limited, protocol-restricted, and audited.
• "Zero trust requires approving every individual action." — Wrong for BAS. A technician doing a BACnet WHO-IS scan and reading 50 controller properties should not need 50 approval clicks. The session is approved. The protocol firewall ensures only approved protocols are used. The audit trail records everything.
• "Zero trust is too expensive for building automation." — The cost of implementing zero trust principles for BAS remote access is a fraction of the cost of a single BAS cybersecurity incident. Johnson Controls spent $27 million cleaning up after a ransomware attack. Per-site remote access costs are measured in hundreds of dollars per year.

A practical zero trust roadmap for building owners and integrators

You do not need to implement everything at once. Here is a phased approach:

Phase 1: Eliminate shared credentials (Week 1)

Replace any shared VPN accounts with individual technician authentication. Every person who accesses the building network should have their own credentials. If your current VPN does not support per-user accounts, this is a strong signal that the tool needs to change.

Phase 2: Implement time-limited sessions (Week 2-4)

Move from persistent VPN connections to time-limited sessions. Even if you cannot implement protocol firewalling yet, limiting session duration to 8-24 hours and requiring re-authentication eliminates standing access — the single highest-risk factor in OT remote access.

Phase 3: Add protocol restrictions (Month 2)

Deploy protocol-level firewalling that restricts remote sessions to BAS protocols only. This requires a remote access platform that operates at the bridge level (Layer 2) with protocol awareness. It is the control that most clearly separates BAS-specific remote access from generic VPNs.

Phase 4: Enable monitoring and audit (Month 2-3)

Implement per-protocol traffic monitoring with real-time visibility. Generate session audit reports for every remote access event. This satisfies the Gartner CPS SRA framework requirements and gives your compliance team the evidence they need.

Phase 5: Continuous improvement

Review session logs quarterly. Identify patterns (technicians who consistently exceed their session windows, sessions with unexpected protocol usage). Refine protocol allow-lists based on actual usage data.

SiteConduit implements zero trust principles for building automation remote access: individual technician authentication, time-limited sessions with auto-expiry, default-deny protocol firewalling, per-protocol traffic monitoring, and compliance-ready audit trails.

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