Is BACnet/SC backward compatible with existing BACnet/IP devices?

BACnet/SC is not directly backward compatible at the data link layer — a BACnet/IP device cannot speak WebSocket/TLS. However, backward compatibility is achieved through BACnet/SC Routers that bridge between the SC network and legacy BACnet/IP or MS/TP networks. In a mixed deployment, legacy BACnet/IP controllers remain on their existing UDP network while a SC Router connects that network to the BACnet/SC hub. SC-aware devices on the new network can then communicate with legacy devices through the router. This allows a phased migration without replacing all field devices simultaneously.

What happens to BACnet/SC communication if the hub goes offline?

BACnet/SC defines a Primary Hub and a Failover Hub for exactly this scenario. If the Primary Hub becomes unreachable (determined by heartbeat timeout, typically 30–60 seconds), devices automatically reconnect to the Failover Hub. If both hubs are offline, BACnet/SC devices cannot communicate with other SC devices — the network goes dark for inter-device communication. This is a key architectural difference from BACnet/IP where devices on the same subnet can communicate without any central infrastructure. For critical control applications, local autonomous control logic in field panels must be maintained as a fallback to handle hub outages gracefully.

How are BACnet/SC device certificates issued and managed?

Each building deploys a private Certificate Authority (Building CA) that issues X.509 certificates to BACnet/SC devices. The process involves: (1) generating a key pair on the device (or on a secure provisioning workstation), (2) creating a Certificate Signing Request (CSR) containing the device's BACnet Device ID in the SAN field, (3) submitting the CSR to the Building CA for signing, (4) installing the signed certificate on the device. Certificate provisioning can be done during factory commissioning, at installation via a secure provisioning tool, or remotely via SCEP/EST protocols. Certificates typically have 1–3 year validity periods and must be renewed before expiry — automated renewal workflows are strongly recommended for large portfolios.

Does BACnet/SC support direct device-to-device connections or only hub routing?

The base BACnet/SC specification uses hub routing for all traffic. However, Addendum bj also defines "Direct Connections" via the Node Switch mechanism, where devices with sufficient IP connectivity can establish direct WebSocket connections to each other, bypassing the hub. Direct connections reduce latency and hub load for high-frequency point-to-point data exchanges. However, direct connections still require mutual TLS authentication — a device cannot bypass certificate verification just because it is connecting directly. Not all BACnet/SC implementations support Node Switch; check vendor documentation for this optional feature.

When will BACnet/SC be widely available in commercial BMS hardware?

As of 2025, BACnet/SC is included in the ASHRAE 135-2020 standard (Addendum bj, formally approved 2021). Major vendors including Johnson Controls, Siemens, Honeywell, Schneider Electric, and Distech Controls have announced or released BACnet/SC support in their controller firmware or new hardware generations. Full ecosystem maturity — where most new field controllers ship with native SC support — is expected by 2026–2027. The BACnet Testing Laboratories (BTL) began adding BACnet/SC to their conformance test suite in 2023. For new high-security projects, designers should specify BACnet/SC in bid documents now and verify vendor support during procurement.

← Smart Buildings Studio

Engineering·10 min read·May 15, 2025

🏢 BACnet/SC: Encrypted BACnet over WebSocket for Modern Building Networks

A complete guide to BACnet/SC (Secure Connect) — the ASHRAE Addendum bj to BACnet Standard 135 that replaces UDP multicast with encrypted WebSocket tunnels, TLS 1.3, and certificate-based device authentication.

Why BACnet Needed a Security Overhaul

BACnet/IP, the dominant transport for building automation since the 1990s, was designed for isolated facility networks where security was an afterthought. It relies on UDP broadcasts and multicasts, has no built-in encryption, and authenticates devices only by IP address — a trivial spoofing target. As buildings connect to enterprise IT networks and cloud services, the attack surface has expanded dramatically. Vulnerabilities disclosed by researchers (including unauthenticated write access to BACnet devices on internet-exposed port 47808) have pushed the industry toward a proper security architecture.

BACnet/SC (Secure Connect), standardized as Addendum bj to ASHRAE Standard 135-2020, replaces the UDP-based BACnet/IP transport with encrypted WebSocket connections, mutual TLS 1.3 authentication, and a hub-and-spoke topology that eliminates the broadcast domain entirely.

Architecture: Hub-and-Spoke over WebSocket

BACnet/SC introduces a new network architecture built around BACnet/SC Hubs:

Every BACnet/SC device establishes one or more outbound WebSocket (WSS) connections to a Primary Hub and optionally a Failover Hub.
All BACnet messages between devices are routed through the hub — direct peer-to-peer UDP is eliminated.
The hub acts as a message router, not a proxy: it forwards BACnet PDUs between connected nodes but does not interpret or modify BACnet application content.
A BACnet/SC Node Switch can optionally enable direct connections between nodes that bypass the hub for latency-sensitive applications.

