Every BAS operator has lived a version of this scenario: a building that worked yesterday is doing something subtly different today. A schedule that was running properly is overriding to occupied at three in the morning. A controller that had been responding reliably is now intermittent. An alarm has appeared on a point that nobody touched. Hours later, after enough investigation, the cause turns out to be a contractor who patched something in last week without telling anyone, or a commissioning engineer who left a temporary override active, or a rebuild that loaded a slightly stale configuration.
None of those things were malicious. They were the kind of small, ordinary mistakes that human beings make in busy industrial environments, and they were possible because the network has no governance, no visibility, and no record of what changed.
The conversation about cybersecurity in building automation has, understandably, focused on encryption and authentication. BACnet/SC delivers both, and for the high-value controllers that warrant the investment in certificates, the move toward encrypted, mutually authenticated communication is overdue. But for the everyday operator, the more pressing question is often not whether the wire is encrypted. It is whether they have any way of knowing what is actually on their network, what changed, and when.
That is a question of BACnet network governance, visibility, and posture, and it is largely independent of cryptography. It is also a question that the BAS team can usually answer without involving the IT department.
The Problem Is Almost Never Malicious
It is tempting, when reading vendor cybersecurity material, to imagine the threat as a sophisticated adversary on the other side of the wire. That threat exists, and for facilities that are part of critical infrastructure, it warrants serious attention. However, the operational pain that consumes the day-to-day attention of facilities and integration teams is almost always something far more mundane.
A contractor brings a new controller onto the network during a tenant fit-out and configures it with a device instance that already exists on another subnet. A junior engineer copies a working configuration to a new site and forgets to change the BACnet network number. A vendor’s commissioning tool, plugged into the wrong network port, sends a global Who-Is and produces a brief storm. A maintenance technician, working around what they thought was a glitch, manually overrides a setpoint and forgets to release it. None of these people intended harm. None of them are bad actors. They are people working under pressure, often with incomplete information, and the network gives them no feedback about the consequences of what they have done.
The frustration that operators experience in this environment is not, in most cases, the product of bad intent. It is the product of human error, accumulated bad habits, and the absence of clear standards, all compounded by the lack of any meaningful record of what changed. Improving the situation does not require treating contractors as adversaries. It requires giving the operations team the visibility and governance controls to catch these problems before they become outages, and to investigate them quickly when they slip through.
What Cryptography Solves, and What It Does Not
True authentication and true encryption can only come from cryptographic mechanisms. There is no substitute for a properly issued X.509 certificate when the question is whether a device is who it claims to be, and there is no substitute for TLS when the question is whether the wire is being read by an attacker with a packet capture. BACnet/SC addresses both of those questions, and any serious conversation about the long-term security posture of a building automation network has to include a credible plan for migrating high-value devices to SC over time.
What cryptography does not address is the broader question of BACnet network governance. A device with a valid certificate can still be the wrong device. A change made by an authenticated user can still be a mistake. An encrypted message can still carry an instruction that breaks the building. The cryptographic layer answers the question of whether a participant is who they claim to be. It does not answer whether they should be doing what they are doing, whether the action was intentional, what the consequences were, or what the network looked like before the change occurred.
A reader who has followed the BACnet/SC conversation might reasonably push back at this point. If every device on a campus were eventually migrated to SC, with every device cryptographically authenticated and every connection encrypted, would the question of governance not largely take care of itself? An unauthorized device cannot connect to the hub. The wire cannot be passively read. The threat of a stranger plugging in a rogue controller is genuinely eliminated. So what is left for governance to do?
The answer is: most of what was already there. Authentication is not authorization. A device with a valid certificate has proven that it is who it claims to be, but not that it should be doing what it is doing, sending what it is sending, or sitting on the segment where it has appeared. A duplicate device instance number, in particular, is an application-layer condition, not a transport-layer one. VMAC, which BACnet/SC uses in place of the IP and UDP port pair, addresses the transport layer. The device instance number is a property of the Device object itself, and it behaves identically across transports. Two controllers from the same vendor routinely ship with the same default device instance, and both can hold perfectly valid certificates and distinct VMACs while colliding at the application layer the moment they are powered on. The contractor who patches in a new controller during a tenant fit-out is a real, authorized contractor whose company has a real, signed certificate, as is the engineer who copies a working configuration to a new site and forgets to change the BACnet network number. The frustrations the article opened with are produced by people and devices who would pass any cryptographic check.
Several other governance concerns also survive a hypothetical full-SC deployment. Certificate issuance becomes the new admission question, with the CA hygiene, lifecycle, and revocation discipline that implies. Authorized users continue to make mistakes, leave overrides active, and copy configurations between sites. Visibility and audit remain orthogonal to encryption, because the wire can be perfectly secured while the conversation goes unrecorded. SC does not eliminate BACnet network governance. It changes the surface on which it has to operate. There is also the practical matter that full SC adoption, on most campuses, is a decade-scale proposition, and designing the operational posture of a network around what may be true in 2036 is a way of deferring the problems that exist today.
These are BACnet network governance questions, and they require a different layer of capability. They require knowing what devices are on the network and how that population changes over time. They require recording who made which change and when. They require visibility into traffic patterns and the ability to surface anomalies before they become incidents. None of that requires a certificate authority. All of it can be implemented today, on the network as it exists, and most of it can be implemented without involving the IT department at all.
The Limits of the IT-Side Approach
The IT department, when one is available and engaged, can do a great deal to improve a BACnet network’s posture. VLAN segmentation, port security on access switches, network access control, and 802.1X authentication are well-understood techniques that, properly applied, can prevent many of the device-onboarding problems that plague BAS networks. In a campus where the IT and OT teams collaborate closely, these techniques are part of a healthy security posture and should be part of the conversation.
However, the reality on most campuses is more complicated. The BAS team often does not own the network it operates on. The switches are managed by IT. The VLANs are configured by IT. The change windows are scheduled around IT priorities. In hospitals, universities, and large commercial portfolios, the BAS team may have to file a ticket and wait days or weeks to have a single port reconfigured. In smaller facilities, there may be no IT department engaged with the BAS network at all, leaving the BAS team responsible for a network they do not have the tools to manage.
The result is that the IT-layer security controls that the textbook describes are, for many operators, either operationally inaccessible or organizationally out of reach. Waiting for the IT side to solve the BAS network’s governance problem is, in most cases, waiting for something that is not going to happen on a useful timeline. The BAS team needs tools that work at their layer, with their level of access, and on the schedule their building actually runs on.
BACnet Network Governance, Visibility, and Logging Are Worthwhile on Their Own
Stepping back from cryptography and from IT-layer controls, three capabilities remain that the BAS team can own directly and that pay dividends immediately.
The first is governance: deciding what belongs on the network, and refusing what does not until it is reviewed and approved. This does not require a certificate authority. It requires a registry, a workflow, and a default behavior that errs on the side of containment rather than open access.
The second is visibility: knowing, at any moment, what devices are actually on the network, what they are communicating with, and how that picture is changing over time. This is not difficult to implement; it requires only that something be watching the traffic and recording what it sees. The information has always been on the wire. The gap is a tool that captures it in a form the operations team can use.
The third is logging: a durable record of what has been happening on the network and in the management of it, including devices appearing and leaving, quarantine and approval actions, error conditions raised and resolved, notifications dispatched and acknowledged, and operator actions in the management interface, all attributed to a source and a timestamp. This is the audit trail that allows an operator to walk back from “the building started behaving differently this morning” to specific entries in the timeline, without spending the rest of the day reconstructing it from memory.
None of these capabilities require encryption to be useful. They are improvements in posture that complement a future SC migration but do not depend on one. They are also, by far, the capabilities that most directly address the kinds of problems that consume the operations team’s time today.
Default, Not Customization
The point at which these capabilities cease to be theoretical and begin to actually change a campus’s posture is the point at which they become the default behavior of the platform, rather than an optional configuration that someone has to remember to enable.
A great deal of the security and governance machinery that exists in building automation today is technically present but operationally absent. The features are listed in the data sheet. They are described in the configuration manual. They can be enabled by an integrator who knows where to look and is given the time to set them up. In practice, they are very often not enabled, because the integrator was not given the budget, because the operator did not know to ask, or because the customization required to make them work in a real-world deployment exceeded the time available.
The difference between a platform that improves a campus’s posture and a platform that merely could improve it is whether the right thing happens by default. Quarantine of unknown devices should not be an advanced setting. Capture of every BACnet write should not require enabling a separate logging service. The audit trail should not be something the operator has to opt into. If the operations team has to remember to turn the governance on, the governance is, for practical purposes, off.
This is not a criticism of any vendor’s design choices. Defaults are difficult, and what is appropriate as a default in one deployment may be inappropriate in another. However, the trend across the broader IT industry over the past decade has been clear, and it is the right one: secure by default, with explicit configuration required to relax the posture rather than to tighten it. Building automation is overdue for the same shift.
What This Looks Like in Practice
The BSP-1000 platform was designed around this principle. Its default posture, on the day it is deployed, is the posture that the operations team would, on reflection, almost always have chosen if they had been asked.
Devices that appear on the network for the first time are recorded in the platform as Pending. They are visible to the operator from the moment they are seen, but they remain isolated from cross-subnet discovery until they have been explicitly approved through the web interface. A duplicate device instance number, meaning the same instance number claimed by two different network identities, is detected automatically and raised as a critical alarm. There is no configuration step required to enable any of this. It is simply how the platform behaves out of the box.
The discovery and protocol traffic that the platform observes is recorded for retrospective review, with attribution to the source and the time at which it was seen. Significant events, such as a device’s first appearance, an IP change, an approval, or a quarantine state change, are kept for the longer term as part of the operator’s audit trail. When deeper investigation is needed on a specific device, an operator can initiate a short on-demand packet capture from the web UI, and the result is available from the same interface for download or analysis, without leaving the platform or running a separate tool on the segment.
Errors that meet the configured severity threshold, such as a device going offline, a controller flapping in and out of reachability, an excessive broadcast rate from a single source, or a duplicate device instance, are dispatched through the platform’s notification system. Notifications are routed first to a configurable primary recipient list, and to an escalation list if the primary list does not acknowledge within the configured window. Every notification is itself logged, with delivery status and acknowledgment recorded against the user who handled it.
None of this requires the IT department’s involvement. It runs on the same network the BAS team already owns, with the same level of access the BAS team already has. It complements an eventual migration to BACnet/SC, and is fully compatible with the gradual SC adoption path described in earlier writing on this site, but it does not depend on that migration. It pays dividends on day one.
A Posture Worth Building
The cybersecurity conversation in building automation has, for the past several years, been dominated by the discussion of encryption and authentication. Those are real and important problems, and the industry’s progress on them is genuine and welcome. But the operational reality on most campuses, today, is that the more pressing problems are not cryptographic. They are problems of governance, visibility, and the absence of a clear default posture for what should and should not be allowed on the network.
These are problems the BAS team can own. They are problems that improve the day-to-day experience of operating the building, not just the long-term security audit. And they are problems that, given the right defaults, can be addressed without waiting for the IT department, the next budget cycle, or the protocol migration.
The encryption is coming. It will arrive on the schedule that certificate management and device replacement allow. While the industry waits for that future to arrive, the more immediate opportunity is to raise the floor of what every BACnet network does by default, and to treat governance, visibility, and logging not as features that someone might pay extra for, but as the baseline of a network that takes itself seriously.
That is a posture worth building, and it is available to the BAS team today.
If this resonates with what you are seeing on your network, we would welcome the opportunity to discuss it further. More information about BACsync is available at bacsync.com.
About the Author — Mark Van Weert is the founder and director of Humber Horizons Limited, a building automation and cybersecurity consulting firm based in Ontario, Canada. With thirteen years of experience in BACnet systems integration, CCNA/CCNP certifications, and a background in large campus deployments, Mark specializes in IT/OT convergence and network infrastructure for universities, hospitals, and commercial facilities.