runZero discovery still needs a named asset steward

Treat discovery as an observation, not an ownership decision

runZero's public platform record supports the use of active, passive, integration, and correlation methods to build cyber-asset intelligence. In an OT environment, that is an important input to inventory work. A device response, MAC address, IP address, passive communication, imported record, or inferred asset identity does not automatically establish what physical equipment the object supports, whether it is active, or who may authorize a change.

Each candidate record should preserve discovery method, sensor or integration, first and last observation, network location, protocol evidence, identifiers, correlation history, and confidence. Human disposition should then link the cyber object to physical asset, process area, equipment hierarchy, lifecycle state, site, vendor, system owner, operations owner, engineering authority, maintenance owner, and cyber owner where those roles differ. Unresolved identity should remain unresolved rather than being filled with a convenient default.

Reconcile duplicate, shared, and transient identities

OT networks produce difficult identity cases: redundant controllers, shared HMIs, engineering workstations, virtual hosts, remote vendor systems, spare devices, temporary commissioning equipment, network-address changes, serial gateways, and multiple interfaces on one physical asset. An asset intelligence platform can correlate observations, but the organization needs explicit merge and split rules plus a review trail when records conflict.

Test the inventory against engineering drawings, control-system configuration, maintenance hierarchy, network management, procurement records, backups, safety documentation, and site walkdowns. Differences are not merely data-cleaning defects; they can reveal undocumented change, abandoned equipment, monitoring gaps, or competing definitions of the asset boundary. The resolved record should identify the authoritative owner for each attribute instead of declaring one system universally authoritative.

Attach operational consequence before prioritizing action

Exposure information becomes decision-useful only when it is joined to operating context. Asset type and vulnerability correlation do not alone establish process consequence, safety impact, environmental impact, recovery dependency, redundancy, outage window, or whether an apparent version applies to the deployed component. Those judgments require engineering and operations evidence alongside cybersecurity analysis.

A remediation or monitoring case should name the affected function, credible consequence, current safeguards, detection coverage, vendor constraints, test environment, outage requirements, rollback plan, approvers, and retained evidence. The asset record can route the case and support prioritization. It should not silently grant a scanner, analyst, or security workflow authority to query, isolate, patch, reboot, or otherwise alter production equipment.

Measure inventory control over the full lifecycle

A buyer test should include known production devices, passive-only assets, unmanaged IT near OT, duplicate identities, powered-off spares, a newly commissioned asset, a retired asset, a remote connection, and a device whose identification is intentionally ambiguous. Measure observation coverage, identification confidence, false merges, stale records, owner assignment, change-review latency, protocol safety, and the time needed to reconcile differences with site evidence.

The registered runZero page establishes provider positioning; it does not establish a reader's deployment safety, discovery completeness, asset identity, ownership map, criticality conclusion, remediation authority, or control effectiveness. Evaluation should be conducted with site operations, control engineering, safety, maintenance, architecture, and cybersecurity owners. A better inventory is valuable precisely because it makes unresolved ownership and context visible rather than pretending the discovery system has already decided them.

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.