BACnet Explained: Building Automation Protocol and BACnet/SC

BACnet is the open data communication protocol that building automation systems use to share data and commands between controllers, sensors and operator workstations for heating, ventilation, air conditioning, lighting, access control, fire detection and elevators. It is ANSI/ASHRAE Standard 135, also published as ISO 16484-5, and maintained by the ASHRAE committee SSPC 135. Classic BACnet over IP or RS-485 has no built-in authentication, so BACnet Secure Connect (BACnet/SC) was added in 2019 to carry BACnet over mutually authenticated TLS 1.3 WebSocket connections through a hub.

This post sits next to our other one protocol per post explainers for operational technology: Modbus, OPC UA, MQTT 5 and PTP. Here we stay on BACnet: the object model with real identifiers, how Who-Is and I-Am bind devices, why broadcast and BBMDs shape every BACnet/IP network, what the lack of authentication allows (described conceptually), exactly how BACnet/SC uses TLS 1.3, WebSockets and hubs, how to split a building network into zones and conduits, what CISA, NIST and ASHRAE have published, and how to inventory BACnet devices with open source tools without writing to anything.

Key takeaways

• BACnet is ANSI/ASHRAE Standard 135. The committee first met in June 1987, the standard was first published in 1995, and the current consolidated edition is ANSI/ASHRAE 135-2024, announced on 31 December 2024 with 17 addenda folded in from the 2020 edition.
• Everything a BACnet device exposes is modelled as objects (Analog Input, Binary Output, Schedule, Device and dozens more), each with properties such as Present_Value. Devices talk through services such as ReadProperty, WriteProperty, Who-Is and I-Am.
• BACnet runs over several data links. BACnet/IP uses UDP port 47808 (0xBAC0), registered with IANA. MS/TP runs over EIA-485 twisted pair. BACnet/IP relies on broadcasts, and BACnet Broadcast Management Devices (BBMDs) forward those broadcasts between IP subnets.
• Classic BACnet was designed for physically separate building networks and has no authentication at the protocol level. A 2010 security addendum was rarely implemented and was removed from the 2020 edition, according to ASHRAE's Managed BACnet guidance.
• BACnet/SC (Addendum bj to 135-2016, approved 18 November 2019) is a new data link. It carries BACnet messages in binary WebSocket frames over TLS 1.3, with mutual certificate authentication, a hub and spoke topology, mandatory node support for a failover hub, and optional direct connections.
• BACnet/SC authenticates devices, not operations. Per operation authorization arrived separately in Addendum cp (November 2024), and an MS/TP trunk behind an SC router is still unprotected against someone with physical access.
• ISA/IEC 62443 zones and conduits, a BACnet aware router or firewall that enforces read only rules across segments, and passive monitoring remain the main controls for the large installed base of BACnet/IP and MS/TP devices.
• Inventory starts passive (a packet capture filtered on UDP 47808), then moves to targeted Who-Is and ReadProperty requests with approval. Never send WriteProperty, ReinitializeDevice or DeviceCommunicationControl during an inventory.

What BACnet is and who maintains it

BACnet stands for Building Automation and Control Network. The BACnet Committee's own site describes it as "the global data communication standard for building automation and control networks" and says it provides vendor independent interoperability for networked equipment and control devices. The committee is ASHRAE Standing Standard Project Committee 135 (SSPC 135), which developed the standard and still maintains it through continuous maintenance: individual changes are published as lettered addenda (bj, cc, cd, cp and so on) and periodically consolidated into a new dated edition.

ASHRAE's BACnet page lists the application areas the protocol was designed for: heating, ventilating and air conditioning control; fire and other life safety and security systems; energy management; lighting control; physical access control; and elevator monitoring. The same page says BACnet may be used by "mobile and cloud-hosted devices, head-end computers, general-purpose direct digital controllers, and application-specific or unitary controllers with equal effect". In practice that means one protocol covers a thermostat on a wall, a variable air volume box controller above a ceiling tile, a chiller plant controller, a lighting panel, and the operator workstation in the facilities office.

Three organisations matter in day to day BACnet work:

Timeline of BACnet and its security work

Scale claims vary by source and date, so treat them as context rather than measurements. The 2019 BACnet/SC white paper written by members of the SSPC 135 IT working group cites "more than 25 million devices worldwide" and interoperability "among over 1000 vendors". The bacnet.org standard page says BACnet is used in "hundreds of thousands of buildings globally" and, citing a market study, that it is specified in more than 60 percent of projects.

How objects, properties and services work

BACnet's first idea, in the words of its founding chair H. Michael Newman writing in ASHRAE Journal in 2013, is an object model: every function of a device is represented as a set of standard objects, and each object is "a set of properties". Each property has an identifier, a data type and a conformance code saying whether it is required or optional and whether it is read only or writable. Every object type must have Object_Identifier, Object_Name and Object_Type properties. A collection of objects is a BACnet Device, and the Device object describes the device itself: its name, vendor, model, firmware revision and protocol revision.

The standard defines object types; instances of those types in real devices are the objects. Newman counted 18 object types in BACnet-1995 and 54 in BACnet-2012, grouped into families such as basic device objects (Analog Input, Analog Output, Analog Value, Binary Input, Binary Output, Binary Value, Multi-state Input and Output), logging objects (Trend Log, Event Log), schedule objects (Calendar, Schedule), notification objects (Notification Class, Event Enrollment), lighting objects (Lighting Output, Channel) and access control objects (Access Door, Access Point, Access Credential). Later editions have added more.

