BACnet SC vs BACnet/IP: Which Should This Project Use?
Use BACnet Secure Connect (BACnet SC) when the network is segmented, when traffic crosses a firewall or a site boundary, or when a security review sits in the path. Stay on BACnet/IP when the network is flat, the devices already speak it, and nobody is asking for certificates. BACnet SC does not replace BACnet/IP: the standard adds it alongside the existing datalinks, so on any given job you are choosing, not migrating. The choice only stays cheap where both transports already live in the same product, which makes this as much a purchasing question as a network one.
Four questions settle which case you are in. A fifth decides whether you can live with the answer.
Does the equipment you are specifying support BACnet SC?
Ask this first, because it ends most conversations. You are usually choosing from controllers the mechanical contractor already bought, and BACnet SC today is concentrated in supervisory and plant equipment rather than field-level product. Most VAV boxes and unitary controllers still ship MS/TP or BACnet/IP. If the head-end will not speak BACnet SC either, the decision is already made.
This is a backbone decision more than a building-wide one. The points behind an MS/TP trunk are unaffected by what the backbone runs.
Is the network segmented?
BACnet carries discovery by UDP broadcast, which assumes every participant shares a broadcast domain. Cross a subnet and the usual answer is a BACnet BBMD (Broadcast Management Device) relaying broadcasts, with a Broadcast Distribution Table on each one.
BACnet SC removes the IP broadcast domain, not broadcast itself. Who-Is still works; the hub distributes broadcasts over the nodes’ existing outbound connections instead of relying on UDP, so there is no BACnet BBMD and no distribution table to maintain. If IT has already segmented the network, that is the layer you stop fighting. The BACnet Discovery and Network Architecture Reference covers the broadcast mechanics on the BACnet/IP side of this trade.
Who is allowed to join?
BACnet/IP has no authentication at the datalink. Anyone who can reach the subnet can speak BACnet on it. BACnet SC authenticates both ends of every connection with X.509 certificates over TLS 1.3, using the cipher suites Annex AB permits.
A cut sheet that says “supports BACnet SC” is not the end of this question. Multi-vendor BACnet SC interop is young next to nearly three decades of BACnet/IP, and two devices at different addendum revisions can both claim support and still refuse each other. Read the device’s PICS knowing it is the vendor’s own declaration, treat a BTL listing as the only third-party evidence in the pile, and ask what has actually been tested against what. “Tested against the hub you are actually buying” is worth more than either.
Be precise about what that buys: BACnet SC authenticates who may join. It does not authorize what they may do once joined. Annex AB has no per-object access control, so “anyone on the network can write” is still true. The network is just much harder to get onto.
Does traffic cross a boundary?
A firewall, a NAT device, a proxy, or a site edge. BACnet/IP crosses those with inbound rules, VPNs, or foreign device registration. BACnet SC nodes connect outbound, so a controller behind a strict firewall needs no inbound rules. The exceptions are the roles that accept: the hub, and any node advertising a direct-connect URI. (Direct connect is the optional path that lets two nodes talk without going through the hub, for latency or to keep local traffic local.) Both need an inbound rule and a reachable endpoint.
It is not invisible, though, and the egress path is where BACnet SC projects go wrong. See What BACnet SC Actually Costs You to Run before you commit.
Who owns the operational cost, and which cost do they want?
The question people skip, and the one that bites. Neither transport is free to run. BACnet/IP costs you BACnet BBMD and broadcast-domain configuration. BACnet SC costs you a certificate lifecycle. You are choosing which kind your site is staffed to carry.
What BACnet SC Actually Costs You to Run
What a decision guide owes you, none of which appears in a feature comparison:
- You lose the wire. Your BACnet/IP diagnostic instinct is a laptop, a span port, and Wireshark, because the traffic is broadcast and plaintext. On BACnet SC it is an encrypted WebSocket. Troubleshooting moves to the hub’s connection status and its record of refused connections, which you read through BACnet rather than a capture. Plan for who owns that visibility.
- The clock and DNS become load-bearing. A controller whose clock drifted or reset cannot authenticate, and hub URIs are usually names, so name resolution joins the outage path too. BACnet/IP needed neither, and both fail in ways that look like a BACnet problem at 2am.
- TLS inspection will find you. A corporate proxy that intercepts TLS breaks mutual authentication outright, and because the standard does not mandate a port, you cannot hand IT a standard ask (443 is often chosen, but it is a convention rather than a requirement). On a campus with an inspecting proxy this turns a commissioning day into a multi-week ticket with a team that does not believe you. Settle it before the devices ship.
- The failure concentrates. On a segmented BACnet/IP network the failure is distributed across your BACnet BBMDs: lose one and you lose that subnet’s cross-subnet discovery. BACnet SC concentrates it in the hub. Nodes can carry a failover hub URI as well as a primary, so the redundancy is designed in, but it is redundancy you specify, verify, and budget for rather than a property you inherit. Two questions to ask: how the hub behaves on restart when every node reconnects at once, and how many nodes one hub is good for.
- You inherit a certificate lifecycle, and someone has to own it. Every node and the hub holds a certificate, and every certificate expires. Whoever signs them is in the loop for every new device and every rotation from then on. You traded a table you control for a queue you do not.
That lifecycle is the single largest piece of work BACnet SC adds, and it runs for the life of the building rather than the length of the commissioning contract. What it costs and who owns it is the thing to settle before you commit, not after.
When BACnet/IP Is Still the Right Answer
BACnet SC is not an upgrade you owe every building.
| Situation | Why BACnet/IP still wins |
|---|---|
| Field devices that do not speak BACnet SC | The dominant real-world reason, and it is not a legacy problem |
| Flat, single-subnet network | No broadcast problem to solve, so the hub buys you nothing |
| Legacy retrofit | Working BACnet/IP controllers would need replacing or gatewaying |
| You need to read the wire | Plaintext broadcast is a durable operational advantage, not an artifact |
| Bench commissioning | A laptop and a patch cable is enough; a BACnet SC device needs certificates before it talks BACnet SC to anything |
When to Use BACnet SC
Reach for BACnet SC when the network the building sits on is not yours to flatten.
That case is easy to underweight from a table, so here it is concretely. On a segmented enterprise network, the BACnet/IP answer is an exception request: a broadcast rule IT does not want to grant, sitting in a queue for six weeks, renewed at every audit, and re-argued every time the security team changes. BACnet SC ends that argument by not needing the exception. The certificate lifecycle is real work, but it is work you schedule. The exception queue is work you beg for, and you lose it eventually.
| Situation | Why BACnet SC wins |
|---|---|
| Segmented enterprise network | IT’s segmentation stops being something you file exceptions against. BACnet BBMDs and distribution tables leave the drawing entirely |
| Hospitals and life-science campuses | Security policy already forbids UDP broadcast on production VLANs, so the argument is over before it starts |
| Multi-site fleet on one console | Nodes dial out, so no inbound rules at the sites and no site-to-site VPN. For one connection per site rather than per controller, see the router note below |
| Cloud-managed buildings | The edge already opens outbound TLS to the platform, so BACnet SC is the same shape and clears the review instead of arguing with it |
| Multi-tenant buildings | Each tenant’s controllers authenticate independently, with cryptographic proof of which device is which |
A mixed network is normal and usually correct. A router between a BACnet SC segment and a legacy BACnet/IP or MS/TP segment is how most sites actually adopt BACnet SC, and it is also how you get one connection per site: the site device runs the hub function for its local nodes and is a node on the central network, routing between the two. Hubs do not chain to each other, so the router node is what connects out. Confirm the device supports both roles at once, since it means two BACnet SC ports on one device, before you draw it that way. You do not have to pick one transport for the whole building.
What Reverses Later, and What Does Not
Your engineering survives a transport change. Your install base does not. Be honest about which one you are asking about.
Reversible for the product you are building. Both transports ship in the same CAS BACnet Stack: one license, one API, one port to your target. The BACnet application layer is transport-independent by design, but that only helps if the datalink you did not pick is already in the product you shipped. Objects, properties, and services behave identically, so your point map and application logic carry over intact.
What does not carry over is anything that assumed an IP address. BACnet SC addresses nodes by a 6-octet virtual MAC. Dynamic bindings re-resolve themselves over Who-Is, but static Device_Address_Binding entries and any tooling that parsed IP and port get redone, and Broadcast Distribution Tables go away rather than migrate. The device also gains a BACnet SC Network Port object carrying the hub URIs, the hub-function enable, the certificate files, and the connection-status properties, plus a TLS build that meets Annex AB’s cipher constraints. That is a scoping question worth asking early, not an application rewrite.
Not reversible for the building. Fielded controllers that only speak BACnet/IP will never gain a BACnet SC port. Reversing at the site means a router at the boundary, replacement, or gatewaying. That asymmetry matters: going from BACnet SC back to BACnet/IP is nearly free, going the other way is a truck roll.
On the BACnet SC side, the hub function, node participation, direct connect, and the B-SCHUB hub profile are supported in the shipping stack today, and certificate rotation works now through the standard BACnet services described above. What 6.x adds is the tooling that turns rotation into a console operation across hundreds of devices, automatic hub failover, and per-function BTL conformance. If your specification turns on any of those, talk to our engineers before you commit; that is a scoping conversation rather than something to settle from a web page. What ships today has the full split.
Next Steps
- Want to see either network before you commit? Try the CAS BACnet Explorer. It discovers BACnet SC and BACnet/IP alike, and it will show you your BACnet BBMD topology and broadcast domains as they actually are rather than as documented.
- Building the device rather than specifying it? Request the CAS BACnet Stack developer kit. Hub function, node, and direct connect ship next to BACnet/IP and MS/TP under one license and one API, so supporting both transports is one integration rather than two.
- Still deciding? Talk to our engineers about the specific project, the equipment list, and who would own the certificate authority.