OT Asset Management Implementation: Inventory, RFP and 90-Day Acceptance for Thai Factories

OT asset management in a Thai factory is not a project to count networked devices. It should connect PLCs, HMIs, SCADA, VFDs, industrial switches, engineering workstations, maintenance PCs and remote-access paths to their operational purpose, approved configuration, communications, change history and recovery evidence. This guide turns passive and manual discovery, an OT asset inventory, an RFP and a 90-day proof of concept into measurable acceptance work.

Do not reduce OT asset management to installing a discovery tool

Factories contain assets that are silent, disconnected, used only during maintenance, located behind gateways or connected through serial links. A spare PLC on a shelf, a vendor laptop brought in for two hours, remote I/O behind a controller and an unmanaged switch inside a panel may not appear at a central observation point. Conversely, one IP address does not always equal one asset: redundant interfaces, NAT, reused addresses and replacement hardware can distort the count.

In June 2026, NIST NCCoE announced a project intended to demonstrate practical OT asset-management approaches, including automated and manual discovery, inventory, configuration and change-management processes. Its draft project description includes a high-level reference architecture and desired demonstration capabilities. It is a project description, not a finished NIST standard, certification or completed reference implementation. The useful procurement lesson is that discovery, verification and change governance belong in the same scope.

NIST SP 800-82 Rev.3 also emphasizes OT’s unique performance, reliability and safety requirements. Therefore, an IT discovery routine should not be copied into a production network without engineering review. This article assumes that unassessed active scanning is prohibited. The baseline is passive observation of existing traffic plus controlled manual discovery. Passive does not mean risk-free: mirror configuration, collection capacity, sensor access, time synchronization and data handling still require change approval.

This article deliberately does not repeat a broad OT-security program or incident-drill design. For those topics, see OT security for factories in Thailand, industrial networks and factory wireless LAN and OT cyber incident response drills. Here the boundary is practical: what exists, how it is configured, what it communicates with, what changed, and how a factory accepts and operates the capability.

Define the purpose and boundary before comparing products

The first deliverable should be a one-page scope sheet, not a feature comparison. Identify sites, lines, cells, networks, operating hours, permitted maintenance windows, excluded areas, users of the inventory and decisions that the data must support.

“Know how many devices we have” is not an actionable objective. Better objectives include:

• prioritize lifecycle replacement by combining support status with process criticality and safety impact;
• route unapproved connections and configuration differences into a queue that plant personnel can investigate;
• find the logic, configuration, license, engineering tool and procedure needed to replace a PLC or HMI;
• identify the owner, approval period, destination and use record for each remote-maintenance path;
• explain which expected assets were observed and which changes remain unresolved after maintenance or an exercise.

Production, maintenance, controls engineering, IT, cybersecurity, quality, safety, procurement and external service providers hold different pieces of the truth. Maintenance may know model and location, controls engineers know communication and project files, IT knows identity and connectivity, while production knows operational impact. An inventory built by one department may be detailed but still misleading.

Define what counts as one asset

A PLC chassis, communication module, remote I/O and power supply may be separate maintainable items or components of one controlled system. An HMI runtime, operating system and project file may be configuration items linked to one physical panel. Fix the identity rules before vendors demonstrate “discovered asset count.”

The correct question is not “What is the single total?” but “Which identity supports each decision?” PoC coverage must be measured against a stated population and identity rule, not a raw IP count.

Combine passive discovery with controlled manual discovery

Passive discovery observes existing traffic from an approved SPAN port, network TAP or other collection point. It can infer asset candidates and communication relationships without initiating interrogation of controllers. It is often the preferred starting point, but it cannot see silent assets or traffic outside the observation path.

Manual discovery is more than walking the floor with a spreadsheet. It reconciles drawings, cabinet and nameplate checks, maintenance registers, spare stores, engineering-project lists, switch configurations, backup repositories, VPN settings, service contracts and interviews to governed asset IDs. Rules for photography, opening panels, access qualifications, PPE and production impact must be approved in advance.