This topology maps naturally to existing enterprise IT network architectures: WebSocket connections traverse NAT and firewalls without requiring special UDP port forwarding or BBMD configuration — one of the most frustrating aspects of deploying BACnet/IP across routed networks.

Security Mechanisms: TLS, Certificates, and Device Identity

Every BACnet/SC connection is protected by multiple security layers:

TLS 1.3 — All WebSocket connections use TLS 1.3 as the transport encryption layer, providing forward secrecy via ephemeral Diffie-Hellman key exchange. TLS 1.2 may be permitted as a fallback but is discouraged.
X.509 Device Certificates — Each BACnet/SC device is issued a unique X.509 certificate signed by a Building CA (Certificate Authority) administered by the building owner. The device's BACnet Device ID is embedded in the certificate's Subject Alternative Name (SAN) field, cryptographically binding the logical BACnet identity to the physical device.
Mutual TLS (mTLS) — Both the client device and the hub authenticate each other during the TLS handshake. A device without a valid certificate signed by the building CA cannot join the BACnet/SC network, eliminating rogue device attacks.
Operational Certificate Store — Devices maintain a local store of trusted CA certificates and can be provisioned with revocation lists (CRLs) or OCSP endpoints for real-time certificate validation.

BACnet/SC Message Flow

The BACnet/SC data link layer wraps standard BACnet NPDUs (Network Protocol Data Units) in a new header format called the BACnet/SC BVLC Header (BACnet Virtual Link Control). Key message types include:

BVLC-Connect-Request / BVLC-Connect-Accept — Hub connection establishment after TLS handshake
BVLC-Encapsulated-NPDU — Standard BACnet NPDU wrapped for hub routing
BVLC-Address-Resolution — Replaces BACnet/IP's Who-Is broadcast for device discovery within the SC network
BVLC-Advertisment — Devices announce their presence and supported connection types to the hub
BVLC-Heartbeat-Request / Response — Keepalive messages to maintain WebSocket connection state through NAT and load balancers

Coexistence with BACnet/IP and MS/TP

BACnet/SC is a new data link layer, not a replacement for the entire BACnet protocol stack. Existing BACnet/IP and BACnet MS/TP (RS-485) networks remain fully valid BACnet networks. Interoperability between BACnet/SC and legacy BACnet networks is achieved through BACnet/SC Routers:

A SC Router bridges a BACnet/SC network (WebSocket side) to a BACnet/IP or MS/TP network (legacy side).
The router handles address translation between the SC Address space (based on device VM-UUIDs) and the legacy BACnet network addresses.
Most major BAS manufacturers (Johnson Controls, Siemens, Honeywell, Distech, Schneider) plan to ship SC-capable field panels and routers by 2025–2026 via firmware updates or new hardware generations.

For new greenfield projects, a fully native BACnet/SC architecture is now recommended by ASHRAE and CISA (Cybersecurity and Infrastructure Security Agency) for any building connected to enterprise IT or cloud services.

Hub Deployment Considerations

The BACnet/SC Hub is a critical infrastructure component and must be deployed with appropriate resilience:

High availability — BACnet/SC defines a Primary Hub and Failover Hub. Devices automatically reconnect to the Failover Hub if the Primary Hub becomes unavailable. Hub failover detection uses the heartbeat timeout, typically configured at 30–60 seconds.
On-premises vs. cloud hub — Hubs can be deployed on-premises (a server in the building's IT room) or in the cloud (AWS, Azure). Cloud deployment enables consolidated multi-building management but requires reliable internet connectivity and introduces latency for time-critical control loops.
Certificate management — The building owner must operate or contract a PKI to issue and renew device certificates. Certificate validity periods of 1–3 years are common; automated renewal (ACME protocol or SCEP) is strongly recommended to avoid certificate expiry outages.
Firewall rules — BACnet/SC uses TCP port 443 (WSS) or 9999 (alternative). Enterprise firewalls can allow outbound WebSocket connections to the hub without opening inbound UDP ports — a major security improvement over BACnet/IP.

BACnet/SC and CISA Guidelines

CISA has identified BACnet/IP systems exposed to the internet as a critical OT vulnerability. CISA Advisory AA22-103A specifically recommends isolating BACnet systems from internet-routable networks and implementing encryption and authentication. BACnet/SC directly addresses these recommendations by design. Building owners subject to NERC CIP, NIST SP 800-82, or IEC 62443 compliance frameworks should document their BACnet/SC deployment as evidence of OT network segmentation and authentication controls.

Topics covered

BACnet/SCBACnet Secure ConnectASHRAE 135BACnet WebSocketBACnet encryptionbuilding automation securityTLS 1.3certificate authenticationBACnet hubBACnet/IPBBMDbuilding automation protocolOT securityBAS network

🛠️ Related Free Tools

Put this knowledge to work on your iPhone

Browse our full catalog of professional iOS apps — from electrical code tools to AI builders.

Browse All 95+ Apps