BACnet Secure Connect (BACnet/SC) Setup Guide

What Is BACnet/SC

BACnet Secure Connect is a data link layer option defined in ASHRAE Addendum 135-2016bj. It replaces the UDP broadcast model of BACnet/IP with a connection-oriented, encrypted transport built on WebSockets and TLS 1.3. Every packet between BACnet/SC devices is authenticated and encrypted end-to-end, which means building automation traffic finally gets the same security treatment that IT systems have expected for years.

BACnet/SC was designed by ASHRAE SSPC 135 specifically for building automation networks that share infrastructure with enterprise IT. It uses standard HTTPS ports (typically 443), passes through firewalls and proxies without special rules, and requires no changes to the BACnet application layer. A controller running BACnet/SC still exposes the same objects, properties, and services—the only difference is that the transport underneath is encrypted, authenticated, and routable across modern IP networks.

How BACnet/SC Differs from BACnet/IP

The differences between BACnet/SC and BACnet/IP are fundamental at the transport layer, even though the BACnet application layer above them is identical. Understanding these differences helps technicians plan deployments correctly.

The most significant operational difference is the shift from broadcasts to a hub-and-spoke model. In BACnet/IP, every device shouts on the subnet and hopes the right device hears it. In BACnet/SC, every node establishes a persistent WebSocket connection to a central hub, and the hub relays messages between nodes. This eliminates the need for BBMDs entirely and makes cross-subnet communication a non-issue.

TLS Certificate Setup

Certificates are the foundation of BACnet/SC security. Every device that participates in a BACnet/SC network must possess a valid operational certificate signed by a trusted Certificate Authority. Without correctly configured certificates, no device can connect to the hub, and no communication occurs.

Certificate Hierarchy

BACnet/SC uses a straightforward certificate model with three components:

• CA Certificate (Issuer Certificate) — The root of trust for the BACnet/SC network. The CA's public certificate is installed on every device and hub so they can verify each other's operational certificates. This can be a self-signed CA created specifically for the BAS, or it can be issued by an organizational PKI. BACnet/SC does not require a publicly trusted CA.
• Operational Certificate — Issued to each device and hub. Contains the device's public key, its identity information, and the CA's signature. During the TLS handshake, each peer presents its operational certificate, and the other peer validates that it was signed by the trusted CA.
• Private Key — Generated on the device itself (ideally never exported). The device uses this key to prove it owns the operational certificate during the TLS handshake.

Certificate Provisioning Workflow

The standard provisioning process follows these steps:

1. The device generates a key pair (public and private) locally.
2. The device creates a Certificate Signing Request (CSR) containing its public key and identity information.
3. The technician exports the CSR and submits it to the Certificate Authority.
4. The CA signs the CSR and returns a signed operational certificate.
5. The technician imports the signed operational certificate back into the device.
6. The CA's public certificate (issuer certificate) is installed on the device so it can validate other peers.

Some platforms—such as the Cimetrics SbC4000 appliance—combine the hub and CA functions into a single device, which simplifies provisioning significantly. The technician generates the CSR on the field device, uploads it to the SbC4000 web interface, and downloads the signed certificate in one workflow.

Certificates have an expiration date. Plan a renewal process before the first certificates expire. If an operational certificate expires, that device loses connectivity to the BACnet/SC network immediately.

Hub and Node Configuration

BACnet/SC uses a hub-and-spoke topology. One device on the network is designated as the primary hub, and every other device connects to it as a node. The hub does not generate BACnet traffic of its own (unless it also functions as a controller)—its role is to accept WebSocket connections from nodes and relay messages between them.

Primary Hub Setup

The primary hub must be a device or appliance that supports the BACnet/SC hub function. During configuration, you will:

1. Enable the hub function on the device (typically a checkbox or toggle in the engineering tool).
2. Import the CA certificate so the hub can validate connecting nodes.
3. Import the hub's own operational certificate and associate it with the hub's private key.
4. Configure the WebSocket listening URI—for example, wss://10.1.10.5:443/bacnet-sc-hub.
5. Verify the hub is listening and accepting TLS connections on the configured port.

Failover Hub Setup

BACnet/SC strongly recommends deploying a failover hub on a separate device. If the primary hub goes offline, every node automatically reconnects to the failover hub without technician intervention. The failover hub configuration mirrors the primary hub: it needs its own operational certificate, the CA certificate, and a WebSocket listener. Each node is configured with the URI of both the primary hub and the failover hub.

Place the failover hub on a different physical device, a different subnet, or a different controller chassis to avoid a single point of failure. If both hubs share a single power feed or network switch, the failover provides no real protection.

Node Configuration

Every BACnet/SC device that is not a hub operates as a node. Node configuration requires:

• The device's signed operational certificate and private key
• The CA certificate (issuer certificate) for validating the hub
• The WebSocket URI of the primary hub
• The WebSocket URI of the failover hub
• A connection timeout value (default is typically 10 seconds; the standard supports 5–300 seconds)

Once configured, the node initiates an outbound WebSocket connection to the primary hub. The TLS handshake occurs automatically—the node presents its operational certificate, the hub validates it against the CA, and a secure channel is established. From that point forward, all BACnet traffic flows through the encrypted WebSocket connection.

WebSocket Configuration

