The Missing Middle

Quick Summary

Building owners and systems integrators who want to know what is on their building automation networks usually have two choices. Free BACnet explorer tools are fast and inexpensive, but they see only one protocol at a single moment in time. Enterprise OT security platforms see much more, but they were designed for refineries, utilities, and factories, and their cost, infrastructure, and staffing requirements rarely fit a single office building, school, or hospital campus. This post explains why building OT discovery has fallen into this gap, what each option does well, and what a right-sized “middle” approach should look like.

The visibility problem nobody budgets for

Ask a facility manager how many controllers, gateways, meters, and supervisors are on their building automation network, and the honest answer is often “I’m not sure.” The original as-built drawings may be years out of date. Devices have been added by different contractors, swapped during repairs, and reflashed during service calls. Some were installed by vendors who are no longer under contract.

That uncertainty matters more than it used to. NIST’s current guide to operational technology security explicitly includes building automation systems and physical access control systems within the scope of OT, alongside industrial control systems [1]. In other words, HVAC, lighting, metering, and access control are now treated as part of the same security conversation as power plants and water systems. Federal auditors reached a similar conclusion more than a decade ago, warning that building and access control systems were increasingly being connected to other information systems and the internet, which raised their exposure to cyberattacks [2].

The starting point for addressing that exposure is an accurate inventory. Guidance released in 2025 by CISA and partner agencies describes an OT asset inventory as a living record that should be kept current throughout each asset’s life, from commissioning to decommissioning, and notes that it supports maintenance and reliability as well as security [3]. That is a useful framing for buildings: an inventory is not just a security artifact. It is how you plan replacements, scope service contracts, and answer the question “what do we actually own?”

The problem is that the tools available to build that inventory tend to fall into two camps, and most buildings don’t fit neatly into either one.

Option one: free BACnet explorer tools

Almost every controls technician has a BACnet explorer on their laptop. These tools are usually free or inexpensive Windows applications. They broadcast a BACnet Who-Is request, collect the I-Am responses, and let the technician browse each device’s objects and properties. Many can reach MS/TP devices behind BACnet/IP routers, and some can trend points or write values.

For commissioning and troubleshooting, they are excellent. They are quick to install, require no network changes, and give a technician immediate answers. Any honest discussion of building discovery should start by giving them credit.

Where they fall short is as an inventory system:

  • One protocol. They see BACnet devices. They do not see the Modbus meters, Niagara/Fox supervisors, SNMP-managed switches, MQTT sensors, or IP cameras sharing the same network.
  • One moment in time. A scan reflects the devices that answered while the laptop was connected. Devices that are offline, on another subnet, or quiet at that moment are missed, and nothing is recorded once the technician unplugs.
  • No context. They can tell you a device exists and what it reports about itself. They generally do not tell you which devices talk to each other, whether traffic is encrypted, or whether the firmware is end-of-life.
  • Manual effort. Turning a scan into a usable inventory means exporting, cleaning, and maintaining a spreadsheet by hand, which starts going stale the day it is finished.

The software is free. The labor to turn its output into a reliable inventory, repeatedly, across many buildings, is not.

Option two: enterprise OT security platforms

At the other end of the spectrum are comprehensive OT and IoT security platforms. These products are genuinely powerful. They identify devices across dozens of industrial protocols, build communication maps, match assets against vulnerability databases, detect anomalies, and feed alerts into a security operations center.

They were also designed primarily for large industrial operators: refineries, utilities, pipelines, and manufacturing plants with dedicated OT security teams. That design center shows up in three ways that matter to building owners and integrators.

Infrastructure. Most enterprise platforms rely heavily on passive monitoring, which means a sensor needs a copy of the network traffic. That usually requires a SPAN (mirror) port on a managed switch, a network TAP, or a packet broker feeding one or more sensors. Many building networks are built on unmanaged switches spread across mechanical rooms and floor closets, with no single aggregation point. Getting full visibility can mean buying new switches, adding sensors per segment, or redesigning parts of the network before discovery even begins.

Cost structure. Licensing is often based on the number of assets, sites, or sensors, and is usually sold alongside deployment services and annual support. For a multinational manufacturer, that cost is spread across very high-value assets. For a single office tower, a school district, or an integrator serving dozens of mid-sized buildings, the same model can be out of proportion to the budget and to the risk.

Staffing. The value of an enterprise platform comes from people actively using it: tuning alerts, investigating anomalies, and managing the console. Most facility teams do not have an OT security analyst on staff, and most integrators are not set up to run a monitoring center for every customer.