Observation-point design determines factory network visibility

A sensor at the core switch may not see local traffic within a cell VLAN, ring or unmanaged switch. PLC-to-local-HMI traffic, serial networks behind a gateway and temporary wireless or cellular access may bypass it. Before the RFP, overlay these items on the logical and physical network drawings:

1. in-scope processes and safety-significant equipment;
2. VLANs, subnets, routing and redundant paths;
3. managed switches and possible mirror ports;
4. TAP candidates, power, rack space and cabling;
5. remote access, maintenance wireless and cellular connections;
6. blind areas and the owner of manual verification.

Keep this drawing under change control. An increasing discovered count is not coverage if the observation boundary cannot be explained.

Conditions for considering active scanning

Active scanning is not necessarily prohibited forever; it is prohibited until a safety assessment is complete. Review the device, firmware and protocol with the equipment vendor, controls engineer and safety owner. Validate in a test environment or tightly limited segment. Record permitted packets, rates, time windows, observers, stop criteria, rollback and incident contacts in the change record.

A “read-only” or “safe scan” product label is not acceptance evidence. The factory must understand what is transmitted, how retries behave and whether unsupported devices could be affected. Where active functions are not approved, prove they remain disabled with both configuration evidence and packet traces.

OT asset inventory fields that support decisions

A useful OT asset register is not the one with the greatest number of columns. It holds decision-relevant values with ownership, source, timestamp and approval. Separate automatically observed values, manually verified facts and approved baseline values.

Identity and responsibility

Configuration, communication and access

Criticality, safety, lifecycle and recovery

NIST SP 1339 states that OT backup management should be integrated into change management, performed regularly, tested and reviewed in recovery exercises. Its examples span PLCs, switches, firewalls, transmitters, actuators, DCS, SCADA, VFDs and HMIs. Recovery may require logic, configuration, I/O, firmware, HMI assets, licenses, tools and documentation. The inventory should therefore link to recoverability evidence rather than display only “backup available.”

Make source, checked date and confidence mandatory

A passive fingerprint, a verified nameplate, a vendor document and an operator statement carry different levels of confidence. Retain source, last verification time, verifier, confidence and approval state for important values. When an observed value differs from an approved value, create a reconciliation item instead of silently overwriting the baseline.

Allowing unknown is better than filling blanks with guesses. However, an unknown without an owner and due date becomes permanent debt. Data quality must be connected to workflow.

Govern four systems of record: asset, configuration, communication and change

The demand for “one source of truth” becomes counterproductive if every data type is forced into one database. Define a governed system of record by information domain.

One platform may hold all four, or a CMMS/CMDB, visibility platform and change system may be integrated. What matters is a controlled key mapping, precedence and update rule.

If passive discovery appears to show a firmware change, do not update the approved baseline automatically. Preserve the observation, reconcile it with a planned change, maintenance record and physical evidence, then approve the baseline. If a planned change was closed but the observation did not change, investigate incomplete work, insufficient visibility or a parsing issue.

The official IEC 62443-2-1:2024 overview says the standard addresses security-program policies and procedures for IACS asset owners/operators. It recognizes lifecycles that can exceed twenty years and unsupported legacy systems. The publicly available preview lists CM1 inventory management and topics for baselines, infrastructure documentation, configuration and change control. This article is not a conformity assessment, and an inventory product alone does not establish IEC 62443-2-1 compliance.

Reconcile unknown, new and missing continuously

The plant changes as soon as the initial inventory is completed. Replacement hardware appears, a maintenance PC connects, equipment stops and addresses change. Daily operations should reconcile current observation with the approved state through three controlled queue states:

• unknown: observed but not linked to an approved asset or baseline;
• new: intentionally introduced and in approval or registration;
• missing: expected to exist or operate but not observed within the agreed window.

