BACnet/SC is a data communication method for BACnet that makes use of TCP/IP and mainstream network security technology to encrypt messages and to restrict which devices can communicate with each other. All BACnet/SC devices use digital certificates, and the use of those certificates is the subject of this article.
BACnet Secure Connect (BACnet/SC) introduces digital certificates into BACnet communication, enabling a level of control over device identity and network participation that is difficult to achieve with earlier BACnet communication methods. In a BACnet/SC network, devices cannot participate simply because they are connected to the IP network; each device must be explicitly provisioned with a valid certificate issued for that network. This gives system designers and operators clear, cryptographically enforced control over which devices are allowed to join.
For certain types of customers, particularly those with strong IT governance, compliance requirements, or concerns about unauthorized or misconfigured devices, this capability addresses a long-standing pain point. It allows BACnet networks to be designed so that network access alone is not sufficient for participation, reducing reliance on perimeter controls such as VLANs or VPNs as the sole means of protection.
At the same time, these benefits come with new responsibilities. Deploying BACnet/SC requires processes for certificate provisioning, renewal, and replacement over the life of the system. For controls engineers, an important design and operational question is whether these responsibilities can be accommodated within existing workflows, tooling, and organizational roles.
Digital certificates also provide the foundation for encrypted communication and device authentication in BACnet/SC. Together, these capabilities establish a well-defined trust boundary for a BACnet/SC network based on device identity rather than IP addressing or network topology.
BACnet/SC networks can coexist with other BACnet networks, such as BACnet/IP or BACnet MS/TP, using BACnet routers. This allows BACnet/SC to be introduced incrementally rather than as an all-or-nothing transition.
This article focuses on how digital certificates are used in BACnet/SC, how they differ from certificates used in typical web-based systems, and what designers and operators should understand about certificate lifecycle management. Authorization and other higher-level security features are intentionally out of scope and will be addressed separately.
A Short Primer on Keys, Certificates, and Trust
BACnet/SC relies on asymmetric cryptography, in which each device possesses a private key that is kept secret and a corresponding public key that can be shared. Private keys are used to prove device identity and to help establish shared session keys that protect communication.
A digital certificate binds a public key to an asserted identity and is signed by a Certificate Authority (CA). The CA’s signature allows other devices to verify that the identity-to-key binding has been approved by a trusted authority.
In familiar IT use cases such as HTTPS, a web browser validates a server’s certificate by following a chain of signatures back to a trusted root certificate. BACnet/SC uses the same cryptographic foundations, but applies them in a more tightly scoped trust model that reflects the operational realities of building automation systems.
The BACnet/SC Trust Model
Every BACnet/SC device is configured with two essential certificates:
- An operational certificate, unique to that device
- An issuer certificate, containing the public key of the CA trusted by the BACnet/SC network
All devices on a BACnet/SC network trust the same network-specific issuer certificate. Operational certificates presented by devices are validated against this issuer certificate during connection establishment. The issuer certificate therefore defines the trust boundary of the BACnet/SC network.
Unlike web-based public key infrastructures, BACnet/SC intentionally uses a single-step certificate chain. There is no hierarchy of intermediate certificate authorities and no reliance on globally trusted public CAs. This design reflects the fact that BACnet/SC networks are operational systems managed by a specific organization, rather than open internet services.
Mutual Authentication Using TLS
BACnet/SC uses TLS (Transport Layer Security) to establish secure connections between devices, including connections to BACnet/SC hubs and, in some cases, direct connections between peer devices.
During the TLS handshake, each device presents its operational certificate to the peer. Each device independently validates that the peer possesses the private key corresponding to the public key in its certificate and that the certificate was signed by the trusted issuer certificate configured on the device. This process provides mutual authentication, meaning that both endpoints authenticate each other before encrypted communication is established.
Successfully completing the TLS handshake establishes encrypted communication and confirms device identity from a transport-security perspective. It does not, by itself, determine what BACnet services an authenticated device is permitted to invoke.
How BACnet/SC Certificate Use Differs from Web PKI
BACnet/SC certificate usage differs from web-based PKI in several important ways:
- All devices on a BACnet/SC network share a network-specific issuer certificate.
- BACnet/SC devices authenticate each other mutually, rather than relying on a client-server trust asymmetry.
- Device identity is established through certificate trust rather than DNS names or IP addresses.
- Support for certificate revocation checking is not mandated by the protocol and is treated as a local matter.
These differences are intentional and reflect the needs of building automation systems, including long device lifetimes, isolated or segmented networks, and predictable operational behavior.
Certificate Lifecycle Considerations
Digital certificates are not intended to be permanently deployed. They have defined validity periods, may need to be revoked, and must occasionally be replaced or refreshed. As a result, certificate lifecycle management is an important operational consideration for any BACnet/SC network.
Certificate management responsibilities must be clearly assigned, whether handled by controls staff, IT, a combination of both, or by a vendor providing certificate management services.
Certificate Lifetimes
Operational certificates used by BACnet/SC devices include validity dates and will eventually expire. The choice of certificate lifetime is primarily a policy decision. Shorter lifetimes can reduce the impact of a compromised certificate but require more frequent updates, while longer lifetimes reduce operational overhead.
There is no single recommended lifetime that applies to all deployments. Appropriate choices depend on organizational cybersecurity policies, the practicality of updating certificates in the field, and the expected service life of the devices.
Issuer Certificates and Network Trust
Each BACnet/SC network is configured with one or two issuer certificates that define the network’s trust boundary. Operational certificates presented by devices are validated against these issuer certificates during connection establishment.
The issuer certificate plays a different role from an operational certificate. Its expiration does not disrupt BACnet/SC communication, since it is used to verify certificate signatures rather than to establish encrypted sessions. For this reason, issuer certificates are often managed with longer validity periods.
Certificate Revocation in Practice
BACnet/SC does not require a specific mechanism for checking whether an operational certificate has been revoked. As stated in the BACnet Standard (Annex AB.7.4), “the support and update of revocation information is a local matter.”
In current practice, BACnet/SC networks typically do not implement online certificate revocation checking. Supporting the infrastructure required for mechanisms such as certificate revocation lists or online status responders is uncommon in building automation environments and is not widely supported by building automation products.
When an operational certificate must be revoked—for example, because a device has been decommissioned or is suspected of being compromised—a recommended approach is to replace the issuer certificate trusted by the BACnet/SC network and to reissue operational certificates for the remaining devices. This establishes a clear new trust boundary and avoids ambiguity about which devices are permitted to participate.
Updating and Refreshing Certificates
Because certificates expire and may need to be replaced, BACnet/SC deployments must also address how certificates are updated on devices.
In practice, two general approaches are used today.
One approach relies on proprietary, vendor-specific mechanisms, using tools or workflows provided by a device manufacturer. These mechanisms are typically limited to devices from a single vendor and do not provide an interoperable solution across products from different manufacturers.
A second approach uses standardized mechanisms defined in the BACnet Standard, specifically those introduced in BACnet Addendum cc. Addendum cc defines BACnet/SC-specific Network Port objects and associated File objects that allow certificates and related data to be transferred using standard BACnet services.
Vendor-specific mechanisms are more common in deployed systems, while the standardized approach defined in BACnet Addendum cc is intended to support interoperable certificate management as BACnet/SC networks continue to evolve.
Closing Thoughts
Digital certificates are central to how BACnet/SC establishes device identity, controls network participation, and defines trust boundaries. For controls engineers evaluating whether to use BACnet/SC, the key questions are not only what benefits certificates provide, but also how certificate responsibilities fit into existing operational practices.
By understanding how certificates are used, how they differ from web-based PKI, and how their lifecycle can be managed in practice, designers and operators can make informed decisions about where BACnet/SC is appropriate and how it can be introduced effectively.
Common Questions about BACnet/SC Certificates
This is primarily a policy question for the end user’s organization. In high security environments, the IT department is likely to insist on certificate lifetimes of one year or less.
The expiration of an issuer certificate does not affect the operation of BACnet/SC devices.
Good practice is that every device should have its own private key and its own operational certificate.
Ideally the certificate authority should be managed by the end user’s organization. If this is not feasible, then management responsibilities can be handled by a vendor with appropriate expertise and security processes.