A few concrete identifiers from the open source BACnet Stack's ReadProperty tool help text make this less abstract. Analog Output is object type 1. Present_Value is property identifier 85, and Priority_Array is property 87. A device instance number must be in the range 0 to 4,194,303. That upper bound is two to the power of 22, minus one, so the device instance is a 22 bit number and must be unique across the whole internetwork, not just one subnet.

Services: the verbs

Objects are the nouns; services are the verbs. Newman describes a client and server model where the client sends a service request and the server returns a service response. His 2013 article counts 38 services in five classes: alarm and event services (11), file access services (2), object access services (10), remote device management services, and virtual terminal services. The ones you meet first:

The open source BACnet Stack ships one command line tool per service, which is a good map of the service set: bacwi for Who-Is, bacrp for ReadProperty, bacrpm for ReadPropertyMultiple, bacwp for WriteProperty, bacdcc for DeviceCommunicationControl, bacrd for ReinitializeDevice, bacts for TimeSynchronization and so on. Notice how few of them are read only. That list is also your do not run list during an inventory.

Worked example 1: binding with Who-Is and I-Am

Suppose a workstation wants the room temperature from device 12001. It does not know the device's IP address or MS/TP address, and BACnet does not require it to. Newman calls this "dynamic binding".

1. The workstation broadcasts Who-Is with a low limit of 12001 and a high limit of 12001. Every BACnet device on the local network receives the packet, and every one checks whether its own instance is in the range.
2. Device 12001 replies with I-Am, carrying its Device object identifier and a few capability fields, such as the largest message it accepts. The I-Am is usually broadcast too, so any other client that wanted 12001 also learns where it is.
3. The workstation caches the address and sends ReadProperty for object Analog Input 3, property Present_Value (85). The device answers with a ReadProperty-ACK containing the value, for example 21.4 as a REAL.

Now widen the range. A Who-Is with no limits asks every device on every reachable network to answer. On a site with 1,200 devices that is 1,200 I-Am replies triggered by one small packet, and if the I-Am replies are broadcast and forwarded by BBMDs, every network segment sees every reply. The BACnet Stack's tool documentation suggests caching the result once (bacwi -1 > address_cache) so later tools can skip Who-Is entirely, which is exactly the habit you want during an inventory.

Worked example 2: commandable outputs and priorities

WriteProperty to a commandable property such as the Present_Value of an Analog Output does not simply overwrite the value. The request may carry a priority, and the device keeps a Priority_Array of commands from different sources, so a life safety override can take precedence over a schedule, which takes precedence over a default. You can read that array with bacrp 123 analog-output 101 priority-array, the example in the BACnet Stack help text. The security point is that a write at a high priority from any address that can reach the device will be honoured on classic BACnet, because nothing in the request proves who sent it. That is also why the BACnet Stack's 2026 decoder fixes for WriteProperty and WritePropertyMultiple, discussed later, matter: the code paths that parse those requests are reachable by anyone on the network.

BIBBs, device profiles and PICS

Because BACnet is large, the standard defines BACnet Interoperability Building Blocks (BIBBs). Each BIBB names one capability and which side performs it. DS-RP-A is "Data Sharing, ReadProperty, A side" (the client that can send ReadProperty) and DS-RP-B is the server that can answer it. Newman counted 111 BIBBs in BACnet-2012. Device profiles such as B-OWS (Operator Workstation), B-BC (Building Controller), B-ASC (Application Specific Controller) and B-SS (Smart Sensor) bundle BIBBs, and every product documents what it supports in a Protocol Implementation Conformance Statement (PICS). For BACnet/SC, the Managed BACnet guide adds hub and direct connection BIBBs (NM-SCH-B for hubs, NM-SCDC-A and NM-SCDC-B for direct connections) and asks manufacturers to list supported TLS versions and cipher suites in the PICS.

The PICS is the first document to ask for in procurement. It tells you which services a device will accept, which tells you which ones you must filter.

BACnet/IP, MS/TP and BBMDs, and why broadcast matters

Newman's article describes the original data link choice as pragmatic: the committee asked vendors what networks they were using and standardised those. The Wireshark BACnet page lists ARCNET, MS/TP over RS-485, point to point over RS-232, LonTalk and Ethernet, plus BACnet/IP over UDP. BACnet/IPv6 and BACnet/SC came later.

BACnet/IP and UDP port 47808

IANA's port registry lists bacnet on port 47808 for both TCP and UDP, registered on 10 February 2011. In hexadecimal 47808 is 0xBAC0, a small joke that also makes it easy to spot in a packet capture. The Managed BACnet guide notes that the BACnet/IP UDP port is configurable within 47808 to 47832 and 49152 to 65535, so a scan of only 47808 can miss a site that uses 47809 for a second BACnet network on the same subnet.

Every BACnet/IP packet starts with a BACnet Virtual Link Control (BVLC) header that says what kind of BVLL message it is: an original unicast NPDU, an original broadcast NPDU, a forwarded NPDU from a BBMD, a foreign device registration, or a read or write of the broadcast distribution table. Wireshark decodes this layer as bvlc, the network layer as bacnet and the application layer as bacapp.

MS/TP

Master Slave/Token Passing is the BACnet committee's own protocol for EIA-485 twisted pair. Masters pass a token; only the token holder may transmit. It is cheap, it runs long distances on existing wiring, and the Managed BACnet guide's history notes that "the vast majority of BACnet devices continued to use low-cost communication methods, principally BACnet MS/TP" even after BACnet/IP arrived. Most terminal unit controllers in a building still sit on MS/TP trunks behind a BACnet router that connects them to the IP network.

