A Dragos asset inventory is not a zone-and-conduit design

Separate observed communication from intended architecture

Dragos' official record documents asset visibility and industrial threat-detection positioning. The direct answer is that a current inventory and communication map can help teams understand what appears to exist, but it cannot establish what the system is designed or authorized to do. A connection may be required, temporary, legacy, misconfigured, routed through an unexpected device, created during maintenance, or visible only from one sensor location.

A zone-and-conduit decision needs a controlled engineering record. That record should identify the physical process, safety and reliability functions, assets and controllers, ownership, operating modes, required data flows, protocols, direction, frequency, identities, remote-access path, fail-safe behavior, vendor dependencies, recovery requirements, and approved exceptions. The observed map is one input alongside drawings, configurations, interviews, change history, OEM documentation, and site validation.

Reconcile identity before drawing a boundary

An IP or hardware address does not automatically identify the correct physical asset, firmware, function, owner, location, safety role, or lifecycle state. Duplicate addresses, network address translation, unmanaged switches, engineering workstations, removable devices, dormant equipment, mirrored traffic, and incomplete sensor placement can distort the apparent topology. A confident architecture decision should not depend on a name assigned by one observation alone.

Asset stewards should reconcile network observations with the engineering asset register, cabinet and location records, control narratives, backups, approved configurations, maintenance history, remote-access inventory, and process ownership. Conflicts should create a review queue. The retained decision should show who resolved the identity, which sources were used, which uncertainty remains, and whether the asset is approved, temporary, retired, unsupported, safety-relevant, or awaiting field confirmation.

Keep architecture changes behind site authorization

A proposed boundary change can affect control latency, redundancy, vendor support, safety systems, remote operations, alarm paths, time synchronization, historian feeds, maintenance access, and recovery. OT teams should not translate an inventory finding directly into a firewall rule, block, scan, endpoint action, or isolation step. Engineering, operations, cybersecurity, safety, reliability, vendors, and change authorities need to assess the physical consequence and rollback path.

A buyer demonstration should use an authorized non-production or controlled scenario. Ask Dragos to show how the proposed deployment observes assets, labels confidence, represents communication direction, handles blind spots, retains raw evidence, records changes, and exports findings. Then test how an analyst creates an architecture question without implying approval, how a named owner responds, and how the final engineering decision remains separate from the analytical recommendation.

Keep Dragos claims inside the official record

The registered Dragos page establishes current provider positioning for OT asset visibility, vulnerability management, threat detection, response, intelligence, and supporting services. It does not establish complete discovery, correct asset identity, a safe or compliant architecture, accurate topology, effective detection, or approval to alter a live industrial environment.

OT Defense Review reviewed the official source on August 19, 2026 and did not operate the product. Buyers should verify the current platform, sensor and data model, passive and active methods, supported protocols, identity confidence, topology and dependency representation, change history, evidence export, site constraints, integrations, services, and package boundaries under authorized engineering and safety governance.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

OT Defense Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.