Unknown does not automatically mean intrusion, and missing does not automatically mean failure. An unknown may be an approved contractor laptop; a missing asset may be a planned-offline spare. Keep detection state separate from incident classification.

Standard difference-handling flow

1. Generate candidates from sensors, walkdowns, change and maintenance systems.
2. Correlate MAC, serial, switch port, location and fingerprint without deleting original evidence.
3. Prioritize by safety impact, process criticality, remote access, change time and confidence.
4. Assign to the line, asset or technical owner.
5. Verify against change records, work orders, drawings, physical inspection and personnel.
6. Resolve by approving, rejecting, adding an expiring exception or escalating investigation.
7. Learn by tuning identification rules and retaining an auditable reason for closure.

Prioritization should not be first-in-first-out. An unknown remote path on a safety-significant line or an unapproved PLC baseline difference deserves attention before an expected dormant spare.

Useful measures include verified coverage against the defined population, evidence-backed completion of required fields, age of unresolved differences, confirmation time for critical items, agreement between planned and observed change, and validity of restore evidence. “More detected assets” may mean more duplicates; “zero unknowns” may mean insufficient visibility. Every KPI needs a denominator, time window and exclusion rule.

What an OT asset-management RFP should require

An RFP should communicate the operational boundary, prohibitions, data ownership, integration, service model and acceptance evidence. It should enable vendors to respond to the same scenarios.

Scope and constraints

• sites, lines, cells, VLANs, protocols and asset classes;
• operating hours, allowable outages, redundancy and safety-significant zones;
• prohibition on active scanning unless separately assessed and approved;
• internal conditions for cloud use, data transfer, retention and export;
• Thai, English and Japanese operating/support needs.

Discovery and identity

• attributes and protocols supported through passive observation, inference method and confidence;
• manual registration and bulk import for silent assets;
• identity treatment for multiple NICs, redundancy, NAT, replacement, address reuse and virtualization;
• explicit handling of PLCs, HMIs, SCADA, VFDs, switches, engineering stations, maintenance PCs and remote paths;
• preservation of unsupported or unidentified equipment as unknown rather than a blank.

Records, change and evidence

• data model for asset, baseline, communication and change history;
• approval workflow that prevents observation from overwriting the baseline;
• APIs, open exports, time handling, audit logs and history retention;
• integrations to CMMS/CMDB, identity, change and backup records;
• full exit/export provisions if the service is replaced.

Operations and lifecycle

• monitoring for sensor outage, packet loss, clock drift and storage exhaustion;
• controlled updates and rollback for parsers and fingerprints;
• separation of duties, MFA, administrative logs and vendor support access;
• source and refresh method for EOL/EOS information;
• escalation and support for unidentified devices and local Thai operations.

Acceptance evidence

Do not accept “visibility is available.” Require a coverage matrix, packet evidence, difference events, audit logs, API exports, links to recovery evidence, failure/recovery records and operator procedures.

Design a 90-day PoC around four acceptance gates

The following schedule and numbers are hypothetical examples, not market benchmarks. Replace every percentage, count and time limit with the factory’s approved criteria.

Gate 1: Coverage

Build a comparison population from maintenance records, drawings, controls projects, switch data and a physical walkdown. It need not be perfect, but the denominator must be fixed. A hypothetical cell could contain 100 candidates: 70 constantly communicating, 15 intermittent and 15 silent or spare.

Do not accept one “95% discovered” figure. Break results down by asset class into automatically discovered, manually verified, unresolved and duplicate. Verify that a silent asset can be registered and linked to the same persistent identity model.

Gate 2: Safe discovery

Use configuration, logs and packet capture to prove that the sensor did not originate unapproved discovery, write or configuration traffic. Check that SPAN/TAP installation creates no loop or bandwidth effect and that sensor failure does not affect control communications.

A hypothetical test can interrupt sensor power, management connectivity and time synchronization. The control process should remain unaffected, monitoring should show the sensor state, and the missing collection interval should be explainable after recovery.