From a security view, MS/TP has no addressing beyond a one octet MAC and no protection at all. Anyone who can clip onto the trunk in a ceiling void or riser can listen and transmit. The BACnet Stack even ships mstpcap, a tool that captures MS/TP traffic from an RS-485 adapter into a Wireshark file for troubleshooting.

BBMDs and foreign devices

BACnet/IP depends on broadcast for discovery (Who-Is, Who-Has), for time synchronisation and for some alarm and event traffic. IP routers do not forward subnet broadcasts, so a campus with controllers on several subnets needs a BACnet Broadcast Management Device on each subnet. Each BBMD holds a Broadcast Distribution Table (BDT) listing its peer BBMDs. When a broadcast arrives on its subnet, the BBMD forwards it to each peer, which rebroadcasts it locally.

A device on a subnet without a BBMD, such as a laptop on a VPN, can register with a BBMD as a foreign device. The BBMD keeps a Foreign Device Table (FDT) and sends broadcasts to registered foreign devices as unicast for the registration's time to live. The BACnet Stack has tools to read both tables (bacrbdt, bacrfdt) and to write a BDT (bacwbdt), and its environment variables show the moving parts: BACNET_BBMD_ADDRESS, BACNET_BBMD_PORT and BACNET_BBMD_TIMETOLIVE.

Why this matters for security:

• A BBMD is a broadcast amplifier by design. One Who-Is with no range on one subnet becomes a broadcast on every subnet in the BDT, and the I-Am replies may travel back the same way.
• A BBMD that accepts foreign device registrations from anywhere lets a remote host receive every broadcast on the BACnet internetwork, and send broadcasts into it. The Managed BACnet guide's history notes that some BACnet/IP devices "inadvertently became Internet connected" once they were placed on shared networks.
• A loop in BDT configuration (two BBMDs on the same subnet both forwarding, or tables that disagree) can cause broadcast storms that look like an attack but are a configuration error.
• The Addendum bj problem statement lists these as reasons IT teams resist BACnet/IP: "UDP broadcasts that may propagate through the entire network are not acceptable" and a "demand for fixed IP addresses, in particular for BBMDs".

Why classic BACnet has no authentication, and what that allows

BACnet was designed between 1987 and 1995 for networks that were physically separate from everything else. The Managed BACnet guide's history appendix is frank about it: during early deployments building automation systems were isolated from IT systems "in almost all cases", cybersecurity "was not a significant concern", and it "was generally believed that an HVAC system was not likely to be targeted". Attacks on those systems required direct access to the BAS network.

That changed in 1999 with BACnet/IP. The committee responded with a BACnet specific security method covering every data link, published as an addendum in 2010 (it became Clause 24, Network Security). In the guide's words, "few manufacturers implemented this addendum, and it was removed from the 2020 edition". The Addendum bj text records the removal of Clause 24 "for clarity and increased security". So for a classic BACnet/IP or MS/TP device, the honest answer is that the protocol carries no proof of who sent a message and no encryption. The 2025 CISA, FBI, EPA and DOE fact sheet on primary mitigations for operational technology makes the same general point: OT devices "lack authentication and authorization methods that are resistant to modern threats".

What that allows, described as categories rather than steps:

The last row is where software supply chain meets building automation. A keyword search of the US National Vulnerability Database for "BACnet" on 23 October 2026 returned 52 records, 14 of them first published in 2026. Several 2026 records describe the open source BACnet Stack C library, which its README says has been "included in many products that successfully completed BTL testing". The descriptions cover out of bounds reads in the ReadPropertyMultiple and WritePropertyMultiple decoders, a length underflow in the WriteProperty decoder and undefined behaviour in integer decoding, fixed in release 1.4.3 and the 1.5.0 release candidates. We mention them as a pattern, not a story: a protocol library embedded in many controllers means one parser fix has to travel through many firmware release cycles before it reaches a building.

None of this means every BACnet network is about to be attacked. It means the controls have to come from outside the classic protocol: network design, BACnet aware filtering, monitoring and, for new work, BACnet/SC.

How BACnet Secure Connect works

BACnet/SC is a new data link layer, not a new application protocol. Objects, properties and services are unchanged; only the way messages travel between devices changes. The 2019 white paper by the SSPC 135 IT working group summarises the goals: TLS 1.3 security, no static IP addresses, no dependence on network broadcast, no BBMDs, and easy passage through firewalls and NAT. It also says BACnet/SC "preserves 100% of the capabilities" of BACnet and works with existing networks through ordinary BACnet routing.

The stack, layer by layer

The white paper's layer diagram puts it plainly. All of BACnet, including the BACnet/SC data link, is the application. WebSockets over HTTP is the application layer, TLS 1.3 and TCP form the transport, IPv4 or IPv6 is the internet layer, and any link that carries IP (Ethernet, Wi-Fi, 4G or 5G) is underneath. Addendum bj specifies that fully encoded BACnet/SC Virtual Link Control (BVLC) messages are sent as WebSocket binary frames, opcode 0x2, as defined in RFC 6455.

Hubs, failover hubs and direct connections

BACnet/SC uses a hub and spoke topology. A hub function accepts secure WebSocket connections from nodes and relays traffic: unicast messages to the destination node, broadcast messages to every connected node. A node can be a sensor, a controller, a router to legacy BACnet networks, or the operator workstation. Because a single hub is a single point of failure, every node must support connecting to a failover hub when the primary is unreachable. Nodes may optionally open direct connections to each other for unicast traffic, while still keeping their hub connection up.

