OT Asset Inventory: Why AI Cannot Defend What You Cannot See

An OT asset inventory is the foundation beneath every industrial security control, including the AI tools now entering control rooms. On September 23, 2026, new coverage of Honeywell's benchmark report exposed a dangerous mismatch: 88% of surveyed leaders called their OT programs mature or design-led, but only 21% reported a complete asset inventory.

That gap matters now because an incomplete map produces incomplete detection, risky automation, and slower recovery. If your security platform cannot see a chiller controller, safety system, remote-access appliance, or aging engineering workstation, its AI cannot reliably distinguish a harmless anomaly from the first sign of operational disruption.

Key Takeaway: Do not measure OT security maturity by the number of tools deployed. Measure whether you can identify each critical asset, explain what it does, see who can reach it, and restore the process it supports.

Why the OT asset inventory gap matters today

The main freshness hook is SecurityWeek's report on Honeywell's findings, published September 23, 2026. Honeywell surveyed 603 security, operations, risk, and plant leaders across energy, oil and gas, healthcare, maritime, and manufacturing organizations in multiple regions.

The full Honeywell benchmark report shows that visibility gaps extend beyond production equipment. Only 33% of respondents said OT was fully integrated into a centralized security operations center, while just 20% continuously monitored more than three-quarters of connected IoT devices.

The consequences are operational, not theoretical. Organizations affected by significant OT security incidents reported an average of 16.2 hours of downtime. Among incident-affected respondents, 21% estimated downtime costs above $100,000 per hour, and 4% put the cost above $500,000 per hour.

Those numbers change the business case for inventory. A current record of assets, dependencies, owners, and recovery requirements is not administrative housekeeping. It is the evidence base for containing an incident without creating a second outage.

Key Stat: Among incident-affected organizations, the share reporting recovery within six hours was 17 percentage points higher when asset visibility was stronger, according to Honeywell.

Why incomplete inventory weakens AI security

AI can correlate large volumes of telemetry, prioritize alerts, and flag behavior that differs from a learned baseline. It cannot compensate for assets that never send telemetry, incorrect labels, missing network paths, or undocumented maintenance access.

Honeywell found that 72% of respondents already use AI for threat detection, 68% for continuous monitoring, and 59% for asset inventory. Yet only 23% use autonomous or agentic AI for threat detection. That restraint is sensible because action taken from incomplete context can interrupt a physical process.

Imagine an AI system that sees a programmable logic controller suddenly talking to a new engineering workstation. The event could indicate malicious lateral movement, a contractor performing approved maintenance, or a replacement workstation introduced during an outage. Without ownership, change history, process role, and expected communication data, the model has confidence without context.

The risks appear in three places:

• Detection: unknown devices and blind network segments never enter the baseline.
• Prioritization: alerts lack process criticality, safety impact, and dependency context.
• Automated response: blocking a legitimate controller path may stop production or undermine safety.

This is why AI governance in OT starts with data quality and authority boundaries. Our AI evaluation incident controls guide explains how testing, containment, and explicit decision rights reduce the risk of automated actions. In an industrial environment, those controls must also account for uptime and physical consequences.

Common Mistake: Buying an AI-enabled monitoring product before deciding which systems are in scope, who owns them, and which response actions are safe to automate.

Define what belongs in your OT asset inventory

An OT inventory should cover more than PLCs and human-machine interfaces. Modern operations depend on connected systems that regulate facilities, safety, access, communications, and environmental conditions.

Include at least these asset groups:

• controllers, remote terminal units, drives, sensors, and actuators
• engineering workstations, historians, HMIs, and application servers
• safety instrumented systems and emergency-control components
• switches, firewalls, radios, serial gateways, and remote-access appliances
• building automation, HVAC, chillers, elevators, and switchgear
• badge readers, cameras, fire panels, and physical security systems
• vendor laptops, jump hosts, backup systems, and removable-media stations
• cloud services and data brokers that receive or influence operational data

For each asset, record the information that supports a decision: unique identifier, physical location, owner, process function, manufacturer, model, firmware or software version, network addresses, communication protocols, dependencies, access paths, support status, criticality, backup method, and recovery objective.

The joint CISA asset inventory guidance recommends pairing inventory with a taxonomy. That classification layer helps teams group assets by function, criticality, location, connectivity, ownership, and other attributes instead of maintaining a flat list nobody can use during an incident.

Your scope should follow operational dependency, not department boundaries. A cooling controller owned by facilities may determine whether a data center remains online. A badge system may control access to a process area. If failure or compromise can affect safety, production, service delivery, or recovery, it belongs in the security view.

The Rockwell PLC security guide shows why internet exposure and unclear ownership are especially dangerous around controllers. Inventory should connect each device to its real access path rather than simply marking it "internal."

Build the inventory in five practical stages

Do not begin with a goal of perfect discovery across every site. Begin with the processes whose failure would create the greatest safety, operational, environmental, or financial impact, then expand through a repeatable lifecycle.