Gate 3: Change detection and reconciliation

Create approved test changes: modify a test HMI address, connect an approved maintenance PC, update controlled configuration information, move a switch port and create a planned missing state. Verify that each item is observed, linked to its change ID, assigned and resolved without silently changing the baseline.

Then simulate an observation without a matching change. It should enter unknown, follow a different review path and retain evidence even after closure. Test whether business criticality and safety impact affect priority.

Gate 4: Recovery evidence and operational handover

For selected PLC, HMI, switch and VFD records, navigate from the inventory to approved backup, configuration, logic, firmware information, engineering tool, license, I/O documentation and procedure. Link to restore/read-back evidence produced in an approved test environment; do not perform an unplanned restore on production equipment.

Finally, plant operators—not the vendor demonstrator—must receive an unknown, investigate it, update the record and conduct the weekly review. If the factory team cannot operate the workflow, a successful demonstration is not acceptance.

Hypothetical 90-day acceptance test matrix

The 15-minute example and sample of 20 are assumptions, not promises. Faster detection may also collect transient peers and create excess review work. Balance detection time with classification accuracy and operating capacity.

Operating the capability after acceptance

Daily work should review critical unknown/new/missing items, sensor health, new remote paths and expiring exceptions. Weekly, production, maintenance, controls and IT/security should review the queue, reconcile approved versus observed changes and return false positives or blind spots to improvement. Monthly or quarterly, review support lifecycle, spare strategy, backup validation, engineering tools/licenses, access rights, external vendor paths, retention and scope changes.

Separate tool administration from asset approval. A parser update by a supplier must not automatically alter the plant’s approved baseline. Use a RACI in which operations confirms purpose, controls engineering confirms configuration and communications, IT owns platform and identity, procurement maintains contract/lifecycle evidence, and governance owners manage workflow and audit.

For multilingual Thai factories, separate a persistent ID from display names. Retain standardized English classes plus Thai and Japanese aliases for search. Assign ownership to roles or teams rather than individuals. At contract exit, make drawings, project files, credentials, licenses and connected devices part of the handover. For remote access, record the entry point, jump host, destination, identity, approval period, support route and location of use logs.

Yokogawa announced an Industrial Cyber Resilience Center in Singapore on 15 September 2026 and described support for OT cyber readiness in Southeast Asia. This is useful current regional context, but it is a vendor release—not independent market statistics. An investment decision should rest on the factory’s asset, safety, downtime and maintainability needs and on demonstrated acceptance results.

Common implementation failures and how to avoid them

Comparing vendors by discovered count

A higher count may contain duplicates, short-lived peers, IT assets or equipment outside the agreed boundary. Compare coverage against the same population, asset-unit rules, duplicate logic and manual-discovery scope.

Treating the initial inventory as project completion

The environment changes immediately. Acceptance must include the difference queue, assignment, due dates, approval and weekly review. During the 90-day PoC, factory personnel should complete at least one full operating cycle.

Letting observations overwrite the approved baseline

An observation is a candidate fact, not an approval. Preserve source, timestamp and confidence, reconcile it with the change record, and update the baseline only after authorization.

Producing an EOL list without replacement context

Support status alone does not determine replacement priority. Combine it with business criticality, safety impact, available spares, substitution options, backup fitness and recovery dependencies.

Assuming that a backup file proves recoverability

A file may be unusable without a compatible engineering tool, license, firmware, credential or I/O document. Create restore or read-back evidence in a controlled environment and make it reachable from the asset record.

FAQ: OT asset inventory, network visibility and IEC 62443-2-1

How is OT asset management different from IT asset management?

OT assets interact with physical processes, so safety, availability and reliability matter directly. Lifecycles can be long, outages difficult and recovery dependent on logic, I/O, firmware, engineering tools and licenses. Use passive observation, manual verification, engineering safety review and change approval rather than assuming agents or active IT scans are appropriate.

What are the minimum fields in an OT asset inventory?

