BACnet Secure Connect in the CAS BACnet Stack
BACnet/IP has carried buildings on UDP broadcast for nearly three decades. That worked when a building’s network was a flat broadcast domain and the BMS (Building Management System) sat on the same VLAN as every controller. It stopped working the moment buildings started living on segmented enterprise networks, behind firewalls, or in the cloud.
BACnet Secure Connect (BACnet SC) is the standard’s answer: it trades the broadcast domain for an outbound, TLS-authenticated connection into a hub, which takes the BACnet BBMD (Broadcast Management Device), its distribution tables, and the foreign device registration that goes with them off your plate. The BACnet Secure Connect reference page has the transport, addressing model, and failure modes. It does not replace BACnet/IP; the standard adds it alongside the existing datalinks.
The CAS BACnet Stack implements BACnet SC in the shipping product today. What matters here is what you can build on right now, and what 6.x adds on top.
Which Projects Are Reaching for BACnet SC
Hospitals and life-science campuses, multi-site retail fleets watched from one console, cloud-managed buildings, and multi-tenant towers. What they share is a network the security team has already segmented, or a boundary the traffic has to cross. If your project has to pass an IT security review, BACnet SC is usually the path of least resistance.
Choosing between the two on a specific job is its own question, and BACnet SC vs BACnet/IP: A Decision Guide walks the questions that settle it.
What Chipkin Provides Today (CAS BACnet Stack 5.x)
Every BACnet SC device is a node: it carries a BACnet SC Network Port object holding its certificate files, connection state, and the hub URIs it connects out to. That object is the configuration surface; Annex AB, the BACnet SC annex of ASHRAE 135, defines no separate management protocol. The hub is a function a node enables, not a separate class of device, so one device can run the hub and carry on being an ordinary controller.
The CAS BACnet Stack ships BACnet SC now. The hub function is supported, along with the device-management services it implements on a hub port: ReadProperty, Who-Is and I-Am, Who-Has and I-Have, and DeviceCommunicationControl. Node participation and the direct-connect datalink are in the stack. Certificate management works through the ordinary BACnet services the standard specifies for it: ReadProperty to inspect certificate state, AtomicReadFile and AtomicWriteFile to move a signing request and the signed credentials, WriteProperty to bind them, and ReinitializeDevice to activate them. If you are starting a project now and you need BACnet SC, build on it.
You can claim B-SCHUB on 5.x. The BACnet SC Hub profile is supported in the shipping stack, so a device built on it today can carry the hub profile in its PICS (Protocol Implementation Conformance Statement) alongside whatever control or gateway profile it already claims. A PICS is your own declaration of what your device does, so this is not something you wait on a release for.
The API reference ships with the developer kit, which also documents which TLS library it expects and the Annex AB cipher-suite constraints that library has to satisfy. That is worth settling early: Annex AB narrows the permitted cipher suites, so a general-purpose TLS build is not automatically a conforming one. If you already have a TLS stack on your target, ask us whether it fits before you scope the port.
The CAS BACnet Explorer discovers BACnet SC networks. Point Explorer at a BACnet SC hub, watch the device list populate, and browse and debug objects the same way you would on BACnet/IP. BACnet SC encrypts the wire, so a packet capture no longer tells you what happened. Explorer hands that visibility back.
Why build on it instead of rolling your own
BACnet SC looks approachable from outside: WebSocket, TLS, certificates, all libraries your team already has. The cost is not in the transport. It is in the BVLC (BACnet Virtual Link Control) state machine, hub reconnection and heartbeat behavior, virtual MAC and UUID handling, certificate lifecycle across a deployment that outlives its commissioning engineer, and interoperability against every other vendor’s reading of Annex AB. None of that differentiates your product, and all of it is what the BTL (BACnet Testing Laboratory) will scrutinize.
The stack is a C library that runs on embedded targets, Linux, and Windows, licensed to OEMs to embed in their own products. Your team writes the application. The Annex AB argument is one we have already had.
What 6.x Adds on Top
The hub, node, and direct-connect roles all work today, and the B-SCHUB profile is claimable on top of them. What 6.x completes is the rest of the story around them: hub failover, fleet certificate rotation, and the test evidence behind the profile and BIBB claims. The 5.x BACnet SC datalink stays supported and is a sound base for a project starting today; code written against it carries forward.
Two of those are genuine feature work: hub failover and fleet rotation tooling do not exist in 5.x, and the rows below say so. The rest is evidence rather than function. As above, you can claim B-SCHUB on 5.x today. What 6.x adds there is proof: the same functions, exercised against the BACnet Testing Laboratory’s published test plans instead of a bench.
| Capability | Shipping today (5.x) | 6.x adds |
|---|---|---|
| Hub function | Yes | Test-plan coverage for the hub’s fan-out and connection handling |
| Node participation | Yes | Hub-connector failover between the primary and failover hub URIs |
| Direct connect | Yes | Test-plan coverage for the node-to-node path |
| Certificate management | Inspect, stage, bind, and activate over standard BACnet services | Fleet-wide rotation tooling |
| B-SCHUB profile | Yes | Third-party test evidence behind the claim |
The certificate-rotation tooling is the piece worth calling out. Rotation works today through the standard services listed above, and 6.x layers fleet tooling over those same primitives, so rotating certificates across a few hundred devices becomes a console operation instead of a script you maintain yourself. Buildings run for 15 or more years and will rotate every device certificate several times.
Hub failover is the other row worth reading closely. A node today points at a hub and reconnects to it; the automatic fallback to a second hub URI is a 6.x item. If you are designing the central-hub topology described above, that changes where you put your redundancy in the interim, and it is worth a conversation before you scope it.
A BTL Listing is granted to a finished product, not to a stack, so your product gets listed, not ours. What we can do is take the surprises out of it. Exercising BACnet SC against the BTL’s published test plans rather than a bench setup is the difference between a listing cycle that ends and one that keeps sending you back.
If your design leans on hub failover, that is a scoping conversation rather than a blocker. Talk to us about timing.
Reference: What the Standard Defines
The network-management behavior is factored into BIBBs (BACnet Interoperability Building Blocks), the named units of required behavior a device claims in its PICS. A -A BIBB initiates a request; a -B BIBB executes one. Two are yours to claim:
- NM-SCH-B, the hub function.
- NM-SCDC-B, the optional node-to-node direct-connect path.
Certificate provisioning and rotation sits on the other side of that split. NM-SCCM-A is claimed by the provisioning tool, which initiates; your device answers it, using the ordinary services listed earlier rather than claiming the
-ABIBB itself. Check the exact device-side row against Annex K before you write it into a PICS.
Annex L packages the hub role as the B-SCHUB device profile, the BACnet SC counterpart to B-BBMD. It stacks on top of a profile from another family, so a B-BC building controller hosting the site hub claims both.
Next Steps
Starting a BACnet SC project? Request the CAS BACnet Stack developer kit. BACnet SC is in the shipping release. The stack is licensed to OEMs, so this starts a conversation rather than a checkout.
Then, depending on where you are:
- Want to see BACnet SC running before you commit? Try the CAS BACnet Explorer. It discovers BACnet SC networks out of the box.
- Scoping a design, or need 6.x timing? Talk to our engineers about your BACnet SC roadmap.
- Working out what you actually configure? The Network Port object page documents the BACnet SC property group: hub URIs, the hub-function enable, the certificate files, the reconnect timers, and the property that tells you why a node was refused.
- Still choosing between BACnet SC and BACnet/IP? BACnet SC vs BACnet/IP: A Decision Guide walks the questions that settle it. The reference page has the attribute comparison and the failure modes.
- Designing the network around it? The BACnet Discovery and Network Architecture Reference covers what changes when the broadcast layer goes away.