1. Set scope and decision owners

Choose a facility or critical process, name one accountable owner, and define what the inventory must support. Useful goals include incident scoping, vulnerability response, remote-access review, recovery planning, and AI monitoring coverage.

Bring security, operations, engineering, facilities, safety, and key vendors into the same working group. Each team sees only part of the environment, so reconciliation is a governance task as much as a technical one.

2. Combine passive and documentary discovery

Use passive network monitoring where possible because aggressive scanning can destabilize fragile devices. Supplement it with switch tables, firewall rules, historian data, controller projects, maintenance records, procurement systems, configuration backups, physical walk-throughs, and vendor documentation.

No single source is authoritative. A device can be installed but silent, visible on a network but missing from procurement, or listed in a spreadsheet after it has been retired. Treat conflicting records as investigation work, not as an excuse to pick the cleanest-looking database.

3. Normalize and classify

Create stable identifiers, standard names, and controlled values for asset type, site, owner, criticality, support status, and lifecycle state. Record which source supplied each field and when it was last verified.

Then connect assets to operational services. Knowing that a server exists is less useful than knowing it feeds the line-control historian, depends on a specific switch, and must be restored within four hours.

4. Validate access and dependencies

Map normal communication paths, remote maintenance routes, vendor access, privileged accounts, and upstream or downstream dependencies. Test assumptions from representative network locations instead of trusting a diagram last updated during installation.

Our office network segmentation guide covers the core principle at a smaller scale: access boundaries only help when teams know what belongs in each segment and verify that traffic follows the intended path.

5. Make change part of operations

Inventory decays when updates depend on a quarterly spreadsheet exercise. Connect equipment commissioning, maintenance, change approval, incident handling, vendor access, and decommissioning to the inventory workflow.

Alert on newly observed assets and material attribute changes, then require an owner to approve, investigate, or retire the record. Keep history so responders can reconstruct what changed before an event.

Pro Tip: Start with a weekly reconciliation for one high-impact process. A smaller inventory with clear owners and verified fields is more useful than a huge list of untrusted records.

Put guardrails around AI-driven OT defense

Once inventory coverage is trustworthy, AI can improve analysis without becoming an uncontrolled operator. The first applications should help people find inconsistencies, correlate observations, and focus review.

Good early uses include:

• suggesting matches between passive observations and existing records
• flagging devices with conflicting models, versions, owners, or locations
• identifying unexpected communication for human investigation
• prioritizing vulnerabilities using process criticality and exposure
• detecting inventory drift after maintenance or network changes
• assembling incident timelines from asset and telemetry history

Keep response authority narrow. An AI system may recommend isolating a workstation, but a trained operator should confirm that isolation will not remove visibility, stop a safety function, or strand a process in an unsafe state.

Define which actions are advisory, which require approval, and which can run automatically under tested conditions. Log the evidence, recommendation, approver, action, and outcome. Test changes against representative equipment or a digital twin before granting broader authority.

This approach also improves recovery. The small-business backup and restore checklist focuses on proving that backups can restore service. For OT, extend that proof to controller logic, HMI projects, server images, device configurations, licenses, certificates, network settings, and the safe sequence for bringing a process back online.

Measure inventory quality, not spreadsheet size

A large row count can hide missing fields, duplicate devices, and stale records. Use metrics that tell you whether the inventory can support security and operational decisions.

Track at least:

• percentage of critical processes with verified asset coverage
• percentage of assets with a named operational owner
• percentage with current version, support, and recovery information
• time from first observation to approved inventory record
• number and age of unknown or conflicting assets
• percentage of remote-access paths tied to an owner and purpose
• percentage of critical assets represented in monitoring and response tests
• time required to scope a simulated vulnerability or incident

Set a verification interval based on risk and change rate. A frequently serviced remote-access gateway may need continuous monitoring, while an isolated controller can follow a different cadence if physical and configuration controls are strong.

NIST's OT asset management project emphasizes automated and manual discovery, inventory, configuration, and change management together. That combination matters because visibility is not a one-time scan. It is a maintained operational capability.

Use incident exercises to test the result. Give the team an unfamiliar IP address, a vulnerable firmware version, or a failed facility controller and measure how quickly it can identify ownership, dependencies, access, evidence sources, containment options, and a safe recovery path.

The action to take this week

Choose one operational process that cannot tolerate a long outage. Identify every controller, workstation, server, network device, facility system, remote-access path, vendor dependency, and recovery artifact required to keep it safe and restore it.

Then compare documentary records with passive observations and a physical walk-through. Resolve unknown assets, assign owners, classify criticality, and link each component to monitoring and recovery procedures. Only after that baseline is trusted should you let AI recommendations influence containment or operational change.

The Honeywell benchmark does not show that industrial organizations lack security tools. It shows that many cannot yet prove they see the full environment those tools are supposed to defend. A dependable OT asset inventory closes that gap and gives people, automation, and AI the context needed to make safer decisions.