The tool in every technician’s bag

If you’ve worked on a building automation system, you’ve probably used a free BACnet explorer. Plug a laptop into the controls network, click “Discover,” and within seconds a list of controllers fills the screen. Expand a device and you can see its points, read live values, and sometimes write a setpoint or trend a sensor.

For commissioning, troubleshooting, and day-to-day service work, that’s exactly what’s needed. The problem starts when the results of that same scan are exported to a spreadsheet and treated as the building’s asset inventory. To understand why, it helps to know how these tools actually find devices.

How a BACnet explorer finds devices

Most explorers rely on a simple request-and-response exchange built into BACnet. The tool sends a Who-Is message as a broadcast, and every BACnet device that receives it answers with an I-Am message identifying itself. On BACnet/IP networks, this traffic uses UDP port 47808, and every BACnet/IP device on the same subnet receives the broadcast [1].

Once a device has answered, the explorer reads properties from its Device object, such as the vendor name, model name, firmware revision, and application software version, and then retrieves the list of objects (points) the device contains.

Two details matter for what comes later:

• Broadcasts stop at the subnet boundary. UDP broadcasts do not cross subnets. To discover devices on other subnets, the network needs a BACnet Broadcast Management Device (BBMD) to forward broadcasts, or the explorer must register with a BBMD as a “foreign device” [1].
• MS/TP devices are reached through routers. Many field controllers sit on RS-485 MS/TP trunks rather than Ethernet. An explorer reaches them through a BACnet router, and settings on the trunk, such as Max Masters, can hide devices if they’re configured incorrectly [1].

In short, an explorer sees what its query can reach and what chooses to answer. That is both its strength and its limit.

What an explorer does well

Credit where it’s due. A good free explorer can tell you a great deal about the BACnet devices it reaches:

• Identity. Device instance number, network number, and MAC or IP address.
• Make, model, and firmware. Vendor, model, firmware revision, and application software version, read directly from the device.
• Points and live values. The device’s object list, present values, status flags, and often the ability to trend or write values.
• Configuration problems. Duplicate device instances, MS/TP addressing conflicts, and routing issues that stop devices from appearing on the front end.

For a technician verifying a new installation or chasing down why a controller dropped offline, that’s exactly the right information, delivered quickly and at no cost.

What an explorer can and can’t tell you

Can tell you	Can’t tell you
Which BACnet devices answered a Who-Is	Which devices didn’t answer, or couldn’t be reached
Vendor, model, and firmware revision of BACnet devices	Whether that firmware is end-of-life, unsupported, or vulnerable
Points, live values, and short-term trends	Modbus, Niagara/Fox, SNMP, MQTT, and IT devices on the same network
The state of the network while the laptop is connected	What changed before or after the scan
Configuration errors such as duplicate device instances	Which devices communicate with each other, and whether that traffic is protected
An export of what it found	Location, criticality, and ownership of each asset

The blind spots, one by one

1. Devices that don’t speak BACnet

A BACnet explorer speaks one protocol. Building networks rarely carry only one. Energy meters often use Modbus TCP, supervisory controllers commonly communicate over Niagara/Fox, network switches are managed via SNMP, and newer sensors may publish over MQTT. Cameras, access control panels, and workstations often share the same network. None of these show up in a BACnet scan. The CISA asset inventory guidance lists a device’s active communication protocols and ports/services among the high-priority fields an OT inventory should capture [3], and a single-protocol tool can’t fill them in.

2. Devices that didn’t answer

An empty spot in the scan doesn’t mean nothing is there. Devices can be missed because they sit on a subnet without a BBMD, because a firewall blocks UDP 47808, because they were powered off during the visit, because an MS/TP trunk’s Max Masters setting is too low, or because a gateway replies with a unicast I-Am that some software ignores [1]. A scan is only as complete as the network path between the laptop and the device, and the explorer has no way of telling you what it couldn’t reach.

3. Everything that happened before or after the scan

An explorer gives you a snapshot. Once the laptop is unplugged, nothing is recorded. Controllers get replaced, firmware gets updated, contractors add devices, and the spreadsheet doesn’t change. CISA’s guidance calls for inventory updates whenever a device is introduced or removed, “in all cases, even under emergency change authority,” and recommends regular reviews of the inventory [3]. A tool that only runs when a technician is on site can’t meet that standard by itself.

4. How devices communicate, and whether it’s protected