Start with persistent ID, type, model/serial, location, business and technical owner, operating state, configuration version, interfaces, approved peers, remote path, business criticality, safety impact, EOL/EOS, backup/recovery dependency, source, verified date and approval state. Evidence and reconciliation matter more than filling every field at once.

Is passive monitoring sufficient for factory network visibility?

Not by itself. It is strong for communications crossing an observation point but can miss silent spares, serial segments, local cell traffic and temporary maintenance devices. Combine it with drawings, walkdowns, maintenance records, controls projects, switch data and contract information, and document blind areas.

Should active scanning be completely banned?

Do not use it without a device- and protocol-specific safety assessment. Only consider it after vendor/engineering/safety review, approved traffic and rate, limited testing, monitoring, stop criteria and rollback. A “safe” label is not evidence.

Does an inventory product provide IEC 62443-2-1 compliance?

No. IEC 62443-2-1:2024 concerns an IACS asset owner’s/operator’s security-program policies and procedures. Its preview identifies inventory, baseline, infrastructure documentation, configuration and change-control topics, but conformity requires an assessment against the purchased standard and the organization’s defined scope. A product purchase alone is insufficient.

Can a 90-day PoC prove ROI?

It can measure coverage, reconciliation time, change agreement, usefulness of lifecycle and backup evidence, and operating effort. It should not claim long-term avoided incidents or downtime value without evidence. Compare measurable internal baselines such as survey labor, investigation time, audit preparation and replacement planning.

Conclusion: accept continuous reconciliation, not a polished dashboard

An OT asset-management outcome is the ability to explain the scope through passive and manual discovery; link PLCs, HMIs, SCADA, VFDs, switches, engineering workstations, maintenance PCs and remote paths to evidence; govern asset, configuration, communication and change records; and continuously resolve unknown/new/missing items. Put safety constraints, data ownership, integration, operations and evidence in the RFP. In the 90-day PoC, use plant-approved criteria to gate coverage, safe discovery, change detection and recovery evidence.

If your Thai factory is still defining the OT asset-inventory boundary, observation points, RFP or 90-day acceptance tests, you can contact TOMAS TECH at the planning stage. We can turn existing drawings, maintenance records and change procedures into product-neutral evaluation and acceptance evidence.

References

• NIST NCCoE, “Asset Management as a Foundation for OT Cybersecurity” project announcement, 2026-06-25: https://csrc.nist.gov/news/2026/comment-on-nccoe-s-draft-ot-cybersecurity-project
• CISA and partners, “Foundations for OT Cybersecurity: Asset Inventory Guidance,” 2025-08-13: https://www.cisa.gov/sites/default/files/2025-08/joint-guide-foundations-for-OT-cybersecurity-asset-inventory-guidance_508c.pdf
• NIST SP 800-82 Rev.3, Final, 2023-09-28: https://csrc.nist.gov/pubs/sp/800/82/r3/final
• IEC 62443-2-1:2024 overview: https://webstore.iec.ch/en/publication/62883
• IEC 62443-2-1:2024 preview: https://webstore.iec.ch/en/iec_catalog/product/preview/?id=L3B1Yi9wZGYvcHJldmlldy9pbmZvX2llYzYyNDQzLTItMXtlZDIuMH1iLnBkZg%3D%3D
• NIST SP 1339, “OT Backup Quick Start Guide,” Final, 2026-06-17: https://csrc.nist.gov/pubs/sp/1339/final
• Yokogawa, “Industrial Cyber Resilience Center,” 2026-09-15: https://www.yokogawa.com/au/news/press-releases/2026/2026-09-15/
• CISA, “Cross-Sector Cybersecurity Performance Goals”: https://www.cisa.gov/cybersecurity-performance-goals

*This article is implementation and procurement guidance, not a guarantee of legal, safety or standards conformity. Follow the asset owner’s safety procedures, manufacturer information, change controls and applicable law before interacting with production equipment.*