BACnet/SC mandates the use of WebSocket Secure (wss://) connections—plain WebSocket (ws://) is not permitted. The WebSocket layer sits on top of TLS 1.3, which in turn runs over standard TCP. This means BACnet/SC traffic looks like ordinary HTTPS traffic to firewalls and network equipment.

URI Format

The hub's WebSocket URI follows this format:

wss://<hub-ip-address>:<port>/<path>

Example:
wss://10.1.10.5:443/bacnet-sc-hub
wss://bacnet-hub.building.local:8443/sc

The port defaults to 443 if omitted. Some controllers (particularly Linux-based edge devices) cannot bind to ports below 1024 without elevated privileges. In those cases, use a port above 1024 (such as 8443) and configure nodes accordingly.

Firewall and Proxy Considerations

Because BACnet/SC uses outbound HTTPS connections on port 443, it passes through most enterprise firewalls without additional rules. However, some environments require attention:

• Web proxies — If the network forces all HTTPS traffic through a web proxy, the proxy must support WebSocket upgrades (HTTP 101 Switching Protocols). Many older proxy appliances do not.
• Deep packet inspection (DPI) — Some firewalls inspect TLS traffic by decrypting and re-encrypting it with their own certificate. This breaks BACnet/SC mutual authentication because the device will see the firewall's certificate instead of the hub's operational certificate. Exempt BACnet/SC traffic from TLS inspection.
• Idle connection timeouts — Enterprise firewalls may drop idle TCP connections after a timeout period. BACnet/SC includes heartbeat mechanisms, but verify that the firewall's idle timeout exceeds the heartbeat interval.

Dual-Stack Considerations

Most real-world BACnet/SC deployments will coexist with BACnet/IP and MS/TP for years. BACnet/SC does not replace existing data link layers—it complements them. A building may have BACnet/SC on the supervisory backbone, BACnet/IP on the floor-level controllers, and MS/TP on the terminal units, all interconnected through BACnet routers.

BACnet Router Between SC and IP

Devices on BACnet/SC and BACnet/IP cannot communicate directly—they are separate BACnet networks at the data link layer. A BACnet router that supports both BACnet/SC and BACnet/IP is required to bridge them. The router appears as a node on the BACnet/SC hub and as a standard BACnet/IP device on the IP subnet. It translates messages between the two data link layers transparently.

Contemporary Controls, Cimetrics, and several major OEMs offer BACnet routers that bridge SC, IP, and MS/TP. When planning a migration, identify which devices will be upgraded to BACnet/SC natively and which will remain on BACnet/IP behind a router.

Migration Strategy

A phased approach works best:

1. Phase 1 — Deploy the CA infrastructure, primary hub, and failover hub. Install BACnet/SC routers to bridge existing BACnet/IP segments.
2. Phase 2 — Upgrade supervisory controllers and head-end servers to BACnet/SC. These devices benefit the most from encrypted transport because they carry the highest-value data.
3. Phase 3 — As field controllers are replaced during normal lifecycle upgrades, specify BACnet/SC-capable models. Over time, the BACnet/IP segments shrink and the BACnet/SC network grows.

There is no need to decommission BACnet/IP entirely. The standard explicitly supports indefinite coexistence through BACnet routing.

Common Mistakes

• Letting operational certificates expire without a renewal plan. Unlike BACnet/IP, which works indefinitely once configured, BACnet/SC devices stop communicating the moment their certificate expires. Set calendar reminders for certificate renewal at least 30 days before expiration. Some CA platforms support automated renewal, but many BAS deployments rely on manual processes that are easy to forget.
• Installing the wrong CA certificate on a device. If a node has CA Certificate A but the hub's operational certificate was signed by CA Certificate B, the TLS handshake fails silently. Every device and hub in the same BACnet/SC network must trust the same CA. When troubleshooting connection failures, verify the CA certificate on the node matches the CA that signed the hub's operational certificate.
• Using a port below 1024 on a platform that does not support it. Some Linux-based controllers and edge devices cannot bind to privileged ports (below 1024) without root access. If the hub is configured on port 443 but the operating system blocks the binding, the hub listener never starts and no nodes can connect. Use port 8443 or another high-numbered port on these platforms.
• Placing both the primary and failover hub on the same device or power circuit. The failover hub exists to maintain network operation when the primary hub is unavailable. If both hubs share the same controller, the same network switch, or the same UPS, a single failure takes out both hubs and the entire BACnet/SC network goes offline.
• Forgetting to exempt BACnet/SC from TLS inspection on the firewall. Enterprise firewalls that perform deep packet inspection replace the server's TLS certificate with the firewall's own certificate during inspection. BACnet/SC devices perform mutual certificate authentication and will reject the substituted certificate, causing every connection attempt to fail. Add a bypass rule for BACnet/SC hub addresses.

Platform Compatibility

BACnet/SC support is growing across the building automation industry. The following platforms have announced or shipped BACnet/SC capabilities:

Before specifying BACnet/SC for a project, confirm the exact firmware or software version required for each device. BACnet/SC is a relatively new addition, and many controllers require a firmware update or a specific license to enable it. Check each manufacturer's release notes and the BACnet International BTL listing for current certification status.

Source Attribution

This guide draws on technical documentation from the following sources:

• BACnet International — BACnet Secure Connect Overview
• ASHRAE SSPC 135 — BACnet Secure Connect: A Secure Infrastructure for Building Automation (Whitepaper)
• Cimetrics — What You Need to Deploy a BACnet/SC Network
• Johnson Controls — BACnet/SC Management (Metasys Documentation)
• Contemporary Controls — Interfacing BACnet/IP and MS/TP to BACnet Secure Connect
• DEOS AG — BACnet/SC: Simply Explained
• Automated Logic — BACnet Secure Connect (WebCTRL)
• ASHRAE Standard 135-2016, Addendum bj — BACnet Secure Connect Data Link Layer