BACnet/SC for Lighting Networks

Why lighting people should care about a BMS protocol

Lighting control systems increasingly report to the building management system: occupancy for HVAC setback, energy for measurement and verification, alarms for maintenance. Most of that traffic travels over BACnet. And the version of BACnet most buildings run, BACnet/IP, was designed for a time when the building network was assumed to be private and trustworthy.

IT departments now review building networks before anything connects, and classic BACnet/IP does not fare well in that review. BACnet Secure Connect (BACnet/SC) is the protocol’s answer. If your lighting is going to talk to your BMS in the next few years, it is worth understanding what SC changes and what it asks of you.

What’s wrong with classic BACnet/IP

Nothing, as long as the network is truly isolated and nobody with bad intentions ever reaches it. In practice, the problems are:

• No authentication. Any device on the network can read, and in many installations write, any point. There is no built-in way to prove who is asking.
• No encryption. Traffic is readable by anyone who can capture it. A packet capture of a BACnet/IP network on our Lab bench shows point names, values and commands in plain view.
• Broadcast discovery. Devices find each other by broadcasting. Broadcasts do not cross IP subnets, so multi-subnet and multi-building networks need BACnet broadcast management devices (BBMDs) configured to forward them. BBMD tables are fragile, and a misconfiguration produces either broadcast storms or devices nobody can find.
• Firewall friction. Unauthenticated UDP and broadcasts are exactly what IT teams prefer not to pass between network zones.

The usual mitigation is segmentation: put BACnet on its own VLAN, restrict who can reach it, and trust the boundaries to hold. That is still good practice. BACnet/SC goes further.

What BACnet/SC changes

BACnet/SC is defined in ASHRAE Standard 135, Annex AB. It keeps the BACnet application layer you already use, with the same objects, properties and services, and replaces how messages travel:

• TLS-secured WebSockets. Every connection is encrypted.
• Mutual authentication. Both ends of every connection present certificates. A device that cannot prove its identity cannot join.
• Hub and spoke. Nodes connect to a hub, which relays messages between them. A failover hub takes over if the primary goes down, and direct node-to-node connections are available for busy pairs.
• No BBMDs. The hub handles message distribution, including what used to be broadcasts, so the broadcast management layer goes away.
• Outbound connections. Nodes open connections to the hub, which fits the way IT teams like to manage firewalls.

BACnet/IP vs. BACnet/SC

Where lighting fits

Most lighting systems don’t speak BACnet at the fixture. They expose BACnet objects at a head-end, gateway or area controller: occupancy per zone, light level, energy, alarms and override commands. That gives you three realistic routes to BACnet/SC:

1. Native SC on the lighting head-end. The cleanest option where it exists. Ask for it in the specification and confirm how the product handles certificates.
2. An SC router in front of the lighting head-end. The lighting system speaks BACnet/IP on a small isolated segment, and a router joins that segment to the SC network. This is the most common route in existing buildings.
3. An integration layer. The lighting system publishes to an integration platform, which exposes points to the BMS over SC. Useful when you also want MQTT or an API feed for analytics.

Routes two and three leave a plain BACnet/IP segment behind the router. Keep it as small as possible: a dedicated VLAN, no other devices on it, and no route from the general network.

Certificates are the real project

Ask anyone who has deployed BACnet/SC what was hard, and the answer is rarely the protocol. It is certificates. Every node needs one, issued by a certificate authority the hub trusts, installed on the device, and renewed before it expires. Before you buy, answer these:

• Who operates the certificate authority: the owner’s IT team, the BMS contractor or an integrator?
• How are certificates installed on devices, and can that be done without the original vendor?
• When do certificates expire, and who is warned beforehand?
• When a device is replaced at 2 a.m., who issues its certificate?
• How is a compromised or decommissioned device revoked?
• Where are private keys stored, and who can reach them?

An SC network with expiring certificates and no renewal plan is a network that will go dark on a predictable date. We would rather plan for that date than discover it.

What BACnet/SC does not fix

SC secures the connection between devices. It does not make the rest of the system secure, and it is worth being clear about the gaps before anyone treats SC as a finished security project.

• It authenticates devices, not intentions. Once a node is on the SC network, it can generally read and write the same points it could over BACnet/IP. If the lighting head-end can command every HVAC setpoint in the building, it still can. Limit what each system is allowed to write at the BMS and in the head-end configuration.
• Head-ends and workstations remain targets. Default passwords, shared accounts, unpatched operating systems and remote-access tools on the lighting server matter as much as the protocol.
• Firmware still needs managing. A device with a valid certificate and outdated firmware is still a device with outdated firmware.
• Segmentation still matters. SC reduces the damage a reachable network can do. It is not a reason to put building systems on the same flat network as everything else.
• Someone still has to read the logs. Refused connections and unexpected certificates are only useful if they reach a person.

For lighting, the most common gap we find is write access. Integrations often grant broad write permissions during startup so that testing goes quickly, and nobody narrows them afterward. We close that out as part of commissioning.

Migration checklist

• Inventory every BACnet device, its firmware, and whether it supports SC natively
• Choose hub and failover hub locations, and which side of each firewall they sit on
• Choose the certificate authority and write the issuance and renewal procedure
• Identify which segments stay BACnet/IP behind routers, and isolate them
• Bench-test the lighting head-end or router with the BMS front end before cutover
• Plan the cutover system by system, with a rollback step
• Monitor certificate expiry and hub connectivity after go-live
• Update the configuration report and network diagrams

A representative scenario: a plant whose IT team said no

Consider a representative furniture plant in the Tupelo area. Its new networked lighting system was meant to send occupancy and energy data to the BMS, which a separate controls contractor maintains. The corporate IT team reviewed the design and refused to let unauthenticated BACnet/IP traffic cross between the plant floor network and the office network where the BMS front end lives.

The practical fix was an SC router in front of the lighting head-end on an isolated lighting VLAN; an SC hub and failover hub on the plant side, maintained by the controls contractor; certificates issued from a certificate authority run by corporate IT; and a renewal calendar with alerts. The BMS sees the same points it would have seen over BACnet/IP. IT sees encrypted, authenticated connections it can reason about.

What we check on the bench

Our Lab runs a BACnet test network with packet capture for security review. For any lighting-to-BMS integration, we:

• confirm what traffic leaves the lighting segment and where it goes;
• verify that SC connections are encrypted and that devices without valid certificates are refused;
• test hub failover and how quickly nodes reconnect;
• test what happens when a certificate expires or is revoked, before it happens in your building.

What we’d do

1. Specify BACnet/SC for new lighting-to-BMS integrations where IT policy requires it or the network crosses trust boundaries.
2. Accept routers as a bridge in existing buildings, with the BACnet/IP segment behind them kept small and isolated.
3. Write the certificate plan before procurement. Who issues, who renews, who is warned, who replaces.
4. Bench the combination. Lighting head-end, router or gateway, hub and BMS front end together, under packet capture.
5. Watch certificate health. We set Ledger Watch to alert on approaching expirations and dropped hub connections, alongside lighting faults.

Our cybersecurity service covers the wider network review, and Security & Data describes how our own platform handles access, encryption and data ownership.

Where to start

If your IT team has questions about how your lighting will talk to the BMS, our lighting and BMS integration service designs that connection, including BACnet/SC where it fits, and tests it on our bench before it touches your network.

Filed under: BACnet/SC · BACnet · building network security · BMS integration