BACnet/SC Certificates for Controls Techs: CSRs, CAs, Expiry and Renewal

Every BACnet/SC connection starts with two devices checking each other's paperwork. If the paperwork is out of date, from the wrong issuer, or checked against a clock that thinks it's 1970, the connection doesn't happen. No partial service, no warning in the graphics. The device is just gone.

Most controls techs have never had to manage certificates. On SC you will, even if someone else runs the CA, because you're the one standing in front of the dead controller. This article covers the parts in plain language, who should own what, and the habits that stop certificate expiry from becoming your Monday morning. For how certificates fit into the connection itself, see how BACnet/SC works; for the big picture, the BACnet/SC introduction.

The parts, in plain terms

The sequence on each device is: generate key pair → produce a CSR → CA signs it → install the operational certificate plus the issuer certificate(s). Provisioning can be done with standard BACnet services — AtomicWriteFile and AtomicReadFile to move the files, then ReinitializeDevice to apply them — or with the manufacturer's own tools. Either way, the result is the same set of files.

Why the private key never leaves the device

This is the one rule I'd want every tech to understand rather than just follow. The certificate is public. Anyone can have a copy. What makes it worth anything is that only the device holds the matching private key, so only the device can complete the handshake.

If you generate the key on a laptop and copy it to the controller, you now have two copies, and the laptop copy is on a machine that visits other sites, gets backed up to who-knows-where and eventually gets recycled. Anyone with that key file can impersonate that controller. That's why the correct flow is for the device to generate its own key and only ever send out the CSR.

Who should run the CA

This is a governance question with technical consequences, and it's the one I'd settle before any hardware arrives.

The CA is the root of trust for the whole building. Whoever controls it can issue a certificate that every device will accept. So ask: who should hold that power for the next fifteen years?

• The owner, usually through IT or a security team. This is the arrangement I'd push for. The owner keeps control when contractors change, the CA can live on properly protected infrastructure, and certificate renewal becomes part of IT processes that already exist.
• The controls contractor. Common, especially on smaller sites where IT has no appetite for it. It works, but be honest about what it means: the building's trust depends on your company's laptop and processes. If the contract changes hands, the CA has to be handed over properly or replaced — and replacing it means re-issuing every certificate on site.
• Nobody in particular. The default, and the worst option. A CA created during commissioning on someone's workstation, never backed up, owner unknown. It'll work perfectly until the first certificate expires and nobody can sign a new one.

Whichever you pick, write it down, with a name and a contact, and put it in the handover. The rollout planning article has the list of questions I'd take to the owner's IT team.

Validity and renewal planning

Every certificate has a not-before and a not-after date. The validity period is chosen by whoever runs the CA. I'm not going to give you a number, because it varies, and the right number is the one the owner's policy says. What matters is that there is an end date on every device, and someone knows what it is.

The failure mode is always the same. A site gets commissioned with every controller's certificate issued in the same week. Years later, they all expire in the same week. The first sign is a supervisor full of offline devices on a Monday, and the root cause is a date that was known the day it was commissioned.

• Track every expiry date. Operational certificates on every device, the hub devices' certificates, and the CA certificate itself. The CA certificate expiring is the worst case, because everything it signed stops being trusted at once.
• Renew well ahead. My rule is at least 30 days before expiry, earlier on large sites. You want time for the device that won't take a new file, the one that needs a site visit, and the one nobody can find.
• Stagger where you can. If certificates are issued in waves, they'll expire in waves, which is much easier to handle than a cliff.
• Put the reminder somewhere that survives staff changes — the owner's maintenance system or IT's certificate tracking, not a calendar on one person's phone.

Clocks: the quiet certificate killer

A device decides whether a certificate is in date by comparing it with its own clock. If the clock is wrong, a perfectly good certificate looks invalid. A controller that lost its time after a long power outage and came back up years in the past will reject its peers' certificates as “not yet valid”. One that has drifted forward can decide a certificate has expired early.

So time sync stops being a nicety. Every SC device needs a reliable time source, and the hub devices especially. Check the clock before you check anything else on a device that has just come back from a power event and won't connect. Time sync also matters for logs — see hardening supervisors and controllers.

What certificate faults look like in the field

In TLS 1.3 the certificates and alerts are encrypted, so a capture won't show you the reason. What you get is a pattern, and the device's own status.

The key point: a connection that closes straight after the TLS handshake starts is almost always a certificate or authentication problem, not a network one. A network problem looks different — SYNs with no answer, or a reset. The troubleshooting article goes through the full pattern method.

Replacing a controller

This is where certificates hit the day-to-day. A failed controller gets swapped. The new one has a new key pair, so it needs its own CSR signed by the site CA, and the site's issuer certificate installed. Copying the old controller's certificate won't work — it doesn't match the new private key — and it shouldn't, because that's the whole point.

So the service van needs a way to get a CSR signed on a Saturday, or the replaced controller stays offline until Monday. Plan that path before you need it. If only one person at the owner's IT team can sign, that's a single point of failure too.

Handover documentation

When you hand a BACnet/SC site over, the certificate record should be as complete as the points list. At minimum:

• Who runs the CA, with a named contact and a backup contact.
• Where the CA lives and how it's backed up. Not the key itself — the fact that it exists and who holds it.
• A register of every certificate: device, device UUID, issue date, expiry date, issuer.
• The CA certificate's own expiry date, highlighted.
• The renewal procedure step by step, including how to handle a device replacement.
• The time source each SC device uses.

None of this is exciting. All of it is the difference between a site that renews its certificates on a Tuesday afternoon and one that finds out on the day they expire.

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