Welcome back to How to Handshake, Optigo Networks’ podcast series on OT networking, building automation, and the conversations that actually move the industry forward.
Subscribe to the podcast on Apple Podcasts, Spotify, Deezer, and YouTube!
Is BACnet/SC the next step in OT networking?
In episode three, we’re joined by Nate Benes from the University of Nebraska — facilities operator by day, BACnet committee member by night — to dig into BACnet Secure Connect. Is it really the next step in OT networking? Should you be getting ready to migrate? And are your BBMDs headed for the recycle bin?
We get into how SC actually works, what zero trust looks like when the “user” is a VAV controller, who owns the certificate authority when an integrator hands the building back, how SC and BACnet/IP coexist, and Nate’s honest take on when to migrate — and when to leave a working building alone.
In this episode, we’re tackling:
- What BACnet/SC actually is: Not a re-architecture of BACnet — just another data link in the toolbox, alongside BACnet/IP and MS/TP. Same who-is, I-am, and read-property messages. New transport.
- Zero trust for buildings: What it means to authenticate based on who a device is rather than where it sits on the network — and how certificates make that possible.
- Certificates and the handoff: Who should hold the certificate authority when the integrator leaves the job, and why ten- and twenty-year certificate expirations are a red flag, not a feature.
- Coexistence with BACnet/IP: Whether SC and IP can run side-by-side in the same building (yes), and what an IP-to-SC router looks like.
- VPN vs. SC: Why running SC across sites can be a smaller attack surface than a sketchy VPN.
- Migration timing: When SC makes sense to deploy, when it doesn’t, and the things you should keep doing even after you’ve adopted it.
Watch the full episode here:
What topics, debates, or technical deep-dives do you think this show needs to cover? Send us a message on LinkedIn, Reddit, or Bluesky, or email us at marketing[at]optigo.net.
Transcript:
Ryan LaFlamme: On this week’s show, Nate Benes is here from the University of Nebraska to talk about BACnet/SC. Is it the next step in OT networking? Should we all be getting ready to migrate? And are my BBMDs headed for the recycle bin? I’m Ryan LaFlamme and this is How to Handshake, Episode Three.
Ryan LaFlamme: Thanks for joining us, Nate. Please introduce yourself — let us know who you are and what you do.
Nate Benes: Hi everybody. My name is Nate Benes. I work at the University of Nebraska in our operations department. I’m a facilities guy by trade, and I also do a lot of work with ASHRAE’s SSPC 135 — the BACnet Committee. Really excited to be here having this conversation with you and with Ping.
Ryan LaFlamme: Ping, you have the first question.
Ping Yao: Nate, you’re at a fairly unique organization. For those who don’t know, can you tell the world how unique it is?
Nate Benes: Nebraska has a really interesting approach to building automation. We don’t buy building automation equipment off the shelf. All of our thermostats, our system controllers — we design and develop in-house. We’ve been in this business since 1975. We just celebrated 50 years last year of doing it this way. There aren’t very many of us out there.
Ping Yao: Wow, that’s impressive. So as Ryan said, we’re going to talk BACnet/SC — Secure Connect. And from a history perspective, in the BACnet standard this is really the third incarnation of the security problem we’ve tried to solve.
Nate Benes: That’s right. BACnet has had different security features added and removed from the protocol over the years — what we call Clause 24, because that’s the part of the standard where these are defined. Historically, Clause 24 tried to give you one tool that allowed you to encrypt messages so they were private as they moved across all the different data links — BACnet/IP, MS/TP, ZigBee, whatever — and as they crossed your routers. What we found out, working with users, was that there was a lot of custom cryptography involved in that work, and it was pretty tricky to implement. So the story of BACnet/SC is kind of inspired by that experience, but it set out to accomplish a different goal.
Ping Yao: Give us the quick overview. What problem is SC trying to address, and what are the major components and terms we need to know before we dive into the weeds?
Nate Benes: BACnet/SC is one of many data links in BACnet. One of the things that’s really cool about BACnet — and one of the reasons it’s stuck around so long; it celebrated its 30-year anniversary last year — is that we can take the same back-end messages, like a who-is or a read-property, and pass them over all sorts of different transports. BACnet/IP is the one most people are familiar with. We also have MS/TP, the serial bus you’ve all seen — the twisted pair in the cabinet. Then there are some less common ones: ZigBee, ARCNET, regular Ethernet, IPv6.
So SC is just another horse in that stable. It doesn’t fundamentally re-architect anything in BACnet. It’s another tool in the toolbox. What’s cool about SC is that it’s fully encrypted point-to-point, and it can run over top of existing IT or OT networks because it operates as a hub-and-spoke model. That’s in contrast to what we’ve seen historically in BACnet/IP, which relies pretty heavily on UDP broadcasts and IP broadcasts. That has historically caused some troubles for enterprise networks.
Which kind of segues into the story of why BACnet/SC came out of the BACnet IT working group. The charter when they got started was: we’re getting all this feedback that when we go and try to deploy BACnet/IP on these big corporate networks, people don’t have a very good experience. We get a lot of pushback from IT departments and building operators that the broadcast/multicast behavior is not very popular. And BACnet is what ASHRAE calls a continuous maintenance standard, which means when we see something in the field that doesn’t serve customers well, we can go fix it. The mission of the IT working group was to make BACnet work better on corporate networks — to play well in the sandbox.
Ping Yao: Before we go further — what are the major components of a BACnet/SC network? What terms do we need to know?
Nate Benes: At the bare minimum, you need what’s called the BACnet hub. The hub is sort of special — it’s the one thing on a BACnet/SC network that everybody needs to be able to see. A BACnet hub could be in a panel inside your building, just like any other piece of building automation equipment. It could be in the cloud. What’s nice is you could have a controller running BACnet in your building, and as long as it can dial out to the hub, it’s going to be able to join the SC network and talk to everybody else. So unlike BACnet/IP, where you have to punch a bunch of firewall holes to string everything together, SC enables some really cool architectures.
Ryan LaFlamme: A lot of the conversation around BACnet/SC leans on the idea of zero trust. For folks who know it from the enterprise IT side, zero trust is a fancy way of saying “never trust, always verify” — every device and every end user has to prove who it is every time it connects. What does zero trust look like when the thing trying to talk isn’t a computer, but a VAV controller? How far can that model realistically be pushed in building automation?
Nate Benes: Great question. When I talk to people about zero trust, one thing I talk about is what it’s not. Traditionally, when we thought of an enterprise network, a lot of that security was based on where you are on the network. If I’m sitting in my office at the university, plugged into the jack on the wall, there are things I can see — file shares, internal services. If I’m on the road like I am today, I don’t have that access.
Zero trust flips that model from where you are on the network to who you are on the network. The idea is that if I can prove I’m Nate Benes, I should be able to access the same resources wherever I am. We can take that same model and bring it over to building automation. Instead of saying “anybody on this building automation VLAN can do anything they want at any time” — and I hope all your building automation equipment is on a separate network, by the way — we can say, “I’m going to issue a certificate to Ping, and a certificate to Ryan. This certificate is only good for this one BACnet/SC network. So even if you take that certificate and drive down the road to the next building, you’re not going to get very far.” We can also stamp those certificates with facts: this is only good for the next two days because I know you’re only on campus for two days. It’ll automatically expire.
Ryan LaFlamme: It’s worth noting for any students or folks new to the industry — one of the big asterisks beside BACnet has always been that it’s unencrypted. It relies on the security umbrella of your IT department if you’re operating over IP. A lot of people see SC as a necessary response in 2026 to having such a critical section of building operations essentially naked to the outside world.
Nate Benes: This comes up a lot. We think, hey, my office is secure — there’s a lock on the door, no one’s going to come plug in under my desk. But the one that gets people isn’t necessarily malice. It’s misconfigurations and misunderstandings. One of the most terrifying things you can find in a cabinet is a duplex Ethernet jack — one wall plate, two unlabeled jacks. You’re two inches from disaster on that plug. Those are the kinds of things I think about: how do I make buildings easier to operate? How do I reduce the risk of someone making a catastrophic mistake on a Friday afternoon?
Ryan LaFlamme: Let’s talk about BBMDs. In a traditional BACnet/IP network we have UDP broadcasts and BBMDs doing a ton of the heavy lifting. The hub-and-spoke model in SC, in theory, does away with BBMDs. How does that change how you architect or topologize a network?
Nate Benes: When I talk to my students, I describe BACnet networks like a group chat. I can choose to text one device directly, or I can send a message to the whole group chat — that gets all 20 thermostats. Where it gets us into trouble is when devices are spread across two different IP subnets. Now we’ve got two different group chats. If I want to invite everybody to the party, something has to make sure that message gets passed over. So you designate somebody on each network and say, “you have a new hobby — anytime you hear a broadcast, take a copy and pass it to the other group chat.” That’s a BBMD.
In the best of times, these things work great. Where you can get into a lot of trouble is when they’re misconfigured. One of the really popular things to do is accidentally set them up in a ring, so a message gets passed around a couple of times. Or you accidentally split the network so messages can get distributed one way and not the other. With BACnet/SC, the deployment is simplified because — except for the hub — everybody is an equal peer talking to the hub. There’s no “I’m on the main network and you’re on the secondary network.” So yes, BACnet/SC does do away with the need for BBMDs.
The other nice contrast is that, in a typical setup, a BBMD is a single point of failure. If it’s rebooting, going down for updates, or something catastrophic happens, those networks split and can’t talk to each other anymore. When we designed BACnet/SC, it actually supports a primary/failover architecture. You can configure all your devices with a primary hub and a failover hub, so if something bad happens to the primary, here’s where we all agree to meet as a backup.
Ping Yao: Let’s dig into certificates. Where does a certificate sit? Who’s responsible for maintaining it? Does it sit on devices, on the hub, on both?
Nate Benes: Everyone who wants to participate in a BACnet/SC network — whether they’re a hub or just a regular node — needs their own certificate and their own private key. All the certificates in a particular network are signed by the same certificate authority. How those get managed, how often they get updated, how often they expire — that depends on your installation and how you want to operate the building.
This is Nate’s personal opinion now, but I think one of the disastrous things that happened when SC first came out — and one of the anti-patterns to look out for as an integrator — is the concept that we should have certificates that expire five, ten, twenty years in the future. It’s foolish to say the building will never change. No point in the next twenty years will a device ever have to be replaced or join the network? There’s a saying: if it hurts, you should do it more. If you’ve got a process at work that’s not working for you, maybe you just need more practice. In a really mature, well-run BACnet/SC network, those certificates don’t last very long. They’re getting changed out and updated all the time. And this is very automatable — you can put a new certificate in a device over the protocol itself and instruct the device to switch over. Renewal and replacement is baked right into the protocol.
Ryan LaFlamme: Most sites aren’t going to rip out every controller on day one. They’re going to want to run their existing BACnet/IP equipment alongside BACnet/SC for as long as they can — we’ve seen this with MS/TP and IP. So in practice, how do those two networks talk to each other during an overlap?
Nate Benes: What’s cool about BACnet is that it’s always been built around the idea that you’ll have multiple networks and multiple data link technologies running at the same time. Most listeners are probably familiar with IP-to-MS/TP routers. Just like that, you can have an IP-to-SC router. You could theoretically have an MS/TP-to-SC router. Any permutation of data link technology. There’s no reason these things can’t run concurrently. Even in a new building you design, there are plenty of places where one data link makes more sense than another.
Ping Yao: Is BACnet/SC realistic for smaller and mid-size buildings, or is this really a large-portfolio-or-campus conversation?
Nate Benes: It can definitely work for smaller deployments. If you had small sites you wanted to connect back to a home office — maybe to do energy readings across a portfolio — it would absolutely work. There’s no technical reason it wouldn’t. It just depends on what your integrators and local vendors are comfortable with.
Ping Yao: A lot of sites today are connected to the web through some combination of VPN and other tooling. Does BACnet/SC eliminate the need for a VPN, work in conjunction with one, or is one a replacement for the other?
Nate Benes: One thing to consider is: when I connect a building over SC, the only information going through that pipe is BACnet packets. When I connect it over a VPN, then I have to ask what firewalls are in place, what kinds of traffic can pass through. Can an attacker who connects to the VPN get into my building and then jump laterally from a building automation controller to a payment system? We’ve seen that very famously in the wild. With a hub in the cloud, the worst case — which is still a bad thing — is that an attacker is sending BACnet packets into the network. They’re not pivoting from that to take files from a corporate file share.
Ping Yao: You’re very involved with the standard, and the committee meets regularly. What’s not covered by the standard that listeners should keep in mind? What are some things their vendors and integrators are responsible for?
Nate Benes: And another way to put it: just because something isn’t covered by the standard doesn’t mean it’s not interoperable. BACnet/SC tells you how to use the certificates. It tells you how the traffic passes over WebSockets, over TLS. It gives you a procedure to update and replace certificates as they expire. What it doesn’t tell you is how long those certificates should last. It doesn’t tell you who should hold the key to issue new certificates. It doesn’t tell you what shape of network to build. Those are left up to your judgment, or your integrator’s judgment.
Ping Yao: Let’s get concrete. With MS/TP, I can buy a device from Vendor A and a router from Vendor B, and assuming they’re both BTL listed, they work together seamlessly. But if Integrator B set up the certificate authority and walked away, you couldn’t create a new certificate. That’s not covered by the standard.
Nate Benes: I would say that as a building owner, when you take handoff of a job, you really ought to have access to that certificate authority and a way to issue new certificates to devices — whether that’s a tool you own or a vendor-managed tool. Much like when a building is handed over, you’d expect to get the passwords to the devices. These are things that should happen at handoff. The owner should have the access to maintain their own equipment.
Ryan LaFlamme: What’s still being developed by you and the committee? What should listeners be aware of for what’s coming next?
Nate Benes: Like I said, BACnet is a continuous maintenance standard, so there are always new things in motion. A couple of items we’ve talked about: should we come up with an interoperable way — a standard way — to go and get new certificates over the network? We’ve already given you a way to push certificates down to devices, much like on the web you can automatically get new certs from folks like Let’s Encrypt. Should we have something like that for BACnet? That’s an open conversation.
Another is the impact of quantum computing. Regulators and governments are asking: there’s all this cryptography that, once we have a decently sized, decently corrected quantum computer, is going to fall apart. How can we identify the post-quantum algorithms and get them deployed? They’re particularly looking at OT systems because OT has a long deployed service life. So there are questions like, as soon as 2030, where can we deploy these post-quantum algorithms — algorithms that are resistant to a quantum attack.
And then there’s the regulatory piece. We have things like the Cyber Resilience Act in Europe, and the new Cyber Trustmark coming out in the United States. How do we make sure tools like BACnet and BACnet Secure Connect continue to meet the requirements set by those regulations?
Ping Yao: For those venturing into BACnet/SC — new construction or retrofits — is there a significantly different cost? Cost per certificate, cost to rotate keys?
Nate Benes: BACnet/SC uses certificates and a certificate authority that you own and manage. It’s not what people imagine with old-school TLS, where you had to go to a big company and buy one. It’s something you own and manage, and you shouldn’t have to pay to issue certificates from your own CA. As for what the price difference is for a particular vendor’s equipment — I can’t speculate. But for a device running Linux, which most controllers do, the device doesn’t really care whether it’s doing BACnet/IP or BACnet/SC. It’s not a significant performance impact.
Ping Yao: A way to think about it for our listeners: if your device runs a web server, and you can log into https://[device], then it likely already has the capabilities to be a BACnet/SC device. The underlying technology is no different than the web server your controller is running.
Nate Benes: Right. Way back at the beginning of the episode we talked about BACnet’s previous attempts at security. One of the big barriers to adoption back then was that they had implemented their own cryptography — taken off-the-shelf algorithms and applied them in BACnet-specific ways. One of the lessons learned in BACnet/SC was that this slowed adoption. So SC just uses TLS and WebSockets, the same way a web server does. That made it really easy when we started rolling it out for developers to get started, and we’ve really seen that strategy pay off in market adoption.
Ryan LaFlamme: What’s the market reality right now for BACnet/SC? Are we seeing vendor support? Are integrators actually doing SC installs?
Nate Benes: Yes, we are. There have been a number of plug-fests — events where vendors from different companies bring their gear, sit around a table, plug everything in together, and make sure it all works. I know there have been plug-fests specifically focused on SC with really good engagement from vendors across the industry.
Another good indicator is BTL — the BACnet Testing Laboratories. They subject your device to thousands of pages of conformance tests, so when you purchase a device with the BTL mark, you can be reasonably sure it’s going to work well on a BACnet network. One lesser-known thing about the BTL website is that you can filter listings. You can go right now and say, “show me everything that knows how to be a BACnet/SC hub,” and you get a menu of things that are ready to go. Or you can pick a specific vendor and see all of their products that support SC today.
Ryan LaFlamme: The relationship between building automation teams and corporate IT — IT didn’t love BACnet/IP for the reasons we’ve already covered. Does SC change that conversation? When traffic is encrypted and looks more like the secure traffic IT is comfortable with, does that open doors that weren’t open before?
Nate Benes: Definitely. Anytime you’re not the odd person out asking for strange firewall exceptions, that’s a great boon to adoption. The fact that it’s just — you know, HTTPS, something everybody knows and is comfortable with, running over standard ports in most cases — very much lowers the barrier to adoption. And the architecture of SC, hub-and-spoke and not requiring special firewall holes, is just an easier pill to swallow across the board.
Ryan LaFlamme: Final question. If you were advising a facility director today, what would you tell them about timing on BACnet/SC? Migrate now, pilot in one building, or stick with BACnet/IP and we’ll get back to you? And are there any “don’t do this” warnings?
Nate Benes: I don’t know about other facility owners, but I’m pretty busy and I don’t have a huge appetite to walk into a building where things are mostly working and start changing a bunch of stuff. That’s probably not going to happen. I’ve never had a student on a recruiting tour walk into a building and say, “gosh, the air is so fresh, I can smell the BACnet/SC.” That’s never a conversation we’ve had.
It comes back to your business objectives. I’m probably not going to walk into a building that’s happy and working well and rebuild it just because it seems cool. Now, if that building has compliance issues, an old sketchy VPN that’s out of support, or other reasons I’m going to be in there making changes anyway — would I choose SC? Maybe. Does it make my life easier? Can I delete a bunch of firewall rules I had in place? Yeah, that’d be a great fit. But am I going to mess with a building that’s working great, well-supported, and has no security issues? Probably not.
For “don’t do this” — SC is great. It runs over TLS. That said, on a typical controller or computer, BACnet is not the only thing running. There’s other software, other web servers. If you have a really good culture of keeping all your building automation devices on a separate network — keep doing that. Don’t stop. If you have a culture of not putting your thermostat directly on the internet with a public IP — keep doing that. Keep it behind the firewall, on its own network. SC enables a bunch of cool new architectures, but it’s not a reason to give up on the great practices we’ve worked so hard to get to.
Ping Yao: If I may, I took notes during our talk. Let me run through them and you nod if you agree, stop me if you disagree.
After all this, people should realize: SC still uses good old BACnet messages — the who-is, the I-am, change-of-value, read-property, trend logs. None of that goes away. SC is a transport-layer change. It doesn’t change what you can do at the application layer.
It is interoperable. If one vendor came your way and talked about moving you to SC on a new building, it does not mean you’re locked in. It is still interoperable — that’s the whole point of the BACnet standard committee.
There’s no change to the IT or network infrastructure. You don’t need new switches or routers. It still uses standard IT infrastructure.
And last but not least, BACnet/SC uses some of the best practices and protocols that have been used by IT for many years. You didn’t create new TLS, you didn’t create a new way of exchanging keys, you didn’t create a new way of creating sockets. It uses things that have been available in the IT industry for decades.
For those listening to the podcast, Nate is enthusiastically nodding his head yes to all of those.
Ryan LaFlamme: Nate, thank you so much for joining us and helping answer a whole variety of questions around SC. I learned something — I personally didn’t know that SC and BACnet/IP could coexist happily in the same building. Hopefully our listeners learned something too. Where can people find you online?
Nate Benes: LinkedIn is probably the best place to connect.
Ryan LaFlamme: Perfect. Thanks for joining us on How to Handshake, created by Optigo Networks. You can find us on YouTube and at optigo.net. Tune in in two weeks for the next episode.