Why buildings fall into the gap

The result is a “missing middle.” A free explorer is too thin to serve as an ongoing inventory, and an enterprise platform is too heavy to justify for most buildings. Several characteristics of building environments make this gap wider than it is in industry:

  • Mixed protocols on flat networks. A single building network may carry BACnet/IP, Modbus TCP, Niagara/Fox, SNMP, and MQTT traffic side by side, often without segmentation between systems.
  • Distributed, unmanaged hardware. Switches and controllers sit in ceilings, mechanical rooms, and closets, not in a central control room with a managed core switch.
  • Budgets that live in facilities, not security. Building OT is usually funded through operations and maintenance budgets, which are sized for equipment and service, not for enterprise security software.
  • Many small sites. Portfolio owners and integrators manage many buildings of modest size. A tool that takes weeks of planning per site does not scale across a portfolio.
  • Fragile legacy devices. Older controllers can be sensitive to unexpected traffic, which is one reason OT guidance stresses the unique performance, reliability, and safety requirements of these systems [1].

The consequence is predictable. Many buildings default to the free tool, run it once during a project, and file the export. The inventory is accurate for about a month. Meanwhile, the federal experience shows how long these gaps can persist: in 2014, GAO found that GSA had completed security assessments of building control systems in only about 500 of its roughly 1,500 facilities protected by the Federal Protective Service [2]. If well-resourced federal portfolios struggled to get coverage, commercial portfolios with smaller teams face an even steeper climb.

What the missing middle should look like

Filling the gap does not require shrinking an enterprise platform or adding features to a laptop utility. It requires designing for how buildings are actually built, funded, and serviced. A right-sized approach to building OT discovery should offer:

  • Multi-protocol coverage. It should recognize BACnet, Modbus, Niagara/Fox, SNMP, and other common building protocols, not just one.
  • Passive first, with safe queries. Listening to existing traffic avoids disrupting controllers. Adding lightweight, standard protocol requests, such as a BACnet Who-Is, fills in the quiet devices that passive listening alone would miss, without aggressive scanning.
  • No network redesign. It should work on the network as it exists today, without requiring SPAN ports, TAPs, or packet brokers.
  • Continuous, not one-time. The inventory should update itself as devices are added, replaced, or reflashed, which is what CISA’s guidance means by a dynamic, lifecycle-based inventory [3].
  • Maintenance-ready data. Make, model, firmware version, and end-of-life status should be captured alongside security details, so the inventory drives capital planning as well as risk reduction.
  • Deployable by the people already on site. A controls technician or integrator should be able to install it in a normal service visit, not a multi-week project.
  • Priced per building. Cost should reflect the size and value of a building portfolio, not that of a refinery.

What this means for owners and integrators

For facility and building managers, the takeaway is that “free” and “enterprise” are not the only options worth considering. The right question is not “which tool sees the most?” but “which tool will give us an inventory we can keep accurate, at a cost and effort we can sustain?”

For systems integrators and MSPs, the missing middle is also a business opportunity. A discovery approach that is fast to deploy and affordable per site can be included in every assessment, turned into an ongoing monitoring service, and used to identify upgrade and remediation work. That is difficult to do with either a laptop utility or a platform built for enterprise security teams.

In upcoming posts, we will look more closely at each side of the gap, including what free explorers can and cannot tell you, the hidden infrastructure costs of enterprise visibility, and how to evaluate discovery tools for building environments.

Key Takeaways

  • Building automation and access control systems are now formally treated as operational technology, and an accurate inventory is the foundation for securing and maintaining them.
  • Free BACnet explorers are excellent commissioning and troubleshooting tools, but they see one protocol at one point in time and leave inventory upkeep to manual effort.
  • Enterprise OT security platforms are powerful but were designed for large industrial operators, and their infrastructure, licensing, and staffing demands rarely fit individual buildings.
  • Building networks, with mixed protocols, unmanaged switches, facilities-funded budgets, and many small sites, fall into a “missing middle” between these two options.
  • A right-sized approach combines passive listening with safe protocol queries, needs no SPAN or TAP infrastructure, updates continuously, captures firmware and lifecycle data, and is priced per building.
  • For integrators, closing this gap can turn one-time discovery into recurring service revenue.

References

  1. 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
  2. U.S. Government Accountability Office. Federal Facility Cybersecurity: DHS and GSA Should Address Cyber Risk to Building and Access Control Systems, GAO-15-6. December 2014. https://www.gao.gov/products/gao-15-6
  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