BACnet Secure Connect (BACnet SC): What It Is and How It Works

BACnet Secure Connect explained: the TLS-over-WebSocket datalink, hub-and-spoke topology, the three BACnet SC BIBBs, certificates, and what the CAS BACnet Stack supports today.

What Is BACnet Secure Connect?

BACnet Secure Connect (BACnet SC) is a secure datalink for BACnet that carries traffic over a TLS 1.3-encrypted WebSocket connection instead of UDP broadcast. It is defined in Annex AB of ASHRAE 135, added by Addendum 135-2016bj and part of the standard since the 2020 edition. Each device authenticates with an X.509 certificate and connects outbound to a hub, which distributes messages to the rest of the network.

BACnet/IP with a BACnet BBMD on every subnet relaying UDP broadcasts, versus BACnet Secure Connect with one hub and outbound TLS WebSocket connections from every node

The BACnet application layer does not change. Objects and services work exactly as they do on BACnet/IP or MS/TP; what changes is how messages move between devices. And BACnet SC does not replace BACnet/IP. The standard added it alongside the existing datalinks, and most sites adopt it with a router between a BACnet SC backbone and their legacy segments.

BACnet SC was created to fix two problems with classic BACnet/IP. The first is that BACnet/IP is an open network. Traffic is plaintext and nothing authenticates the participants, so anyone with access to the subnet can monitor every message going back and forth, and send their own. BACnet SC closes that: every connection is encrypted, and a device without a valid certificate cannot join. The second problem is the BACnet BBMD (Broadcast Management Device). Getting BACnet’s broadcasts from one subnet to another meant installing and configuring a BBMD on each, with distribution tables to keep current. BACnet SC removes the need: the hub distributes messages over connections the nodes already hold, so there is nothing extra to install between networks.

Where You’d Hit BACnet SC in the Field

Take a hospital. The security team runs segmented VLANs for patient records, medical devices, and building systems, and its policy says no UDP broadcast on any of them. Traditional BACnet/IP cannot pass that review, and the BACnet BBMD workaround is exactly the configuration surface IT wants gone. On BACnet SC, every controller makes one outbound, certificate-authenticated connection to a hub. Nothing broadcasts, and the review closes.

Or take a retail chain that wants one console watching 200 stores. On BACnet/IP that plan means a site-to-site VPN and BACnet BBMD configuration for every location. On BACnet SC, each store’s gateway opens a single outbound connection to a central hub, the same way the store’s other services already reach the cloud.

Cloud-hosted head-ends and multi-tenant towers follow the same pattern: a boundary the traffic has to cross, and a security team that expects TLS with mutual authentication when it does.

What the Spec Defines

Every BACnet SC device is a node. A node carries a BACnet SC Network Port object holding its certificate files, its connection state, and the URIs of the hub it connects out to. That object is the whole configuration surface; Annex AB defines no separate management protocol. The hub itself is a function a node enables rather than a separate class of device, so a building controller can run the site’s hub while carrying on with its normal work.

Discovery still works. Who-Is and other broadcast traffic ride the nodes’ existing connections, distributed by the hub, so there is no BACnet BBMD and no distribution table to maintain.

The network-management behavior is factored into three BIBBs (BACnet Interoperability Building Blocks):

  • NM-SCH-B, the Secure Connect Hub: accepts node connections and distributes messages, handling the connect, advertisement, heartbeat, and disconnect exchanges.
  • NM-SCDC-B, Direct Connect: the optional node-to-node path used when two devices can reach each other without the hub in the middle.
  • NM-SCCM-A, Certificate Management: claimed by the tool that provisions and rotates certificates; the device answers it over ordinary BACnet services.

BACnet SC hub-and-spoke network labeled with the three BIBBs: NM-SCH-B on the hub, NM-SCDC-B on the optional node-to-node path, and NM-SCCM-A on the certificate provisioning tool

The certificate model has two halves. Each device holds an operational certificate proving its own identity, plus the issuer certificates it trusts, and both must be in place before a node can join. Provisioning them uses standard services (AtomicWriteFile, WriteProperty, ReinitializeDevice) rather than anything exotic. The BACnet Secure Connect reference page covers the addressing model and the full message set in detail.

What the CAS BACnet Stack Supports Today

The CAS BACnet Stack implements BACnet SC in the shipping product: node participation, the hub function, direct connect, and certificate management over the standard services above. It has been through our full test suite and is running on customer sites now. A device built on it today can claim the B-SCHUB hub profile in its PICS (Protocol Implementation Conformance Statement) alongside whatever profile it already carries.

Two practical notes from projects we’ve supported. Annex AB narrows the permitted TLS cipher suites, so a general-purpose TLS library is not automatically a conforming one; the developer kit documents what the stack expects. And BACnet SC encrypts the wire, which takes away the packet-capture instinct every integrator has. The free CAS BACnet Explorer hands that visibility back: point it at a hub and it discovers and browses the network the same way it does on BACnet/IP.

If you are adding BACnet to a product and BACnet SC is on the requirements list, this is well-trodden ground for us. Talk to us about what your target hardware needs.

How 6.x Expands This

In 6.x we are expanding this foundation in two directions. On features: hub-connector failover, so a node falls back automatically between its primary and failover hub URIs, and fleet certificate-rotation tooling, which turns rotating a few hundred device certificates into a console operation built on the same standard services rotation uses today. On evidence: we are exercising the BACnet SC roles against the BACnet Testing Laboratory’s published test plans, strengthening what stands behind the profile and BIBB claims. Code written against the current datalink carries forward.

Where This Lives in the BACnet Spec

BACnet SC touches a specific set of annexes, objects, services, BIBBs, and profiles. Each links to its reference page.

Annexes. Annex AB of ANSI/ASHRAE 135-2024 defines BACnet SC itself: the WebSocket transport, the message set, the permitted TLS cipher suites, and the certificate model. Annex L packages the hub role as a device profile.

Object types

  • Network Port: the whole BACnet SC configuration surface; hub URIs, certificate file references, and connection status.
  • File: holds the certificate signing request and the staged credentials during provisioning.

Services

BIBBs

  • NM-SCH-B: the Secure Connect Hub function.
  • NM-SCDC-B: the optional node-to-node Direct Connect path.
  • NM-SCCM-A: Certificate Management, claimed by the provisioning tool.

Profiles

  • B-SCHUB: the BACnet SC hub profile (Annex L), claimed alongside whatever profile the device already carries.
  • B-BBMD: the BACnet/IP broadcast-management counterpart that a BACnet SC hub replaces.

Where to Go Next

Later in this series: choosing between BACnet SC and BACnet/IP on a real project, and planning a certificate lifecycle for a building that runs 20 years.