Is BACnet Secure Connect post-quantum safe?

BACnet Secure Connect post-quantum readiness describes whether BACnet/SC can keep building automation traffic confidential and authentic once quantum computers can break today’s public-key cryptography. BACnet/SC protects traffic with TLS 1.3 and X.509 certificates, and both depend on elliptic-curve or RSA algorithms that quantum computers are expected to break. This article covers which parts are exposed, what hybrid ML-KEM changes, and how to plan the migration.

Building owners and operators of critical infrastructure (hospitals, data centres, utilities, campuses) increasingly connect BACnet sites to a central building management system (BMS) over the public internet or shared WANs. That makes the cryptographic lifetime of those links a real planning question rather than a theoretical one.

What encryption does BACnet Secure Connect use?

BACnet Secure Connect carries BACnet messages in secure WebSockets over TLS 1.3, with mutual X.509 certificate authentication on every connection. Bulk traffic is protected with TLS 1.3 AEAD cipher suites, and session keys come from an ephemeral elliptic-curve Diffie-Hellman exchange.

BACnet/SC was introduced by Addendum 135-2016bj to ANSI/ASHRAE Standard 135 (BACnet) and is part of later consolidated editions of the standard. It replaces the plain UDP transport of BACnet/IP, which commonly runs on port 47808 and has no native encryption, with a hub-and-spoke virtual network. Each node opens an outbound TLS connection to a primary hub (and a failover hub). Nodes can also open direct connections to each other.

BACnet/SC builds on TLS 1.3 as defined in RFC 8446. That inherits two useful properties. TLS 1.3 explicitly removed support for static RSA key transport in favor of supporting only ephemeral mode Diffie-Hellman to provide perfect forward secrecy, and in TLS 1.3, the Certificate message is encrypted whereby hiding the server identity from any intermediary.

Where the asymmetric cryptography sits

A BACnet/SC device holds an operational certificate and private key, plus one or more issuer (CA) certificates that it trusts. The organisation or its integrator usually operates the issuing CA for the site, not a public web CA. Asymmetric cryptography therefore appears in exactly two places: the ECDHE key share that derives session keys, and the ECDSA or RSA signatures that bind certificates and handshakes to device identities. BACnet International’s interoperability testing checks that devices implement this profile correctly. It does not make the underlying algorithms quantum-resistant.

Is BACnet/SC vulnerable to quantum computers?

Yes. The key exchange and the certificate signatures in BACnet/SC rely on elliptic-curve or RSA cryptography, which a cryptographically relevant quantum computer could break. The symmetric AES-GCM encryption of the payload is not the weak point.

The two exposures differ in timing, and that difference should drive your priorities:

NIST has set the general timeline for moving away from these algorithms. In its final transition report, NIST states it will “deprecate quantum-vulnerable public-key cryptography after 2030 and disallow its use under NIST standards and guidelines after 2035.” The policy goal behind this, quoted by Dustin Moody of NIST’s Cryptographic Technology Group from National Security Memorandum 10, is to transition “with the goal of mitigating as much of the quantum risk as is feasible by 2035.”

Can BACnet/SC hubs negotiate hybrid ML-KEM key exchange in TLS 1.3?

In protocol terms, yes: TLS 1.3 negotiates key exchange groups through its supported_groups and key_share extensions, so hybrid ML-KEM groups fit without changes to BACnet itself. In practice, a hub and every node that connects to it must both support the same hybrid group, and most installed controllers cannot do that today.

The IETF specification for this is draft-ietf-tls-ecdhe-mlkem. It introduces three new supported groups for hybrid post-quantum key agreements in TLS 1.3: the X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024. ML-KEM itself is a key encapsulation mechanism defined in [NIST-FIPS-203]. According to the IETF TLS Working Group, the hybrid approach aims to “provide security against both classical and quantum adversaries while maintaining compatibility with existing infrastructure and protocols.”

Mechanically, for X25519MLKEM768, the shared secret is the concatenation of the ML-KEM shared secret and the X25519 shared secret. The resulting 64-byte hybrid shared secret is supplied to the TLS 1.3 key schedule. If either component holds, the session key stays secret.

What limits adoption in BACnet/SC networks

• Every node is a TLS client. The hub can offer a hybrid group, but each controller must also send a hybrid key share. If even one older device does not, that connection falls back to classical ECDHE.
• Firmware-bound TLS stacks. Field controllers often ship with a fixed TLS library. Adding ML-KEM requires a firmware release from the manufacturer, plus enough RAM and flash for larger key shares.
• Curve choice. Many embedded stacks use P-256 rather than X25519, so SecP256r1MLKEM768 may be the more realistic first group. The draft also notes certification differences: for SecP256r1MLKEM768 and SecP384r1MLKEM1024, the ECDH implementation must be certified whereas the ML-KEM implementation does not require certification.
• Conformance. Check whether the edition of ANSI/ASHRAE Standard 135 that your devices claim, and the test profile they were listed under, says anything about hybrid groups. Do not assume interoperability between manufacturers until you have tested it on your own hub.

