BACnet/SC in a specification: what to require and how to accept it
To specify BACnet Secure Connect (BACnet/SC) in a BMS work package, state which links must use it, require a primary and a failover hub, keep the certificate authority under the owner's control, define how certificates are issued, renewed and revoked, say how BACnet/SC coexists with BACnet/IP and MS/TP, and list the acceptance tests that prove it works. BACnet/SC is a BACnet datalink option introduced by Addendum bj to ANSI/ASHRAE Standard 135-2016, approved on 18 November 2019: it carries BACnet messages over WebSocket connections secured by TLS 1.3, with mutual authentication by X.509 certificates, in a hub-and-spoke topology. Below, the requirement wording and the tests, drawn from the addendum and from public guidance.
What BACnet/SC changes
BACnet/IP and MS/TP carry no encryption or authentication of their own, so their protection rests on network segregation and filtering; the ANSSI guide on building management systems (ANSSI-PA-110, version 1.0 of 27 April 2026) devotes its Appendix B to BACnet architecture, detection and filtering. BACnet/SC moves security into the datalink. Under the addendum:
- connections are secure WebSockets ("wss" URIs, RFC 6455), and support of TLS version 1.3 (RFC 8446) is required;
- both peers perform mutual TLS authentication: each checks that the other's operational certificate is well formed, active as of the current date and not expired, not revoked if that information is available, and directly signed by one of its locally configured CA certificates;
- each node connects to a hub function, which forwards unicast and broadcast messages; nodes may also open direct connections for unicast traffic, as an option;
- every node's hub connector supports a primary and a failover hub;
- regular BACnet routing connects BACnet/SC networks with devices on other datalinks, so BACnet/SC can coexist with BACnet/IP and MS/TP.
Because WebSockets run over standard IP, the addendum's introduction also cites support for DNS host names, DHCP, IPv4 and IPv6 and network address translation.
When to require it, and when not yet
Require BACnet/SC where the products support it and where it removes a real exposure: links between controllers and the supervisory system on an IP network, links crossing shared IT infrastructure, multi-building or multi-site connections. Do not make it a blanket requirement where it cannot be delivered: field buses on MS/TP, legacy controllers without support, third-party equipment whose vendor offers only BACnet/IP. For those, keep the segregation and filtering rules of ANSSI-PA-110: recommendation R24 favours secure protocols between controller and supervisory station, R26 refers to the BACnet measures of Appendix B, and R7 recommends disabling the "Foreign Device" function and filtering the related services. The ANSSI guide itself states that a later version will extend its coverage to BACnet/SC architectures.
A workable requirement reads: "Communications between controllers and the supervisory system use BACnet/SC where the devices support it. The bidder lists, device by device, BACnet/SC support and the firmware version required. Remaining BACnet/IP flows are confined to the BMS network and filtered according to Appendix B of ANSSI-PA-110."
Certificates and their lifecycle
The addendum leaves the creation of keys and the management of the signing authority to each site, but fixes the mechanics:
- operational credentials are the device certificate, its private key and the accepted signing CA certificates; each operational certificate is directly signed by a CA present in the device's CA certificate store;
- the signing CA "shall be controlled by the site" and can be a root or an intermediate CA, chosen by site policy;
- certificate signing requests and signed certificates are exchanged in PEM format (RFC 7468) by the device's configuration tool;
- a private key is transferred only in a secured environment or over TLS;
- a reset to factory defaults, by a secure out-of-band mechanism (physical access recommended), erases operational certificates, private keys and CA certificates.
What the specification should add, because the standard leaves it to the site: who operates the CA (the owner, or a party it appoints in writing); certificate validity periods and the renewal procedure; an inventory of certificates with expiry dates, handed over at acceptance; how revocation is handled, since the addendum makes it a local matter; no manufacturer or test certificates in operation; private keys never sent by email. An expired certificate stops communication, so expiry monitoring belongs in the maintenance contract.
Architecture: hubs, nodes, coexistence
| Element | What to specify |
|---|---|
| Primary hub | Where it runs (supervisory server or dedicated device), its power backup, who administers it |
| Failover hub | A second hub on separate hardware, configured in every node; nodes return to the primary when it is restored |
| Nodes | The list of controllers and gateways on each BACnet/SC network, with their certificate and hub URIs |
| Direct connections | Allowed only where justified, and declared in the flow matrix |
| Routers to BACnet/IP or MS/TP | Their location, the networks they join, and the filtering applied on the BACnet/IP side |
| Network | BACnet/SC still runs on a segregated BMS network: encryption does not replace segmentation |
| Time | All nodes synchronised to an owner-controlled source, since certificate validity is checked against the current date |
These choices sit in the network and cybersecurity chapters of the specification; the BMS specification template shows where.
Acceptance tests
- Declarations: a protocol implementation conformance statement (PICS) for each device type, showing BACnet/SC support; the addendum requires any TLS versions or cipher suites supported beyond TLS 1.3 to be listed there.
- Certificate inventory: for a sample of nodes, the certificate is signed by the site CA and its dates match the inventory.
- Negative test: a device presenting a certificate not signed by the site CA is refused.
- Failover: stop the primary hub, check that nodes connect to the failover hub and that alarms still reach the supervisory system, then restore the primary and check the return.
- Renewal: renew one certificate by the written procedure, without loss of service.
- Factory reset: on a spare device, check that credentials are erased.
- Traffic check: a capture on the segments declared BACnet/SC shows no cleartext BACnet/IP; remaining BACnet/IP is limited to the declared segments, with Foreign Device registration disabled.
- Time: clocks on a sample of nodes agree with the reference source.
Record each result in the cybersecurity acceptance checklist; the BMS cybersecurity requirements checklist gives the other families, and the BMS commissioning and acceptance checklist shows where the session fits in the handover.
FAQ
Is BACnet/SC mandatory?
Not as such. The French BACS rules (Article R. 175-3 of the Construction and Housing Code) require interoperability, not a given protocol, and the ANSSI guide states that its recommendations are not normative unless a regulation provides otherwise. A requirement binds the contractor once the owner writes it into the specification.
Does BACnet/SC make network segmentation unnecessary?
No. It authenticates and encrypts BACnet traffic between nodes, but a compromised workstation on the same network, an exposed web interface or a permanent remote access remain risks. Keep the BMS on its own segregated network.
Can existing controllers be upgraded to BACnet/SC?
It depends on the product: some accept a firmware update, others do not. Ask bidders to state support device by device; where it is absent, a BACnet router can join the BACnet/SC network and the old segment stays filtered.