The hub is just a function, so it can live in a controller, a router, a server in the building or a host in the cloud. The white paper's first scenario is a building that cannot accept inbound connections: a BACnet/SC router inside the building makes an outbound connection to a hub in the cloud, the facility manager's workstation connects to the same hub, and the building firewall only needs to allow outbound HTTPS style connections.

WebSocket subprotocols and BVLC-SC messages

Addendum bj defines two WebSocket subprotocol names, registered with IANA on 19 December 2019:

• hub.bsc.bacnet.org for connections from a node to a hub function
• dc.bsc.bacnet.org for direct connections between nodes

Peers are named by wss:// URIs, so devices can use DNS names and DHCP rather than fixed addresses. The BACnet/SC BVLC messages, from Table YY-1 of Addendum bj:

Nodes are addressed by a 6 octet virtual MAC address (VMAC). Broadcasts use the local broadcast VMAC X'FFFFFFFFFFFF'. Every device with a BACnet/SC port also has a device UUID as defined in RFC 4122, generated before first deployment and kept persistently, which identifies the device regardless of its VMAC or device instance number. The Managed BACnet guide notes the default timers recommended in Addendum cc: 10 seconds to wait for a connection, 10 seconds to wait for a disconnect, and 300 seconds for the heartbeat timeout.

TLS 1.3 and mutual authentication

Addendum bj requires TLS 1.3 as specified in RFC 8446. Support for other TLS versions or extra cipher suites is "a local matter" that must be listed in the PICS. Addendum cd, approved in August 2021, sets the minimum profile every implementation must support:

• Cipher suite TLS_AES_128_GCM_SHA256
• Digital signature ecdsa_secp256r1_sha256
• Key exchange secp256r1

The Managed BACnet guide recommends that devices also support TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256, because some IT departments prefer them, and says a device able to fall back to TLS 1.2 must offer a way to prevent that downgrade in a strict TLS 1.3 system.

Every BACnet/SC connection uses mutual TLS. Addendum bj says both the initiating and accepting peer shall:

1. Validate that the peer's operational certificate is well formed.
2. Validate that it is active on the current date and not expired.
3. Validate that it is not revoked, if revocation information is available.
4. Validate that it is directly signed by one of the locally configured CA certificates.

The addendum then says no additional checks are performed by default "to ensure interoperability". Common Name, Distinguished Name or Subject Alternative Name matching only happens if the installation enables it. Two consequences follow. First, unlike a web browser, a BACnet/SC device validates against the CA that directly signed the peer certificate, not any CA in a chain, so you need one dedicated issuing CA per BACnet/SC network. Second, any certificate signed by that CA is a valid member of the network, which makes protecting the CA key and controlling what it signs the real access control decision.

Certificates and their lifecycle

Addendum bj defines operational credentials as a device's certificate, its private key and the accepted signing CA certificates. Before a device joins a live network it must hold a CA certificate store and a unique operational certificate with its private key, "issued and directly signed" by a CA in that store. Addendum cc later limited each BACnet/SC port to at most two issuer certificate files: one for the current CA and one for a CA you are migrating to, with the old one removed once the transition ends. Addendum cc also added certificate management through the Network Port object, so a workstation can replace a device's certificate online, and Addendum cs (June 2024) defined a standard file format for exchanging certificate data during offline onboarding.

The Managed BACnet guide's certificate recommendations are worth reading even if you are an owner rather than a manufacturer: devices should generate a certificate signing request so the private key never leaves the device, there should be no global factory credentials, operational certificates should be renewed before they expire, an operational certificate's lifetime should sit inside its signing certificate's lifetime, and if a device is compromised you should issue a new issuer certificate and new operational certificates to the remaining devices.

For background on how certificate authorities and chains work in general, see what a certificate authority is.

What BACnet/SC does not do

BACnet/SC is a big step, and it is easy to overstate. From the primary sources:

• It authenticates devices, not users or operations. Any authenticated node can send any BACnet service to any other node. The Managed BACnet guide says plainly that network access through an operational certificate "is not sufficient" for authorization. Addendum cp (November 2024) adds device authentication and request authorization data, and the guide notes that devices at protocol revision 29 or later may implement it, so support depends on firmware.
• It does not protect what sits behind a router. The white paper's mixed scenario says an SC to MS/TP router "does not secure the MS/TP trunk itself from actors with physical access to the trunk".
• It assumes the endpoints are trustworthy. Addendum bj states that both peers are assumed trusted "including all code they execute", and that validating that code and its origin is outside the standard's scope. Firmware integrity and the libraries inside it are your problem, not the protocol's.
• It moves filtering to the endpoints. Because messages are inside TLS, the Managed BACnet guide notes they are only visible and filterable at connection endpoints, and that filtering at the hub is weak because nodes can bypass it with direct connections.
• It is a data link, so it only works on IP networks.

Classic BACnet/IP compared with BACnet/SC

Step by step: a BACnet/SC lab with the open source BACnet Stack

The clearest way to understand BACnet/SC is to watch a hub and a node authenticate each other on your own machine. The open source BACnet Stack (GPL with a linking exception, maintained on GitHub and SourceForge) includes a BACnet/SC hub simulator and client tools that can be built for the SC data link. Run this on an isolated lab host or VM, never on a production building network.

Step 1: build the tools for the BACnet/SC data link

The project's Makefile notes that BACnet/SC builds need libwebsockets, libssl and libcrypto. On a Debian or Ubuntu lab host:

sudo apt-get install -y build-essential git libwebsockets-dev libssl-dev libcap-dev
git clone https://github.com/bacnet-stack/bacnet-stack.git
cd bacnet-stack
git tag --list 'bacnet-stack-1.*' | tail -5   # pick a current release tag
make clean
make bsc          # builds the client tools with BACDL=bsc
make sc-hub       # builds the BACnet/SC hub simulator
ls bin/ | grep -E 'bacwi|bacrp|bacschub'

Step 2: create a lab CA and operational certificates

Addendum bj requires each operational certificate to be directly signed by a CA in the device's store, and Addendum cd's minimum profile is ECDSA on the P-256 curve. This lab CA is for testing only; in production the private key for the issuing CA belongs in a hardened, offline or HSM backed system.

mkdir -p lab-certs && cd lab-certs

# Lab issuing CA (P-256, matches the Addendum cd minimum profile)
openssl ecparam -name prime256v1 -genkey -noout -out ca_key.pem
openssl req -x509 -new -key ca_key.pem -sha256 -days 365 \
  -subj "/CN=Lab BACnet SC Issuing CA" -out ca_cert.pem

# Hub operational certificate: key stays here, CA signs a CSR
openssl ecparam -name prime256v1 -genkey -noout -out hub_key.pem
openssl req -new -key hub_key.pem -subj "/CN=bsc-hub-lab" -out hub.csr
openssl x509 -req -in hub.csr -CA ca_cert.pem -CAkey ca_key.pem \
  -CAcreateserial -sha256 -days 180 -out hub_cert.pem

# Node (client tool) operational certificate
openssl ecparam -name prime256v1 -genkey -noout -out node_key.pem
openssl req -new -key node_key.pem -subj "/CN=bsc-node-lab" -out node.csr
openssl x509 -req -in node.csr -CA ca_cert.pem -CAkey ca_key.pem \
  -CAcreateserial -sha256 -days 180 -out node_cert.pem

# Check: each operational certificate is directly signed by the CA
openssl verify -CAfile ca_cert.pem hub_cert.pem node_cert.pem
cd ..

Note the operational certificate lifetimes (180 days) sit inside the CA lifetime (365 days), matching the Managed BACnet recommendation.

Step 3: start the hub

The hub simulator reads its configuration from environment variables documented in its help text and in the project's bin/bsc-server.sh example.

export BACNET_SC_ISSUER_1_CERTIFICATE_FILE=lab-certs/ca_cert.pem
export BACNET_SC_OPERATIONAL_CERTIFICATE_FILE=lab-certs/hub_cert.pem
export BACNET_SC_OPERATIONAL_CERTIFICATE_PRIVATE_KEY_FILE=lab-certs/hub_key.pem
export BACNET_SC_HUB_FUNCTION_BINDING="50050"   # local port for the hub function
./bin/bacschub 111 LabHub

The project's example script also sets BACNET_SC_SELFSIGNED_ENABLED=1 because its bundled sample certificates are self signed, and its own comment says not to set it in production deployments that use CA issued certificates. With a real lab CA as above, leave it unset so you exercise the same validation a production network would.

Step 4: connect a node and run read only services

In a second terminal, point the client tools at the hub as their primary and failover hub, using the node certificate:

export BACNET_SC_ISSUER_1_CERTIFICATE_FILE=lab-certs/ca_cert.pem
export BACNET_SC_OPERATIONAL_CERTIFICATE_FILE=lab-certs/node_cert.pem
export BACNET_SC_OPERATIONAL_CERTIFICATE_PRIVATE_KEY_FILE=lab-certs/node_key.pem
export BACNET_SC_PRIMARY_HUB_URI="wss://127.0.0.1:50050"
export BACNET_SC_FAILOVER_HUB_URI="wss://127.0.0.1:50050"

./bin/bacwi 111 111                     # Who-Is for device 111, relayed by the hub
./bin/bacrp 111 device 111 object-name  # ReadProperty on the hub's Device object

Now break it on purpose. Sign a second node certificate with a different CA and try again: the TLS handshake fails before any BACnet message is exchanged, which is the whole point of the data link. Then let a certificate expire (issue one with -days 1 and wait, or set the lab clock forward) and watch the connection fail rule 2 of the mutual authentication list.

Step 5: look at it on the wire

sudo tcpdump -i lo -w bsc-lab.pcap 'tcp port 50050'
# then open bsc-lab.pcap in Wireshark

You will see a TCP handshake, a TLS 1.3 handshake, and encrypted application data. You will not see object names or property values, which is exactly why monitoring a BACnet/SC network relies on endpoint logs and hub connection status rather than on decoding packets in the middle.

How to segment and monitor a building network

Most buildings will run classic BACnet/IP and MS/TP for many years, so segmentation is the main control. ISA/IEC 62443 is the usual framework. The ISA page describes the series as requirements and processes for "electronically secure industrial automation and control systems" and lists building automation among the sectors it covers. ANSI/ISA-62443-3-2-2020, "Security risk assessment for system design", is the part that defines how to divide a system into zones (groups of assets with shared security requirements) and conduits (the communication paths between zones). Parts 3-3 (system requirements and security levels) and 4-2 (component requirements) are the ones the Managed BACnet guide says most influenced its recommendations.

A practical zone and conduit model for a building

The Managed BACnet guide's segmentation chapter adds BACnet specific rules on top of IP firewalls, because ordinary firewalls cannot see BACnet service choices. Its recommendations for a BACnet firewall or router include:

• Rules that can match on BACnet network number, router port, BACnet MAC address, source or destination device instance, and the confirmed or unconfirmed service choice.
• A default of drop when no rule matches (explicit enable rules), which it maps to ISA/IEC 62443-3-3 requirement SR 5.2 at security level 2.
• Ready made rule sets for blocking time synchronisation, blocking global broadcasts, enforcing read only access from a given segment, allowing control only from known devices, and preventing peer segments from reaching each other while the backbone can reach all of them.
• Logging, alerts and per rule counters when a rule fires.
• An "island mode" that takes a router port out of service to isolate a segment during an incident, which it maps to SR 5.2 at security level 3, with the disable mechanism itself requiring authorization.

Its worked example is useful as a design pattern: a BACnet/SC backbone with authenticated workstations, and a floor level BACnet/IP field network where anyone with physical access would otherwise "have full access to all BACnet network segments". The router between them allows full access from the backbone down, read only access from the field network up, and blocks time synchronisation across the boundary.

It also warns about the conduit people forget: built in cellular modems or VPN tunnels added for commissioning. Recommendation NSEG-4 says devices should not include remote access paths that bypass IT firewalls, and NSEG-1 says devices must be able to be onboarded and operated without internet access.

Monitoring what you cannot yet secure

For classic BACnet, passive monitoring at the conduits gives you most of the visibility you need without touching a controller:

# Capture BACnet/IP at a SPAN port or mirror on the backbone
sudo tcpdump -i eth1 -w bacnet-$(date +%F).pcap 'udp portrange 47808-47832'

# Summaries with tshark (Wireshark's command line tool)
tshark -r bacnet-2026-10-23.pcap -Y 'bacnet || bvlc || bacapp' -q -z io,phs
tshark -r bacnet-2026-10-23.pcap -Y 'bacapp' \
  -T fields -e ip.src -e ip.dst -e bacapp.type -e bacapp.confirmed_service \
  | sort | uniq -c | sort -rn | head -40

Adjust the port range to what your site actually uses; the Managed BACnet guide notes BACnet/IP ports can be configured from 47808 to 47832 and from 49152 to 65535. For BBMD changes, a display filter on bvlc shows distribution table and foreign device table messages, and fields such as bvlc.bdt_ip and bvlc.fdt_ip show which addresses are being added. The things worth alerting on in a building are few and specific: WriteProperty or WritePropertyMultiple from any address that is not a known workstation or server; DeviceCommunicationControl or ReinitializeDevice from anywhere; unbounded Who-Is from a new address; a new device instance or a duplicate one; a new foreign device registration on a BBMD; changes to a BBMD's distribution table; and any BACnet traffic crossing the enterprise boundary. For BACnet/SC, watch hub connection logs instead: new certificates, failed handshakes, nodes flapping between primary and failover hub, and certificates close to expiry.

What CISA, NIST and ASHRAE have published about building automation exposure

You do not need a vendor report to make the case for this work. The primary publications are clear.

Two points stand out. First, the CISA fact sheet's top mitigation, remove OT connections from the public internet, applies directly to BACnet/IP: a controller answering on UDP 47808 to the internet is answering anyone's Who-Is and ReadProperty. Second, NIST's OT guide is under revision right now, so if you write building security policy this quarter, cite Revision 3 and plan to check the Revision 4 changes.

How to inventory BACnet devices safely in read only mode

An inventory is where good intentions break buildings. Controllers are small embedded systems that run occupied spaces; some respond badly to unexpected traffic, and some sites still remember the guide's example of curious students who "accidentally interfere" with BACnet communication. Follow these rules before any command:

• Get written approval from the building owner and the facilities team, and agree a window outside occupied hours.
• Start passive. A capture at a mirror port shows most devices that talk regularly, without sending a single packet.
• Remember that every active BACnet client is itself a BACnet device. Pick a device instance number you have confirmed is unused, or you will create a duplicate.
• Use only Who-Is with a bounded range, and ReadProperty or ReadPropertyMultiple. Never run bacwp, bacwpm, bacrd, bacdcc, bacts, bacwbdt, bacco or bacdo during an inventory.
• Do not register as a foreign device on a production BBMD unless the owner explicitly wants a cross subnet sweep; scan one subnet at a time.
• Rate limit. Space requests out and stop at the first sign of a device that resets or stops answering.

Step 1: passive discovery

sudo tcpdump -i eth1 -w passive.pcap 'udp portrange 47808-47832'
# leave it running through at least one schedule change, then:
tshark -r passive.pcap -Y 'bacapp.unconfirmed_service == 0' \
  -T fields -e ip.src -e bacapp.instance_number | sort -u > i-am-sightings.txt

I-Am is unconfirmed service 0 in BACnet's enumeration, and devices often announce themselves at startup or in response to another workstation's Who-Is, so a long enough capture builds a first device list for free. Field names can differ slightly between Wireshark versions; check the BACnet APDU display filter reference for yours.

Step 2: a bounded Who-Is with the BACnet Stack

Build the tools for the default BACnet/IP data link (make clean all), then:

export BACNET_IFACE=eth1            # the interface on the BACnet subnet
export BACNET_IP_PORT=47808         # the site's BACnet/IP port
export BACNET_APDU_TIMEOUT=3000     # milliseconds; the default
./bin/bacwi 1000 1999 > address_cache   # one bounded range at a time
cat address_cache

The tool help says a device instance range can be given as a minimum and a maximum, and the tools read address_cache from the current directory so later commands can skip Who-Is. The output ends with a device count, and bacwi marks duplicate device instances with a leading semicolon and a duplicate count, which is often the first configuration problem an inventory finds.

Step 3: read identity properties only

