Key takeaways
- Find out what's actually reachable.
BACnet (Building Automation and Control Networking protocol) is the dominant protocol behind commercial building automation — HVAC, lighting, access control, fire and life-safety systems all speak it — and its most common transport, BACnet/IP, broadcasts commands over UDP with no authentication or encryption by default, standardized as ANSI/ASHRAE Standard 135. A secure option, BACnet/SC, exists since a 2019 addendum, but a decade of CISA ICS advisories against building-automation vendors shows that most documented BACnet failures are implementation bugs and exposed web interfaces, not breaks in that secure option itself — largely because most deployed BACnet equipment doesn't run it.
What ASHRAE Standard 135 actually leaves open
BACnet's application layer — the services a device uses to discover peers (Who-Is/I-Am), read and write properties, and exchange alarms and schedules — is defined by ANSI/ASHRAE Standard 135, under continuous maintenance by ASHRAE's Standing Standard Project Committee 135 and currently at edition ANSI/ASHRAE 135-2024. None of that core application layer carries a field for a credential or signature, and BACnet/IP's addressing model relies on UDP broadcasts a device on the same segment can simply listen to and, in many deployments, respond to. That design reflects BACnet's origin on physically isolated building-controls networks; it has aged the same way Modbus and pre-2012 DNP3 have, by ending up routed over general-purpose IP infrastructure, remote-access VPNs and, in a meaningful number of documented cases, directly reachable from the internet.
BACnet/SC: a real fix, if it's actually running
BACnet Secure Connect (BACnet/SC) is a secure datalink-layer option first introduced through Addendum 135-2016bj — which went through ASHRAE's standard 45-day public review (21 June–5 August) before adoption — and later folded into Annex AB of the ASHRAE 135-2020 edition. Rather than patching UDP broadcast, BACnet/SC replaces it with a connection-oriented transport over WebSockets and TLS: devices authenticate each other with certificates and encrypt the BACnet messages they exchange, so, per BACnet International's own description, "no device on the network can determine the content of secure messages unless they have the appropriate encryption keys." Subsequent addenda rounded out the mechanics — Addendum 135-2020cd defines the TLS 1.3 cipher-suite profile BACnet/SC uses, Addendum 135-2020cc updated the Network Port object so a device can represent and configure its BACnet/SC state, and Addendum 135-2020cs defined an offline certificate-exchange file format for sites that can't run a live certificate authority. Critically, BACnet/SC changes the transport, not the application layer: a device running it still exposes the same objects and services a BACnet/IP device does, just over an authenticated, encrypted channel instead of a broadcast one. BACnet International itself frames adoption as still maturing, noting it built a reference implementation and test bench specifically "to help suppliers gain in-house technical knowledge" — language that reads as an acknowledgment that BACnet/SC support in deployed equipment remains a minority, similar to DNP3 Secure Authentication's described uptake.
Where it actually fails: implementation bugs and exposed interfaces
| Advisory | Vendor / product | CVE(s) | CVSS | What it actually allowed |
|---|---|---|---|---|
| ICSA-16-126-01 (2016, rev. 2018) | KMC Controls Conquest BAC-5051E router | CVE-2016-4494, CVE-2016-4495 | 5.3 / 5.3 (v3) | Missing-authentication and CSRF flaws let an unauthorized remote user read configuration data from a file |
| ICSA-17-285-05 (Update A) | Siemens APOGEE PXC / TALON TC BACnet field panels | CVE-2017-9946, CVE-2017-9947 | 7.5 / 5.3 | Authentication bypass on the integrated web server (download sensitive data); path traversal exposing file-system structure |
| ICSA-25-135-03 | Siemens BACnet ATEC devices (550-440/441/445/446) | CVE-2025-40556 | 7.1 (v4) / 6.5 (v3.1) | Crafted BACnet MSTP message from the same network causes denial of service; no vendor fix planned |
The pattern across nine years of these advisories is consistent: the authentication and path-traversal bugs sit in vendor web management interfaces bolted onto BACnet field panels, not in BACnet/SC's TLS handshake, and the most recent finding is a denial-of-service in MSTP message parsing that Siemens has stated it will not patch — meaning network access control is not a stopgap there, it's the only control. A building network that segments BACnet traffic from the general IT network, and keeps vendor and contractor remote-access paths off that segment, stops most of what these advisories describe regardless of whether BACnet/SC is deployed.
A workable starting point
Find out what's actually reachableBACnet/IP's broadcast model and the routine practice of opening remote access for HVAC vendors make internet-exposed building controllers a recurring, documented finding — confirm nothing on the BACnet segment is reachable from outside the building network before anything else. Patch field panels and routers on current firmwareThe KMC Controls and Siemens findings above are implementation bugs independent of BACnet/SC; a secure transport option doesn't patch an authentication-bypass bug in a device's web server. Check whether BACnet/SC is actually negotiated, not just supported on a datasheet, on devices capable of it — unenabled support provides no protection, the same caveat that applies to DNP3 Secure Authentication. Segment regardless of the aboveIsolate BACnet/IP traffic (commonly UDP port 47808) behind firewalls from business and guest networks, consistent with CISA's standing recommendation across every advisory cited here — including the one Siemens has said it will not fix. Treat building automation as part of the same OT architecture discipline as industrial controlThe Purdue Model and NIST SP 800-82 apply to a BACnet-driven building network the same way they do to a Modbus- or DNP3-driven industrial one.
BACnet/SC gives building automation a real, standards-based answer to BACnet/IP's unauthenticated broadcast model — but it is an option a building has to actually deploy, and CISA's advisory record shows that most documented BACnet incidents so far involve devices and web interfaces with no Secure Connect layer in the picture at all. SoftWSP's OT Snapshot builds a passive, factual picture of what's actually talking BACnet on a building or campus network, and what's reachable from where, off a mirror port: see OT Snapshot.
This guide draws on BACnet International's published description of BACnet/SC, ASHRAE's published addendum PDFs, and CISA's published ICS advisories (all fetched directly). This guide is not a substitute for ASHRAE Standard 135 itself, CISA's own advisories, or an integrator's assessment of a specific site's configuration and patch level.
Sources
- BACnet International: BACnet Secure Connect (BACnet/SC)
- ASHRAE: Addendum bj to ANSI/ASHRAE Standard 135-2016 (BACnet Secure Connect Datalink Layer Option, PDF)
- ASHRAE: Addendum cc to ANSI/ASHRAE Standard 135-2020 (Network Port object updates for BACnet/SC, PDF)
- CISA ICS Advisory ICSA-16-126-01: KMC Controls Conquest BACnet Router Vulnerabilities (last revised 23 August 2018; CVE-2016-4494, CVE-2016-4495)
- CISA ICS Advisory ICSA-17-285-05 (Update A): Siemens BACnet Field Panels (last revised 16 June 2022; CVE-2017-9946, CVE-2017-9947)
- CISA ICS Advisory ICSA-25-135-03: Siemens BACnet ATEC Devices (15 May 2025; CVE-2025-40556)
Frequently asked questions
Does BACnet have authentication or encryption built in?
The base protocol does not. BACnet (Building Automation and Control Networking protocol) is standardized as ANSI/ASHRAE Standard 135, maintained on continuous maintenance by ASHRAE's Standing Standard Project Committee 135, with the current edition ANSI/ASHRAE 135-2024. Its most common transport, BACnet/IP, relies on UDP broadcasts to discover and address devices, and the base application layer has no field for a credential, session key or message signature — any device that can reach a BACnet/IP segment can issue a Who-Is, Read-Property or Write-Property request that a controller will act on. That gap is structurally the same one Modbus and, before its 2012 revision, DNP3 have: a protocol built for a trusted, physically isolated network, now commonly running on IP infrastructure that isn't isolated at all.
What is BACnet/SC, and does it actually close that gap?
BACnet Secure Connect (BACnet/SC) is a secure datalink-layer option added via Addendum 135-2016bj — introduced through ASHRAE's standard addendum process, with a 45-day public review running 21 June to 5 August of that review cycle — and later formally incorporated into Annex AB of the ASHRAE 135-2020 edition. Per BACnet International's own description, BACnet/SC replaces BACnet/IP's UDP broadcast model with a connection-oriented transport built on WebSockets and TLS, using certificates to perform peer authentication and encrypt messages so "no device on the network can determine the content of secure messages unless they have the appropriate encryption keys." Later addenda extended it further: Addendum 135-2020cd specifies the TLS 1.3 cipher-suite application profile BACnet/SC uses, Addendum 135-2020cc updated the Network Port object so a device can represent and configure its BACnet/SC settings, and Addendum 135-2020cs defined an offline certificate-exchange file format. It closes the gap for devices and links that actually implement, configure and run it — exactly like DNP3's Secure Authentication and OPC UA's security model, it changes nothing for a controller still running plain BACnet/IP alongside it, which is the common case on a mixed or legacy building network.
What do real, documented BACnet security failures actually look like?
A mix of implementation bugs in vendor web interfaces and firmware, and denial-of-service findings in the protocol-handling code — not breaks of BACnet/SC's cryptography. CISA's ICSA-16-126-01 (published 5 May 2016, last revised 23 August 2018) covers KMC Controls' Conquest BAC-5051E BACnet router, where independent researcher Maxim Rupp found that its web interface let an unauthorized user read configuration data from a file via a missing-authorization check (CVE-2016-4495, CWE-306, CVSS v3 5.3) or via a cross-site request forgery attack (CVE-2016-4494, CWE-352, CVSS v3 5.3), both exploitable remotely with low attacker skill. CISA's ICSA-17-285-05 (Update A, originally published 12 October 2017, last revised 16 June 2022) covers Siemens APOGEE PXC and TALON TC BACnet field panels: CVE-2017-9946 (CWE-288, Authentication Bypass Using Alternate Path, CVSS 7.5) let an attacker with network access to the integrated web server bypass authentication and download sensitive information, and CVE-2017-9947 (CWE-22, Path Traversal, CVSS 5.3) let a remote attacker read the device's file-system structure. Most recently, CISA's ICSA-25-135-03 (published 15 May 2025) covers Siemens BACnet ATEC devices (models 550-440, 550-441, 550-445, 550-446): CVE-2025-40556 (CWE-20, Improper Input Validation, CVSS v4 7.1 / v3.1 6.5) lets an attacker already on the same BACnet network send a specially crafted MSTP message that forces a power cycle to recover from — and as of that advisory, Siemens has no plan to fix it, leaving network-layer controls as the only mitigation. None of these are failures of BACnet/SC itself; they are bugs and design gaps in devices that, in most deployments, have no Secure Connect layer enabled to even gate who can reach them.
What should a building owner or integrator actually check first?
Three things, roughly in order of what stops the most realistic incident. First, whether the BACnet/IP network is reachable from anything other than the building controls it needs to talk to — CISA's standing advice across every advisory above is network segmentation and keeping control-system devices off the public internet, and this matters more for BACnet than for most OT protocols because building-automation gear is routinely connected for remote vendor access or cloud dashboards. Second, whether field devices and web interfaces are on current firmware: the KMC Controls and Siemens findings above are patchable implementation bugs, not something BACnet/SC configuration fixes. Third, whether BACnet/SC is actually available and negotiated on devices that support it — a controller's datasheet listing BACnet/SC support is not the same claim as a live, certificate-provisioned BACnet/SC connection running in the field, the same distinction that matters for [DNP3 Secure Authentication](/guides/dnp3-protocol-security-ot-ics/) and [Modbus Security](/guides/modbus-protocol-security-ot-ics/). Where BACnet/SC isn't yet deployed across a site, the [Purdue Model](/guides/purdue-model-ot-ics-network-architecture/)'s segmentation layer and [NIST SP 800-82](/guides/nist-sp-800-82-ot-security/)'s compensating-control guidance are the same answer this guide's companion protocol guides give: the network has to hold the weight an unauthenticated field protocol doesn't.
In this cluster
