Planning a BACnet/SC Rollout Without Breaking the Building

The protocol side of BACnet/SC is the easy part. The devices know how to connect to a hub. What they don't know is where the hub is, whether the firewall will let them reach it, who signs their certificates, or what happens when the building's only hub is on the same power strip as the coffee machine.

This is the plan I'd follow to bring SC into an occupied building without an outage. It assumes you know the moving parts from how BACnet/SC works and the certificate lifecycle from BACnet/SC certificates. If you're still deciding whether SC is right for the site at all, the introduction is the place to start — on plenty of older sites, good segmentation is the better first step.

1. Decide where the hubs live

The hub function runs on some device — a supervisor, a router, a controller or a software package. Every SC node on the network connects to it, so it's now as critical as your core switch. Choose deliberately.

• Primary hub: a device that's always on, well maintained, on UPS power, and on the network segment where the SC nodes can reach it with the fewest firewall hops. The supervisor or a dedicated router is the usual choice.
• Failover hub: a different device, on a different power circuit, behind a different switch. Every node must support a failover URI, so use it properly.
• Capacity: check the manufacturer's stated connection limit for the device hosting the hub, against the number of nodes you'll have after the last phase, not the first.

Also decide how you'll notice a failover. When the primary fails, the nodes quietly move to the failover hub and the building keeps running. That's the point — but it also means nobody may notice the site has lost its redundancy. Make “nodes connected to failover” an alarm, or at least a line on the service checklist.

2. Request the firewall rules

This is where SC is genuinely easier than BACnet/IP. Nodes make outbound connections to the hub, so the request is short:

• One TCP port inbound to the primary hub, from the SC nodes' networks.
• The same to the failover hub.
• If you use direct connections, the matching rules between those specific nodes. Most sites won't need them.

There's no standard SC port. The port is part of the hub URI — wss://10.1.10.5:443/ or wss://hub1.site.local:8443/. 443 is common, but some platforms default to 8443 or another port. Confirm what your hub actually listens on, write it in the URI, and give IT that exact number. A mismatch between the URI port and the listening port is a guaranteed “refused” on commissioning day.

Ask for three more things while you're talking to IT:

• No TLS inspection on these flows. A firewall that decrypts and re-signs TLS breaks mutual authentication, because the node sees a certificate the site CA didn't sign. Get the exemption agreed in advance, in writing.
• Idle timeouts longer than the heartbeat interval. SC connections are long-lived and quiet at night. If a firewall or NAT drops idle sessions faster than the SC heartbeat fires, you'll get drops every few minutes. Either IT extends the timeout for these flows or you shorten the heartbeat; agree which.
• The old BACnet/IP rules and their end date. During migration you'll still need UDP 47808 somewhere. Agree when those rules come out.

The BAS Port Reference lists the other building protocols you may need in the same request, and segmentation and talking to IT covers how to frame it.

3. DNS names or IP addresses in the URI

Both work. Each has a cost.

My rule: use names if the owner's IT runs reliable DNS that the BAS network can reach, and IPs if the BAS network is isolated or DNS is someone's afterthought. Whichever you choose, be consistent, and test resolution from the node's network, not from your laptop on the office Wi-Fi.

4. Write the certificate plan before you order hardware

This is the part that sinks projects, because it's a decision about people, not devices. Settle, in writing:

• Who runs the CA — ideally the owner, through IT. If it's the contractor, how is it handed over or replaced when the contract changes?
• How CSRs get signed on commissioning day and on a weekend service call.
• Validity period and renewal procedure, with renewal at least 30 days before expiry, and who gets the reminder.
• Time sync for every SC device, because a wrong clock makes a good certificate look expired.

The certificates article goes through each of these.

5. Migrate in phases, supervisory layer first

Don't switch a building over in one night. SC is a BACnet datalink, so ordinary BACnet routing lets SC, BACnet/IP and MS/TP networks coexist. Use that.

Keep a back-out plan for each phase: which devices, which settings to restore, and which firewall rules must still be open to do it. Leave the BACnet/IP path working until the SC path is proven.

6. Commissioning checks

“It shows up in the front end” is not commissioned. For each phase, check:

• Every node is connected to the primary hub, per its own SC status and the hub's connection list.
• Failover works. Take the primary hub offline in a controlled window and watch nodes move to the failover hub. Bring it back and confirm they return. This is the only way to know the failover URIs, rules and certificates on the second hub are right.
• Connections survive a quiet night. Check the next morning that nodes haven't been dropping and reconnecting — the idle-timeout fault only shows up when things are quiet.
• No unique identity is duplicated. Especially where configurations were copied between controllers: VMACs and UUIDs must be unique.
• No leftover BACnet/IP. A short capture on the BAS network, filtered on udp.port == 47808, shows any SC device still talking BACnet/IP.
• Certificate dates recorded for every device and both hubs, and clocks correct.
• Discovery and trends work end to end, through the routers, from the supervisor.

If any of these fail, the troubleshooting article has the method.

7. Documentation to hand over

• Network drawing showing hubs, routers, SC and legacy networks, network numbers and the power and switch each hub depends on.
• Hub URIs (primary and failover), ports, and whether they're names or IPs.
• Firewall rules as agreed with IT, including the TLS inspection exemption and idle timeout settings.
• Device register: device, BACnet instance, device UUID, VMAC, certificate issue and expiry dates.
• Certificate plan: CA owner, contacts, signing procedure, renewal procedure.
• What isn't covered by SC: MS/TP trunks and legacy segments, and how they're protected instead.
• Commissioning results, including the failover test and when it was done.

What to ask the owner's IT team

Before the first device arrives, I'd want answers to these:

• Who will run the CA, and who can sign a CSR outside office hours?
• What certificate validity period does your policy require?
• Will the BAS network use your DNS and time servers? Are they reachable from it?
• Which firewalls sit between the nodes and each hub, and do any of them inspect TLS?
• What idle timeout do those firewalls apply to TCP sessions?
• Where should the failover hub live so it doesn't share power or switching with the primary?
• How will remote access to the supervisor work? (See BAS remote access.)
• Who gets told when certificates are due, and who gets the alarm when nodes move to failover?

If IT wants a framework to hang all this on, IEC 62443 and NIST for BAS techs translates zones and conduits into what we actually build. And SC is only one layer: accounts, passwords and patching still matter — see default passwords and accounts and hardening supervisors and controllers.

Found a wrong number or a broken link? Tell me and I’ll fix it.