for dev in $(awk '/^ *[0-9]+/ {print $1}' address_cache); do
  for prop in object-name vendor-name model-name firmware-revision \
              application-software-version protocol-revision location; do
    printf '%s %s: ' "$dev" "$prop"
    ./bin/bacrp "$dev" device "$dev" "$prop"
    sleep 1
  done
done | tee device-identity.txt

Firmware revision, application software version and protocol revision are the three properties that matter most for security. Protocol revision tells you which addenda a device can support: the Managed BACnet guide notes that Addendum cc certificate management through the Network Port object cannot be implemented until protocol revision 24, and that devices at revision 29 or later may implement Addendum cp authorization.

Step 4: Python alternative with BACpypes3

BACpypes3 is an open source Python BACnet library (version 0.0.110 on PyPI, released 24 September 2026). Running the module directly gives a shell for examining the local BACnet internetwork, its devices and their objects:

python3 -m venv bacnet-inv && . bacnet-inv/bin/activate
pip install bacpypes3
python3 -m bacpypes3 --help    # set the address and an unused device instance
python3 -m bacpypes3           # then type 'help' at the prompt

Use only the discovery and read commands in that shell, with the same rules as above.

Step 5: single host checks with Nmap

The Nmap scripting engine includes a bacnet-info script that sends standard requests to one host and reports vendor, instance number, firmware, application software, object name, model, description and location. It is in the discovery and version categories:

nmap -sU -p 47808 --script bacnet-info 10.20.30.41

Point it at one known controller at a time, never at a whole range during occupied hours. The script's own notes say a device that answers with a BACnet error is still positively identified as a BACnet device.

Step 6: record the result where it will be used

Write the results into your OT asset inventory with the kind of attributes CISA's guidance lists, such as asset type, model, IP address, firmware and software version, physical location, active communication protocols and time source. CISA's guidance also organises assets into ISA/IEC 62443 zones and conduits, so record which zone each controller belongs to. Add the BACnet specifics: device instance, network number, MAC address, BBMD or SC hub membership, protocol revision, and whether the device supports BACnet/SC. That inventory is what turns a firmware advisory into a work order for named devices.

Common mistakes

• Treating BACnet/SC as a firewall. It authenticates devices on the SC network. It does not filter services, it does not authorize operations without Addendum cp, and it does nothing for the MS/TP trunk behind an SC router.
• One CA for everything. BACnet/SC validates against the directly signing CA, and any certificate that CA signs joins the network. Use a dedicated issuing CA per BACnet/SC network and protect its key like a master key to the building.
• Turning on self signed acceptance in production. Lab conveniences such as accepting self signed peers remove the authentication you deployed BACnet/SC to get.
• Forgetting certificate expiry. A hub certificate that expires overnight disconnects every node on the network. Track expiry dates and renew well inside the CA's lifetime.
• Unbounded Who-Is through BBMDs. One command becomes a site wide broadcast and a flood of I-Am replies. Bound the range and scan one subnet at a time.
• Open foreign device registration. A BBMD that accepts registrations from any address extends the building network to whoever registers.
• BACnet/IP reachable from the internet. The CISA, FBI, EPA and DOE fact sheet's first mitigation is to remove OT connections to the public internet. Use a brokered remote access path instead.
• Commissioning modems left in place. Cellular or VPN paths added during construction bypass every firewall you designed afterwards.
• Scanning only port 47808. Sites can run BACnet/IP on other ports in the configured ranges, and MS/TP devices never appear on IP at all.
• Inventory with write capable tools. Every write, reinitialize or communication control tool should be absent from the inventory host's path.
• Ignoring the libraries inside the firmware. Parser bugs in protocol libraries are fixed upstream long before every product that embeds them ships an update. Ask suppliers which BACnet stack and version their firmware uses.

FAQ

What is BACnet used for?

BACnet carries data and commands between building automation devices: HVAC controllers, chillers and boilers, lighting panels, access control, fire and life safety systems, elevator monitoring, meters and operator workstations. It lets products from different manufacturers share values such as temperatures, setpoints, alarms and schedules using one object and service model.

What port does BACnet use?

BACnet/IP uses UDP port 47808 (0xBAC0) by default, registered with IANA. Sites can configure other ports in the ranges 47808 to 47832 and 49152 to 65535. BACnet/SC uses TCP with TLS and secure WebSockets on whatever port the hub or direct connection listener is configured for, addressed with a wss:// URI.

What is the difference between BACnet/IP and BACnet MS/TP?

BACnet/IP carries BACnet messages in UDP packets over IP networks. MS/TP (Master Slave/Token Passing) carries them over EIA-485 twisted pair wiring using token passing, with a one octet MAC address. Most buildings use both: MS/TP for terminal controllers and BACnet/IP for building controllers and workstations, connected by BACnet routers.

What is a BBMD in BACnet?

A BACnet Broadcast Management Device forwards BACnet/IP broadcasts between IP subnets, because IP routers do not forward subnet broadcasts. Each BBMD has a Broadcast Distribution Table of peer BBMDs and can accept foreign device registrations from hosts on subnets without a BBMD.

Is BACnet secure?

Classic BACnet over IP, MS/TP or Ethernet has no authentication or encryption at the protocol level, so security depends on network isolation, BACnet aware filtering and monitoring. BACnet/SC adds mutual TLS 1.3 authentication and encryption for devices that support it. Per operation authorization came later in Addendum cp and depends on device firmware.

What is BACnet Secure Connect (BACnet/SC)?

