Secure, encrypted communication layer
For years, integration in buildings has been based on a tension that is difficult to resolve. On the one hand, BACnet has established itself as the benchmark for interoperability in building automation and technical management. On the other hand, many BACnet/IP-based architectures have become dependent on networking practices that IT departments tend to view with suspicion, such as broadcast traffic, specific segmentations, and exposure of systems that do not always fit well with modern cybersecurity policies. BACnet Secure Connect, or BACnet/SC, comes into play precisely at this point of friction. According to BACnet International, it is a secure, encrypted communication layer added to the BACnet protocol to better meet the requirements of today’s IP infrastructures. It does not replace existing options, but adds a path more aligned with expectations for security, management, and interoperability in professional networks.
What is BACnet/SC really?
In practice, BACnet/SC does something very important without changing the functional essence of BACnet: it continues to transport data, statuses, alarms and commands between devices and systems, but does so over a secure communication basis. BACnet International describes it as a means for two BAS devices to establish a strongly protected and encrypted connection between themselves, through which conventional BACnet messages are passed. The critical difference is that the content of these messages is no longer easily observable on the network by anyone who does not have the appropriate keys and authentication mechanisms.
From a technical standpoint, BACnet/SC brings building automation closer to current IT practices. The official ASHRAE white paper emphasises that the proposal was developed based on widely accepted standards and security methods in the IT world, precisely to reduce friction between building networks and corporate policies. This same framework is reinforced by more recent ASHRAE material, which refers to the use of TLS, PKI certificates, mutual authentication between connection endpoints, and elimination of broadcasts as central aspects of the approach. Instead of constantly asking the IT team for exceptions, BACnet/SC attempts to speak a language that IT already knows.
What changes in systems integration
The most visible change is not in the BACnet object, logical point, or data semantics. It is in the communication architecture. BACnet/SC typically uses a hub-and-spoke topology, with a central hub that routes traffic between connected nodes, and there may be a failover hub to maintain service if the primary hub fails. ASHRAE’s technical documentation explicitly describes this topology and also allows for optional direct connections between certain nodes on the same BACnet/SC segment. In terms of integration, this changes the way the network is thought of. Instead of a model heavily dependent on local broadcasting and behaviours typical of classic BACnet/IP, there is now a more controlled model, oriented towards secure sessions and defined routing.
This has concrete implications for the project. The first is that integration is no longer just a matter of mapping points, defining objects, and validating supported services. It also requires digital trust design: certificates, certification authorities, renewal policies, addressing, DNS resolution in some scenarios, and primary hub and failover planning. The second is that the integrator has to think more carefully about the coexistence of new and legacy systems. ASHRAE refers to mixed scenarios in which BACnet/SC routers bridge existing BACnet/IP or MS/TP networks. This allows the exposed or interconnected layer to be modernised without requiring the immediate replacement of the entire installed base. But it is important not to romanticise this coexistence: the legacy section continues to have the security limitations inherent to the technology that remains there. The router improves the perimeter and access, it does not magically transform an old segment into a secure end-to-end segment.
In practice, BACnet/SC does something very important without altering the functional essence of BACnet: it continues to transport data, statuses, alarms, and commands between devices and systems, but it does so over a secure communication basis.
What changes in building security
The security gain does not result solely from traffic encryption. It results from a combination of several principles: mutual authentication, use of TLS, certificate management, elimination of broadcasts, and better compatibility with segmentation and access policies already common in enterprise environments. ASHRAE states that BACnet/SC should eliminate risky practices such as placing unprotected devices directly on the Internet and highlights the use of TLS v1.3 and PKI certificates as key parts of the new approach. The Managed BACnet guide adds an important point: BACnet/SC simplifies the security of BACnet networks and can contribute to a defence-in-depth strategy, i.e., an additional layer of protection within a broader security architecture.
But here it is worth being precise. BACnet/SC greatly improves security posture, but it does not solve building cybersecurity on its own. BACnet International itself has clearly stated this in other materials: it is an important piece, not the total solution. If there is poor credential management, expired certificates, weak remote access policies, lack of adequate segmentation, outdated firmware, or undisciplined operation, the risks remain. What changes is that the protocol now offers a foundation that is much more consistent with what is expected of a serious technical infrastructure today. In buildings where the OT network can no longer exist in isolation from the rest of the organisation, this difference is significant.
Where BACnet/SC has the most operational impact
The impact is felt mainly on three fronts. The first is remote access. The ASHRAE white paper describes scenarios in which a BACnet/SC node inside the building initiates a connection to a hub in the cloud, enabling secure access from the outside without the need to open complex inbound connections in the firewall, beyond what already exists for outgoing HTTPS traffic. For distributed operations, remote maintenance, and multi-site supervision, this is an important practical change.
The second front is the relationship between OT and IT. Instead of requiring special treatment for BACnet traffic on shared networks, BACnet/SC brings building automation closer to mechanisms that IT already knows how to govern. This does not eliminate the need for coordination between teams, but it does reduce classic arguments against integration into corporate networks. The third front is the maturity of the ecosystem itself. The Managed BACnet guide shows that the topic has already evolved beyond the initial idea of transport encryption and now covers topics such as cryptographic suites, onboarding, authorisation, certificate management, network events and segmentation. This reveals a consistent technical trajectory, but also shows that serious implementation requires method, governance and competence.
What should an integrator conclude?
BACnet/SC does not change the value of BACnet as the common language of building automation. What changes is how to make it work in a world where security, remote access and IT integration requirements are much more demanding than they were a decade ago. For designers and integrators, this means that integration is no longer just logical and functional, but also a discipline of secure architecture. For building owners and operations teams, it means that there is now a more credible way to connect buildings, portfolios and remote services without relying so heavily on network exceptions or improvised solutions.
The sensible decision is not to ask whether BACnet/SC is ‘better’ than BACnet/IP in the abstract. The right question is another: in which parts of the infrastructure does it make sense to introduce a secure communication layer, more in line with modern IT policies, without losing interoperability and without destroying existing investment. In many new buildings, the answer will tend to be ‘from the outset’. In many existing buildings, the answer will involve hybrid migrations, routers, transition phases, and careful review of certificate policy. That is where BACnet/SC ceases to be a matter of standardisation and becomes an engineering decision.
References
- BACnet International. “BACnet Secure Connect”.
- ASHRAE. “BACnet Secure Connect (BACnet/SC): A Secure Infrastructure for Building Automation”.
- ASHRAE. “Protecting Building Automation Systems with BACnet Secure Connect”.
- ASHRAE. “Managed BACnet Guidance Volume 1: Manufacturer’s Guide”.
- ASHRAE. “ANSI/ASHRAE Addendum cp to ANSI/ASHRAE Standard 135-2020”.
WiseBuilding® is technically capable of implementing any project that creates buildings that think, save and protect the planet. Consult us.
WISEFRAMEWORK is a BACnet B-AWS certified software solution for state-of-the-art integration, control, management and visualisation in building automation systems. Designed to redefine the way buildings are operated through an open platform and seamless harmonisation between building-generated data by supporting multiple protocols including BACnet, Modbus, KNX, OPC-UA and MQTT. Through the use of Haystack technology, the software also empowers the building for the future at the forefront in the integration of the various technical systems.
