BACnet Secure Connect (BACnet SC)

BACnet Secure Connect reference covering the WebSocket and TLS transport, hub-and-spoke topology versus BBMD broadcast, node and hub roles

What BACnet Secure Connect Is

BACnet Secure Connect (BACnet SC) is a secure datalink for BACnet defined in Annex AB of the standard (added by Addendum 135-2016bj, part of the standard since ANSI/ASHRAE 135-2020; the current edition is 135-2024). It carries BACnet over a WebSocket connection (WSS, the same transport modern web services use) wrapped in TLS 1.3, with X.509 certificates authenticating both ends of every connection. Annex AB constrains the permitted cipher suites, so a general-purpose TLS library is not automatically a conforming one.

BACnet SC does not replace BACnet/IP. The standard adds it alongside the existing datalinks, and a router between a BACnet SC segment and a legacy BACnet/IP or MS/TP segment is the normal way a site adopts it. Nobody greenfields an all-BACnet SC building.

The BACnet application layer does not change. Objects, services, and properties work the same way they do on any other datalink. What changes is how messages move: instead of broadcasting on a subnet, every device opens an outbound, encrypted, authenticated connection into the network.

Addressing: URI, VMAC, and UUID

BACnet SC does not address devices by IP and port. There is no BACnet SC equivalent of UDP 47808, and the standard does not mandate a port; a hub is reached at a wss:// URI, and TLS on 443 is the common choice because it survives enterprise firewall policy.

IdentifierWhat it isWhy it matters
Hub URIThe wss:// address a node connects outbound toReplaces the subnet broadcast address as the thing you configure
VMACA 6-octet virtual MAC address identifying the node on the BACnet SC networkThe actual device address: what BACnet’s network layer binds to. Collisions must be detected and resolved
Device UUIDA 16-octet identifier assigned once, for the life of the deviceSurvives certificate rotation and readdressing, so a rotated device is still recognized as the same device

A node is addressed by its VMAC, not by a URI. The wss:// URIs are connection endpoints, for reaching a hub or for accepting a direct connection, and a node that accepts neither has no URI at all while remaining fully addressable.

Why It Matters

BACnet/IP assumes a network where broadcasts reach every participant. Enterprise IT increasingly forbids exactly that: production VLANs are segmented, UDP broadcast is blocked, and anything crossing a site boundary must be encrypted and authenticated. The traditional workarounds, a BACnet BBMD (Broadcast Management Device) per subnet with a maintained Broadcast Distribution Table plus site-to-site VPNs, add configuration surface that fails in the field.

BACnet SC removes that layer. A node’s WSS connection is outbound and TLS-wrapped, so it traverses firewalls, NAT, and cloud load balancers without inbound rules or a VPN. It is not invisible: the standard does not mandate a port, and an enterprise proxy that intercepts TLS breaks mutual authentication outright. Confirm the egress policy and whether the path inspects TLS. Certificate authentication replaces “anyone on the subnet can join,” though it authenticates who may join rather than authorizing what they may do once joined.

Hub-and-Spoke Topology

Every BACnet SC device is a node. Each node opens an outbound WebSocket to a hub, and the hub fans messages out to the other nodes. A node holds a primary hub URI and, optionally, a failover URI, and connects to one at a time; redundancy is a node-side choice, not something the hub arbitrates.

RoleFunctionDefined by
NodeOpens an outbound WSS connection to the hub; sends and receives BACnet messages over itAnnex AB node requirements
HubAccepts node connections and fans out messages; the SC replacement for the broadcast domainNM-SCH-B
Direct connect (optional)Node-to-node path that bypasses the hub when two nodes can reach each otherNM-SCDC-B
Certificate managementProvisioning and rotating device certificatesNM-SCCM-A, claimed by the provisioning tool rather than the device

Because a node’s connections are outbound, a device behind NAT or a strict firewall needs no inbound rules. That is the property that makes central hubs, cloud hubs, and multi-site deployments practical. The exceptions are the roles that accept: the hub, and any node that advertises a direct-connect URI. Both need an inbound rule and a reachable endpoint.

How BACnet SC Differs from BACnet/IP

Deciding which to use on a specific project rather than comparing attributes? See BACnet SC vs BACnet/IP: A Decision Guide.

AspectBACnet/IPBACnet SC
TransportUDP, port 47808 by defaultWebSocket over TLS 1.3 (WSS)
Discovery across subnetsBACnet BBMD with distribution-table maintenanceHub distributes broadcast NPDUs over existing connections; no IP broadcast domain
AuthenticationNone at the datalinkMutual X.509 certificate authentication
EncryptionNoneTLS 1.3 on every connection
Firewall and NAT traversalInbound rules, VPNs, or FDROutbound-only connections, HTTPS-like traffic
Operational overheadBDT tables, broadcast domainsCertificate lifecycle management

The trade is real: BACnet SC removes broadcast-era network engineering and replaces it with a certificate lifecycle the site has to own.

The Certificate Model

Each BACnet SC device carries an operational certificate signed by the site’s certificate authority, plus the CA certificate it uses to verify its peers. The node presents its certificate when connecting to the hub, and the hub presents its own back. Provisioning and rotation run over standard BACnet services (ReadProperty, WriteProperty, atomic file transfer, and ReinitializeDevice), which is the behavior NM-SCCM-A packages.

The cleanest rotation path never moves a private key: the device generates its own key pair and emits a signing request through Certificate_Signing_Request_File, which NM-SCCM-A walks service by service.

Planning the lifecycle across a building’s life, including revocation and the day the authority’s own certificate rolls over, is a separate exercise: see BACnet SC Certificate Lifecycle.

Common Failure Modes

SymptomLikely CauseFirst Check
Node never appears on the networkCertificate expired, untrusted, or clock skew breaks TLS validationCertificate validity dates and device time source
Node connects, then drops repeatedlyProxy or firewall terminating long-lived WSS connectionsIdle timeout policy on the path to the hub
Everything fails at onceHub unreachable and no failover hub configuredPrimary/failover hub reachability, and whether the node’s stack automates the fallback at all (on the CAS BACnet Stack this is a 6.x item)
Works in the lab, fails on siteEnterprise TLS inspection interfering with mutual authenticationWhether the IT path intercepts TLS

What Chipkin Provides

The CAS BACnet Stack implements BACnet SC today. The hub function (NM-SCH-B) and direct connect (NM-SCDC-B) are in the shipping stack, along with the ReadProperty, WriteProperty, atomic file transfer, and ReinitializeDevice primitives that certificate management (NM-SCCM-A) is built from. The B-SCHUB hub profile is supported today, so a device on the shipping stack can claim it in its PICS. Per-function BTL conformance is not yet verified. Two functional gaps are worth knowing before you design: automatic fallback from the primary to the failover hub URI, and fleet-wide certificate rotation tooling, are both CAS BACnet Stack 6.x items, so do not design 5.x redundancy around hub failover. See BACnet SC in the CAS BACnet Stack for what ships today and what 6.x adds.

The CAS BACnet Explorer discovers and browses BACnet SC networks the same way it does BACnet/IP.