How do I protect BACnet traffic between buildings and a central building management system over the internet?

Do not expose BACnet/IP to the internet. Use BACnet/SC between sites and the central BMS. Where the BACnet/SC key exchange cannot yet be made post-quantum, carry the inter-site segment inside a network-layer tunnel that uses a hybrid ML-KEM key exchange.

The options differ in what they protect and what they need from field devices:

Practical design notes

• Place the hub centrally and keep connections outbound. BACnet/SC nodes connect out to the hub, so remote buildings need no inbound firewall openings. Keep that property when you add tunnels.
• Layer, don’t substitute. A post-quantum tunnel protects the WAN segment. BACnet/SC inside it still gives device-level authentication that a site-to-site tunnel cannot provide. Run both where you can.
• Decide where inspection happens. If your firewall inspects BACnet traffic, place the tunnel endpoint so that the firewall still sees the traffic in the clear, behind the tunnel.
• Account for legacy segments. MS/TP trunks and BACnet/IP-only controllers reach the BMS through routers or gateways. The cryptography only protects the segment after that conversion point.

One example of the tunnel approach is Quantum Network’s QPN gateway. It sits at each end of a site link and encrypts at Layer 3, so BACnet/SC or BACnet/IP traffic passes through unchanged and no software has to be installed on controllers. Its key agreement combines a classical part and ML-KEM (FIPS 203) into one session key. The gateway can sit in front of an existing firewall that must keep inspecting traffic, or behind it where no inspection is needed. It does not replace the firewall, and it protects data in transit, not the devices behind it.

How should BACnet/SC device certificates be migrated to post-quantum algorithms?

Migrate certificates in planned stages, starting with an inventory and the issuing CA and finishing with field devices. Forged signatures only become a risk once a quantum computer exists, so this can follow the key-exchange work, but long device lifetimes mean the planning has to start now.

1. Build an inventory. For every hub, node and BMS server, record the operational certificate, the key algorithm, the expiry date, the issuer certificate and who can replace it. NIST’s guidance on TLS certificate management calls out enabling rapid migration to new certificates and keys when certificate authorities or cryptographic mechanisms are found to be weak, compromised, or vulnerable.
2. Shorten validity periods now. Controllers often receive certificates valid for many years. Shorter lifetimes, issued through a repeatable process, turn a future algorithm change into a routine renewal.
3. Stand up a post-quantum issuing hierarchy alongside the current one. Use ML-DSA (FIPS 204) for a new root and issuing CA. Where devices accept more than one issuer certificate, load the new trust anchor early so both hierarchies are trusted during the transition.
4. Migrate the hub and BMS servers first. They have the most capacity and are the identities most worth impersonating. Then move field controllers as manufacturers release firmware that can validate and present ML-DSA certificates.
5. Test resource limits. Post-quantum signatures and public keys are considerably larger than ECDSA ones. Verify handshake times, memory use and certificate storage on the smallest controllers before rolling out to a whole site.
6. Write firmware support into procurement. Require crypto agility (replaceable algorithms in the TLS stack) in specifications for new BACnet/SC devices, since controllers installed today may still run after 2035.

What timeline should building owners plan against?

Treat 2030 as the point where classical public-key algorithms become deprecated and 2035 as the point where they are disallowed under NIST rules. Systems with sensitive data should have quantum-resistant key exchange earlier.

• After 2030: NIST deprecates quantum-vulnerable public-key cryptography, and disallows it after 2035 (NIST IR 8547, 2026).
• December 31, 2030: under OMB Memorandum M-26-15, high value assets, high impact systems, and other systems with highly sensitive data in the US federal government must use quantum-resistant key establishment (as cited in NIST IR 8547, 2026).
• 3 hybrid groups: X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024 are defined for TLS 1.3 in draft-ietf-tls-ecdhe-mlkem-05 (IETF, May 2026).

For BACnet operators, this produces a clear order of work. First, protect the key exchange on every link that crosses an untrusted network, using hybrid TLS groups where devices support them and a post-quantum tunnel where they do not. Second, inventory certificates and shorten their lifetimes. Third, roll out an ML-DSA issuing hierarchy as firmware allows. As NIST’s project page puts it, organizations must identify where vulnerable algorithms are used and plan to replace or update them.