NIST’s National Cybersecurity Center of Excellence has announced a new initiative: a project specifically focused on helping critical infrastructure organizations gain meaningful visibility into their operational technology environments. The OT visibility project will develop practical guidance, reference architectures, and tooling recommendations for organizations trying to understand what is actually running on their OT networks.
The project addresses something that security practitioners in industrial and building environments have known for years: the majority of organizations operating OT and smart building infrastructure do not have an accurate, current inventory of the devices on those networks. They do not know what firmware versions are running. They do not know which devices are communicating with each other or with external systems. They do not know when devices change their behavior.
You cannot defend what you cannot see. The NIST project is a recognition that for OT environments, the visibility problem is widespread, persistent, and foundational to everything else in the security stack.
Why OT Visibility Is a Harder Problem Than IT Visibility
In enterprise IT environments, asset visibility is a solved problem in most organizations. Endpoint management platforms enumerate connected workstations and servers. Directory services maintain authoritative lists of managed devices. Network scanners identify connected hosts. MDM systems track mobile endpoints. The tools exist, the integrations work, and maintaining an accurate inventory of IT assets, while never trivial, is a tractable operational task.
OT environments are fundamentally different. The devices are different. The protocols are different. The operational constraints are different. And the organizational history of how these environments were built has produced a specific set of visibility challenges that IT-focused tools do not address.
Device heterogeneity. A typical smart building OT environment contains devices from dozens of manufacturers across multiple generations of technology. HVAC controllers from 2008. Access control panels from 2014. Smart lighting systems from 2019. Environmental sensors from multiple vendors. Building management gateways running proprietary firmware. Elevator control systems with vendor-specific communication interfaces. These devices speak different protocols — BACnet, Modbus, LonWorks, KNX, Zigbee, Z-Wave, proprietary serial protocols — and most do not respond to standard IT network scanning tools in ways that produce useful discovery data.
Scan sensitivity. Many OT devices are sensitive to network scanning traffic in ways that enterprise IT systems are not. A device that receives a port scan may crash, lock up, or change its operational state. This means that the standard IT discovery approach — run an Nmap scan across the network range — is not applicable to OT environments without detailed knowledge of which devices are present and what they tolerate. Organizations that have applied IT discovery tools to OT networks without that knowledge have in some cases disrupted operational systems.
Documentation gaps. The institutional memory of what was installed, when, and with what configuration often lives in the heads of facilities managers, system integrators, or contractors who may no longer be available. Upgrade and expansion projects add devices without comprehensive documentation. Devices are replaced without removing old entries from system documentation. The result is that existing documentation, where it exists, is frequently inaccurate.
IT/OT organizational separation. IT security teams and OT/facilities teams often operate with limited coordination. The IT team responsible for network security may have no visibility into the building automation network managed by facilities. The facilities team managing HVAC and access control may not report security incidents to the IT security organization. Neither team has a complete picture of the combined attack surface.
What the NIST NCCoE Project Will Produce
The NIST National Cybersecurity Center of Excellence has a specific methodology for its projects: it brings together technology vendors, end-user organizations, and government stakeholders to develop practical, implementable guidance rather than abstract frameworks. The output is typically a NIST Special Publication or NIST Internal Report that includes reference architectures, tool inventories, and implementation guidance that practitioners can use directly.
For the OT visibility project, the expected outputs include:
Reference architectures for OT asset discovery. These will describe how to deploy passive monitoring, active polling where appropriate, and integration with existing asset management systems to build and maintain an accurate OT device inventory. The architectures will be designed for the heterogeneous, protocol-diverse environment that actual OT deployments represent.
Tool guidance. The project will evaluate and document specific commercial and open-source tools for OT network discovery and monitoring. This is practically useful because the OT visibility tooling landscape is fragmented, with significant differences in protocol support, deployment complexity, and integration capabilities between products.
Implementation guidance for smaller organizations. Previous NIST NCCoE projects have sometimes produced guidance oriented toward large organizations with substantial security teams. The OT visibility project has specifically indicated attention to smaller critical infrastructure operators — water utilities, smaller manufacturers, commercial building operators — who have OT visibility problems but limited resources for complex solutions.
Integration patterns with IT security tools. Many organizations want to feed OT device data into existing SIEM and asset management systems that their IT security teams already use. The project will address how OT discovery data can be integrated with IT-layer tooling in ways that produce useful, actionable information rather than noise.
The Smart Office Visibility Problem
For organizations running smart office environments, the OT visibility problem manifests in a specific way that is worth examining in detail.
A modern smart office building contains, depending on size and configuration, somewhere between dozens and hundreds of connected devices that most IT security teams would classify as OT: HVAC controllers, smart lighting systems, occupancy sensors, energy management systems, access control panels, elevator systems, fire safety systems, parking management, and building automation gateways that integrate all of these.
Ask the IT security team responsible for that building how many OT devices are on the network. In most cases, the answer will be a rough estimate, not an accurate count. Ask what firmware versions are running on those devices. The answer will typically be unknown for the majority of devices. Ask when those devices last communicated with an unexpected external host. The answer will almost always be that this is not monitored.
This is not primarily a failure of the people responsible for building security. It is a structural consequence of how smart building infrastructure has been deployed. Building automation systems were installed by system integrators whose scope was operational functionality — making the HVAC work, making the access control work — not security monitoring. The network connectivity that was added to enable remote management and cloud analytics was added for operational convenience without a corresponding security architecture. The IT security team was not in the room when these systems were designed.
NIST’s project is an acknowledgment that this is the common condition, not an exception, and that the guidance gap — specific, practical guidance on how to gain visibility into OT environments — has been a genuine barrier to improvement.
Existing Tools and Their Limitations
Several commercial tools specifically address OT network visibility, and they are worth understanding in context of what the NIST project will add.
Claroty and Dragos are established OT security platforms that include asset discovery functionality. Both use passive network monitoring — listening to OT network traffic rather than actively scanning — to identify devices and build inventories. Both support a range of OT protocols and can integrate with IT security tooling. Both are primarily positioned at larger enterprise and critical infrastructure customers, with pricing and deployment complexity that is challenging for smaller organizations.
Nozomi Networks and Forescout offer comparable capabilities, with Forescout extending more explicitly into the IT/OT convergence space. Microsoft Defender for IoT, formerly CyberX, provides OT visibility capabilities integrated with the broader Microsoft security platform, which makes it appealing for organizations already using Microsoft security tooling.
For organizations that cannot deploy commercial OT security platforms, open-source options exist. Zeek (formerly Bro) can analyze OT protocol traffic in passive monitoring mode if configured for the relevant protocols. GRASSMARLIN, a CISA-released tool, was designed specifically for passive industrial network analysis — though its development has been less active in recent years.
The common limitation across these tools is that they require deployment decisions: where to place passive monitoring taps or span ports on the OT network, how to handle encrypted OT traffic, how to integrate discovery data with existing IT asset management systems. These are not insurmountable challenges, but they require knowledge of OT network architecture and security monitoring that many organizations lack. The NIST guidance is specifically intended to address this knowledge gap.
Practical Steps for Smart Office OT Visibility
While the NIST project develops its full guidance, organizations can begin addressing the OT visibility gap with steps that do not require specialist tooling.
Document what you know exists. Start with the system integrator documentation, vendor records, and facilities team knowledge to build the most complete inventory possible of installed OT and smart building devices. This is the baseline against which discovery findings are compared. The gaps between documented devices and discovered devices are themselves informative.
Identify network segments where OT devices reside. Map which VLANs or network segments carry building automation, access control, HVAC, and other OT traffic. This is a prerequisite for deploying monitoring and also provides the network topology needed to assess segmentation adequacy.
Deploy passive monitoring on OT segments. Even without purpose-built OT security tools, configuring network flow logging on the switches serving OT segments provides baseline visibility into what devices are communicating with what. Anomalies — devices communicating with unexpected destinations, unexpected volumes of traffic, devices that appear for the first time — are visible in flow data without active scanning.
Assign ownership. For each OT system category — HVAC, access control, smart lighting, building management — define who is responsible for security monitoring and what their escalation path is to the IT security team. In the absence of defined ownership, visibility gaps persist because no one is accountable for closing them.
Engage vendors for inventory. Many building automation and OT system vendors can provide detailed device inventories from their management platforms. The access control vendor knows what panels are installed. The BMS vendor knows what controllers are connected to their management system. This vendor-sourced data supplements network discovery and is often more detailed for vendor-specific protocol devices.
The NIST project will produce more sophisticated and scalable guidance. But the organizations that will benefit most from that guidance are the ones that have already started building their OT visibility capability and understand where their specific gaps are. Starting now, with available means, is better than waiting for comprehensive guidance to materialize.
This article is provided for informational purposes only and does not constitute legal advice.