An explorer talks to devices one at a time. It doesn’t show which controllers talk to which supervisors, which devices reach outside the building network, or whether that traffic is encrypted. That matters because most installed BACnet traffic is not encrypted or authenticated. BACnet Secure Connect (BACnet/SC) was developed to address this, adding mutually authenticated connections secured with TLS 1.3 and eliminating reliance on broadcasts [2]. Knowing which parts of your network still run unprotected traffic is a key input for security planning, and it isn’t something an explorer reports.

5. Whether the firmware matters

An explorer will happily report that a controller is running firmware revision 3.2. It won’t tell you whether 3.2 is current, end-of-life, or has known vulnerabilities. Turning a firmware string into a maintenance or security decision still means looking it up by hand, device by device.

6. The context around each device

Where is the device physically installed? What system does it serve? How critical is it? Who is responsible for it? CISA lists physical location and asset criticality among the high-priority inventory fields [3]. An explorer can’t provide them, so someone has to add them to the spreadsheet manually and keep them up to date.

A note on “just running a scan”

An explorer is an active tool. It sends broadcasts and then reads properties and object lists from each device it finds. On a healthy BACnet/IP network, that’s usually harmless. On a slow MS/TP trunk or with older controllers, reading full object lists from every device at once can add noticeable load. NIST’s guide to OT security emphasizes that these systems have unique performance, reliability, and safety requirements that must be considered when securing them [4]. Experienced technicians know to scan deliberately. It’s one more reason a laptop scan is better suited to targeted service work than to repeated, building-wide inventory sweeps.

The hidden cost of “free”

The software costs nothing. Using it as an inventory system doesn’t. For every building, someone has to schedule a site visit, connect to each subnet (or set up foreign device registration), run the scans, export the results, merge them with other sources, add location and criticality, look up firmware status, and then repeat the whole process when the data goes stale. Across a portfolio of buildings, or across an integrator’s customer base, those technician hours add up quickly, and the result is still a point-in-time list limited to one protocol.

Getting the most from your explorer, and knowing when you’ve outgrown it

Free explorers remain the right tool for commissioning and troubleshooting. If you’re also using one to build an inventory, a few habits help:

• Scan from every subnet, or use foreign device registration with a BBMD, so you aren’t limited to the segment your laptop is on.
• Check MS/TP settings such as Max Masters before assuming a trunk is fully discovered.
• Record the date and location of each scan, so everyone knows how old the data is.
• Cross-check against other sources, such as switch tables, drawings, and the BAS front end, to catch non-BACnet and non-responding devices.

If you find you need multi-protocol coverage, an inventory that updates itself, firmware and lifecycle status, or insight into how devices communicate, you’ve likely outgrown what an explorer was designed to do. In our previous post, The Missing Middle, we described what a right-sized alternative for buildings should look like. Upcoming posts will look at the other end of the spectrum, including the hidden infrastructure costs of enterprise OT platforms.

Key Takeaways

• Free BACnet explorers are excellent commissioning and troubleshooting tools that quickly identify BACnet devices and their vendor, model, firmware, and points.
• They discover devices with Who-Is broadcasts, which don’t cross subnets without a BBMD or foreign device registration, so scan coverage depends on where the laptop is connected.
• They only see BACnet, so Modbus, Niagara/Fox, SNMP, MQTT, and IT devices on the same network are missed.
• A scan is a snapshot: it can’t show what changed after the technician left, which falls short of CISA’s call for inventories updated with every change.
• Explorers don’t show how devices communicate, whether traffic is encrypted, or whether firmware is end-of-life or vulnerable.
• The software is free, but the labor to turn scans into a current, complete inventory across many buildings is not.

References

1. Chipkin Automation Systems. BACnet Discovery & Network Architecture Reference. Chipkin Documentation Portal, updated March 2026. https://docs.chipkin.com/articles/bacnet-discovery-network-architecture-reference/
2. ASHRAE. Protecting Building Automation Systems with BACnet Secure Connect. ASHRAE eSociety, July 2019. https://www.ashrae.org/news/esociety/protecting-building-automation-systems-with-bacnet-secure-connect
3. Cybersecurity and Infrastructure Security Agency (CISA), et al. Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators. August 2025. https://www.cisa.gov/resources-tools/resources/foundations-ot-cybersecurity-asset-inventory-guidance-owners-and-operators
4. Stouffer, K., et al. Guide to Operational Technology (OT) Security, NIST Special Publication 800-82 Rev. 3. National Institute of Standards and Technology, September 2023. https://csrc.nist.gov/pubs/sp/800/82/r3/final