BACnet/SC is a BACnet data link defined in Addendum bj to ANSI/ASHRAE 135-2016, approved on 18 November 2019, and included as Annex AB in later editions. It carries BACnet messages in binary WebSocket frames over TLS 1.3 with mutual certificate authentication, using a hub and spoke topology with a failover hub and optional direct connections.

Does BACnet/SC replace BBMDs?

On a BACnet/SC network, yes. The hub function relays broadcasts to connected nodes, so no BBMDs or broadcast distribution tables are needed. Legacy BACnet/IP networks connected through a BACnet router may still use BBMDs on their side.

Can I run BACnet/SC alongside existing BACnet/IP and MS/TP devices?

Yes. BACnet routers connect BACnet/SC networks to BACnet/IP and MS/TP networks, so you can add an SC backbone and migrate devices over time. Remember that the legacy networks behind those routers keep their original lack of authentication, so filter at the router.

Who maintains the BACnet standard?

ASHRAE's Standing Standard Project Committee 135 (SSPC 135), known as the BACnet Committee, maintains ANSI/ASHRAE Standard 135. It is also published internationally as ISO 16484-5. BACnet International runs the BACnet Testing Laboratories and interoperability programs.

How do I find BACnet devices on my network without disrupting them?

Start with a passive capture filtered on the site's BACnet/IP ports, then, with approval, send a bounded Who-Is on one subnet and read identity properties with ReadProperty only. Never run write, reinitialize, communication control or time sync tools during an inventory, and choose an unused device instance for your own client.

Where Safeguard fits

Safeguard does not monitor BACnet traffic, configure BBMDs or BACnet/SC hubs, manage certificates for building devices, inventory controllers on a building network or scan controller firmware. Nothing in the segmentation, BACnet/SC or inventory steps above depends on it. The honest connection is the software around the building: integration services, gateways, analytics jobs and supervisory applications that teams build themselves, often with open source BACnet libraries such as BACpypes3 from PyPI or the BACnet Stack C library, and often shipped as container images.

For those applications and images, Safeguard's software composition analysis builds a dependency inventory of your own code, container scanning shows which images carry which package versions, and SBOM generation and analysis records the result in SPDX or CycloneDX. The platform shows which projects contain a given component and version, vulnerability matching and reachability analysis help you decide what to fix first, and policies and gates can stop a build that pulls in a known vulnerable version. When the next advisory lands for a BACnet library, the question "which of our services still ship the old version" has a quick answer. See using SBOMs to find affected products fast.

Controller firmware is a different matter: when the vulnerable library is inside a vendor's controller, the fix has to come from that vendor's firmware release. Still, every BACnet gateway, integration service and analytics job your team writes pulls open source components through the same package managers and base images as any other software. Keeping those dependencies current is the part of building automation security that sits squarely in your own build pipeline.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, SBOM and remediation workflows, not BACnet monitoring or building network security. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Pointed at a BACnet integration service or a gateway container image your team builds, the same scan lists the packages and versions inside it and their known vulnerabilities, so you know which images to rebuild after a protocol library advisory.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: ask it to fix the lodash CVE in a repository and watch it read the finding and the advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with your approval, and push nothing. The same approve each step flow applies when you bump a BACnet library in a Python or Node.js integration service that talks to your building controllers.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. You can then ask which of your projects ship a given package version, such as a specific BACpypes3 release, and get the answer from your own scan data rather than from memory.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• BACnet Committee (ASHRAE SSPC 135) home page and news
• BACnet Committee: About the BACnet Standard
• BACnet Committee: History of BACnet
• BACnet Committee: ANSI/ASHRAE 135-2024 Now Published (31 December 2024)
• BACnet Committee: BACnet Secure Connect Reference Implementation Released
• ASHRAE: BACnet, the ASHRAE Building Automation and Control Networking Protocol
• ASHRAE: ANSI/ASHRAE Addendum bj to ANSI/ASHRAE Standard 135-2016 (BACnet Secure Connect), approved 18 November 2019
• ASHRAE SSPC 135 IT Working Group: BACnet Secure Connect, A Secure Infrastructure for Building Automation (white paper, 2019)
• ASHRAE: Managed BACnet Guidance, Volume 1: Manufacturer's Guide, Version 1 (2025)
• H. Michael Newman: BACnet Explained, Part One, ASHRAE Journal, November 2013
• BACnet International
• IANA: Service Name and Transport Protocol Port Number Registry
• IANA: WebSocket Protocol Registries (subprotocol names)
• RFC 6455: The WebSocket Protocol
• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
• ISA: ISA/IEC 62443 Series of Standards
• NIST SP 800-82 Rev. 3: Guide to Operational Technology (OT) Security
• NISTIR 8259: Foundational Cybersecurity Activities for IoT Device Manufacturers
• CISA, FBI, EPA and DOE: Primary Mitigations to Reduce Cyber Threats to Operational Technology
• CISA: Foundations for OT Cybersecurity, Asset Inventory Guidance for Owners and Operators
• NVD CVE API 2.0: keyword search for BACnet (queried 23 October 2026)
• Wireshark Wiki: BACnet protocol page
• Wireshark: BVLC display filter reference
• Wireshark: BACnet APDU (bacapp) display filter reference
• BACnet Stack (open source C library) on GitHub
• BACnet Stack: command line tools and environment variables (bin/readme.txt)
• BACpypes3 documentation
• BACpypes3 on PyPI
• Nmap NSE documentation: bacnet-info

Last reviewed: 23 October 2026. BACnet addenda, ISA/IEC 62443 parts and NIST SP 800-82 are all under active revision; check the pages above for the edition and protocol revision your devices actually support.