{"data":{"slug":"ot-asset-inventory-network-discovery","title":"OT Asset Inventory and Network Discovery","summary":"OT asset inventory — knowing exactly what hardware and software is running on the industrial network — is the foundation of OT security and maintenance.","category":{"slug":"industrial-cybersecurity","name":"Industrial Cybersecurity"},"url":"https://wiki.aspotomasyon.com/article/ot-asset-inventory-network-discovery","markdown_url":"https://wiki.aspotomasyon.com/article/ot-asset-inventory-network-discovery.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/ot-asset-inventory-network-discovery","published":"2026-08-06T12:26:37+00:00","modified":"2026-09-13T11:13:13+00:00","reading_minutes":5,"word_count":893,"image":"https://wiki.aspotomasyon.com/assets/social/ot-asset-inventory-network-discovery-cda3c185cad5.png","html":"<p><strong>OT asset inventory</strong> — knowing exactly what hardware and software is running on the industrial network — is the foundation of OT security and maintenance. You cannot protect, patch, or even reliably operate systems you do not know exist. Yet many plants have incomplete asset lists assembled from spreadsheets, memory, and chance discoveries during outages. This article explains why a complete, current OT asset inventory is essential, how to build one, and how to keep it accurate over time.</p><figure class=\"article-figure\"><img src=\"https://wiki.aspotomasyon.com/assets/diagrams/industrial-cybersecurity-context.svg\" width=\"1100\" height=\"460\" loading=\"lazy\" decoding=\"async\" alt=\"Conceptual access controls around an OT service. Actual zones, conduits, protections, and response actions require a site-specific assessment.\"><figcaption>Conceptual access controls around an OT service. Actual zones, conduits, protections, and response actions require a site-specific assessment. <a href=\"https://wiki.aspotomasyon.com/assets/diagrams/industrial-cybersecurity-context.svg\" target=\"_blank\" rel=\"noopener\">View full size</a></figcaption></figure>\n\n<h2 id=\"why-asset-inventory-matters\">Why Asset Inventory Matters</h2>\n\n<ul>\n  <li><strong>Security:</strong> unmanaged devices are how attackers enter and move laterally (see <a href=\"https://wiki.aspotomasyon.com/article/iec-62443-industrial-cybersecurity-standards\">IEC 62443</a>); you can only defend what you can see.</li>\n  <li><strong>Patch management:</strong> you cannot plan patching without knowing what software and firmware versions exist (see <a href=\"https://wiki.aspotomasyon.com/article/ics-patch-management\">ICS Patch Management</a>).</li>\n  <li><strong>Risk assessment:</strong> vulnerabilities only matter if the asset is actually present.</li>\n  <li><strong>Maintenance and lifecycle:</strong> end-of-life equipment, spare parts, and obsolescence planning all start from the inventory.</li>\n  <li><strong>Compliance:</strong> many standards (IEC 62443, NIST SP 800-82, and sector regulations) require an asset inventory.</li>\n</ul>\n\n<h2 id=\"what-to-record\">What to Record</h2>\n\n<p>A useful OT asset record goes beyond \"IP address and hostname\":</p>\n\n<table>\n  <thead>\n    <tr><th>Category</th><th>Attributes</th></tr>\n  </thead>\n  <tbody>\n    <tr><td>Identity</td><td>Hostname, IP/MAC address, asset tag, location (area, cabinet)</td></tr>\n    <tr><td>Hardware</td><td>Vendor, model, serial number, hardware revision</td></tr>\n    <tr><td>Software</td><td>Operating system, version, installed applications, firmware version</td></tr>\n    <tr><td>Function</td><td>Role (PLC, HMI, historian, gateway, switch), process area served, criticality</td></tr>\n    <tr><td>Ownership</td><td>Responsible team, vendor support contract, service schedule</td></tr>\n    <tr><td>Lifecycle</td><td>Installation date, warranty/end-of-life dates, patch status</td></tr>\n    <tr><td>Network</td><td>VLAN/zone, connections, open ports/services (where known)</td></tr>\n  </tbody>\n</table>\n\n<h2 id=\"discovery-methods\">Discovery Methods</h2>\n\n<h3 id=\"1-passive-discovery-safe-continuous\">1. Passive discovery (safe, continuous)</h3>\n\n<p>Passive sensors tap network traffic (via SPAN ports or network taps) and build a picture of devices, protocols, and conversations without sending a single packet to production devices. This is the safest method: it cannot disrupt a PLC. Passive tools identify devices from their traffic signatures and are the recommended baseline for OT.</p>\n\n<h3 id=\"2-active-discovery-use-with-care\">2. Active discovery (use with care)</h3>\n\n<p>Active scanning (ping sweeps, SNMP queries, port scans) probes devices directly. It is faster and reveals more detail (open ports, SNMP OIDs), but it can disturb fragile legacy devices and increase network load. Rules:</p>\n\n<ul>\n  <li>Scan only during approved windows, in a test or low-risk segment first.</li>\n  <li>Exclude known-critical and safety devices, or scan them only with the vendor's blessing.</li>\n  <li>Use read-only credentials (SNMP read community/version 3) and avoid aggressive scans.</li>\n  <li>Never run vulnerability scanners (which send exploit payloads) against production OT without explicit approval.</li>\n</ul>\n\n<h3 id=\"3-manual-source-based-inventory\">3. Manual / source-based inventory</h3>\n\n<p>Import data from the sources that already exist: switch MAC tables, DHCP leases, DNS, the PLC engineering databases, maintenance records, and the previous spreadsheets. This fills in what network discovery cannot see (e.g., devices on serial links or isolated segments).</p>\n\n<h2 id=\"building-the-process\">Building the Process</h2>\n\n<ol>\n  <li><strong>Start with the critical systems.</strong> Prioritize: safety systems, DCS/PLC controllers, historians, and gateways first.</li>\n  <li><strong>Deploy passive discovery</strong> at the network core and at key segments; let it run for weeks to catch intermittent devices.</li>\n  <li><strong>Reconcile</strong> discovered devices against existing lists; investigate every unknown device — unknowns are either forgotten assets or intruders.</li>\n  <li><strong>Store in a CMDB or asset tool</strong> that supports custom attributes and change history; a spreadsheet is a starting point, not a destination.</li>\n  <li><strong>Connect to change control:</strong> every new device or network change updates the inventory as part of the MOC process.</li>\n</ol>\n\n<h2 id=\"keeping-the-inventory-current\">Keeping the Inventory Current</h2>\n\n<p>The hard part is not the first inventory; it is keeping it true:</p>\n\n<ul>\n  <li><strong>Continuous discovery:</strong> passive sensors run permanently and flag new devices automatically.</li>\n  <li><strong>Alerting:</strong> new or changed devices generate a review task (\"is this device authorized?\").</li>\n  <li><strong>Periodic audits:</strong> reconcile quarterly against switch tables and engineering databases.</li>\n  <li><strong>Lifecycle hooks:</strong> update firmware/software versions in the inventory when patching or commissioning changes them.</li>\n  <li><strong>Ownership:</strong> assign an owner for each asset; ownerless assets decay into stale records.</li>\n</ul>\n\n<h2 id=\"common-pitfalls\">Common Pitfalls</h2>\n\n<ul>\n  <li><strong>Relying on active scanning only.</strong> The gaps — unmanaged switches, serial devices, temporary laptops — are exactly what passive monitoring sees and active scanning misses or disturbs.</li>\n  <li><strong>Inventory as a one-off project.</strong> A stale inventory is worse than none: it creates false confidence.</li>\n  <li><strong>Ignoring the human element.</strong> Contractors and engineers plug in laptops and test rigs; the inventory process must include their devices.</li>\n  <li><strong>No criticality field.</strong> Without criticality, you cannot prioritize patching and protection.</li>\n  <li><strong>Storing incomplete data.</strong> An IP-only list does not support patching, risk, or lifecycle decisions.</li>\n</ul>\n\n<h2 id=\"summary\">Summary</h2>\n\n<p>A current, complete OT asset inventory is the prerequisite for security, patching, and reliable operations. Build it with continuous passive discovery, supplement with carefully managed active discovery and existing data sources, store it in a tool with change history, and keep it alive through alerting, audits, and change control. Treat every unknown device as either a forgotten asset or a potential intruder — and resolve it either way.</p><section class=\"engineering-check\"><h2 id=\"apply-this-to-your-project\">Apply this to your project</h2><ul><li>Identify asset owners, permitted communications, operational dependencies, and consequences of losing the function.</li><li>Test access restrictions and visibility without disrupting plant operations; agree the activity with the OT owner.</li><li>Validate an offline recovery path and document who can authorize isolation, restoration, and return to service.</li></ul><p><a href=\"https://wiki.aspotomasyon.com/guides\">Follow an ASP project guide</a> to connect the fundamentals with implementation and acceptance.</p></section><figure class=\"article-figure\"><img src=\"https://wiki.aspotomasyon.com/assets/diagrams/industrial-cybersecurity-review.svg\" width=\"1100\" height=\"460\" loading=\"lazy\" decoding=\"async\" alt=\"Engineering review sequence: Inventory → Restrict → Observe → Recover. Keep the recorded evidence with the accepted configuration.\"><figcaption>Engineering review sequence: Inventory → Restrict → Observe → Recover. Keep the recorded evidence with the accepted configuration. <a href=\"https://wiki.aspotomasyon.com/assets/diagrams/industrial-cybersecurity-review.svg\" target=\"_blank\" rel=\"noopener\">View full size</a></figcaption></figure><h2 id=\"primary-references-and-further-reading\">Primary references and further reading</h2><p>Use the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.</p><ul><li><a href=\"https://csrc.nist.gov/pubs/sp/800/82/r3/final\" rel=\"noopener noreferrer\" target=\"_blank\">NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security</a></li><li><a href=\"https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards\" rel=\"noopener noreferrer\" target=\"_blank\">ISA — ISA/IEC 62443 series</a></li></ul><!-- asp-editorial-202609 -->","markdown":"# OT Asset Inventory and Network Discovery\n\n> OT asset inventory — knowing exactly what hardware and software is running on the industrial network — is the foundation of OT security and maintenance.\n\n- Canonical URL: https://wiki.aspotomasyon.com/article/ot-asset-inventory-network-discovery\n- Publisher: ASP OTOMASYON A.Ş. (ASP OTOMASYON Wiki)\n- Category: Industrial Cybersecurity\n- Published: 2026-08-06 · Updated: 2026-09-13\n- Reading time: 5 min · Language: English\n\n**OT asset inventory** — knowing exactly what hardware and software is running on the industrial network — is the foundation of OT security and maintenance. You cannot protect, patch, or even reliably operate systems you do not know exist. Yet many plants have incomplete asset lists assembled from spreadsheets, memory, and chance discoveries during outages. This article explains why a complete, current OT asset inventory is essential, how to build one, and how to keep it accurate over time.\n\n![Conceptual access controls around an OT service. Actual zones, conduits, protections, and response actions require a site-specific assessment.](https://wiki.aspotomasyon.com/assets/diagrams/industrial-cybersecurity-context.svg)\n\n*Conceptual access controls around an OT service. Actual zones, conduits, protections, and response actions require a site-specific assessment.*\n\n## Why Asset Inventory Matters\n\n- **Security:** unmanaged devices are how attackers enter and move laterally (see [IEC 62443](https://wiki.aspotomasyon.com/article/iec-62443-industrial-cybersecurity-standards) ); you can only defend what you can see.\n- **Patch management:** you cannot plan patching without knowing what software and firmware versions exist (see [ICS Patch Management](https://wiki.aspotomasyon.com/article/ics-patch-management) ).\n- **Risk assessment:** vulnerabilities only matter if the asset is actually present.\n- **Maintenance and lifecycle:** end-of-life equipment, spare parts, and obsolescence planning all start from the inventory.\n- **Compliance:** many standards (IEC 62443, NIST SP 800-82, and sector regulations) require an asset inventory.\n\n## What to Record\n\nA useful OT asset record goes beyond \"IP address and hostname\":\n\n| Category | Attributes |\n| --- | --- |\n| Identity | Hostname, IP/MAC address, asset tag, location (area, cabinet) |\n| Hardware | Vendor, model, serial number, hardware revision |\n| Software | Operating system, version, installed applications, firmware version |\n| Function | Role (PLC, HMI, historian, gateway, switch), process area served, criticality |\n| Ownership | Responsible team, vendor support contract, service schedule |\n| Lifecycle | Installation date, warranty/end-of-life dates, patch status |\n| Network | VLAN/zone, connections, open ports/services (where known) |\n\n## Discovery Methods\n\n### 1. Passive discovery (safe, continuous)\n\nPassive sensors tap network traffic (via SPAN ports or network taps) and build a picture of devices, protocols, and conversations without sending a single packet to production devices. This is the safest method: it cannot disrupt a PLC. Passive tools identify devices from their traffic signatures and are the recommended baseline for OT.\n\n### 2. Active discovery (use with care)\n\nActive scanning (ping sweeps, SNMP queries, port scans) probes devices directly. It is faster and reveals more detail (open ports, SNMP OIDs), but it can disturb fragile legacy devices and increase network load. Rules:\n\n- Scan only during approved windows, in a test or low-risk segment first.\n- Exclude known-critical and safety devices, or scan them only with the vendor's blessing.\n- Use read-only credentials (SNMP read community/version 3) and avoid aggressive scans.\n- Never run vulnerability scanners (which send exploit payloads) against production OT without explicit approval.\n\n### 3. Manual / source-based inventory\n\nImport data from the sources that already exist: switch MAC tables, DHCP leases, DNS, the PLC engineering databases, maintenance records, and the previous spreadsheets. This fills in what network discovery cannot see (e.g., devices on serial links or isolated segments).\n\n## Building the Process\n\n1. **Start with the critical systems.** Prioritize: safety systems, DCS/PLC controllers, historians, and gateways first.\n2. **Deploy passive discovery** at the network core and at key segments; let it run for weeks to catch intermittent devices.\n3. **Reconcile** discovered devices against existing lists; investigate every unknown device — unknowns are either forgotten assets or intruders.\n4. **Store in a CMDB or asset tool** that supports custom attributes and change history; a spreadsheet is a starting point, not a destination.\n5. **Connect to change control:** every new device or network change updates the inventory as part of the MOC process.\n\n## Keeping the Inventory Current\n\nThe hard part is not the first inventory; it is keeping it true:\n\n- **Continuous discovery:** passive sensors run permanently and flag new devices automatically.\n- **Alerting:** new or changed devices generate a review task (\"is this device authorized?\").\n- **Periodic audits:** reconcile quarterly against switch tables and engineering databases.\n- **Lifecycle hooks:** update firmware/software versions in the inventory when patching or commissioning changes them.\n- **Ownership:** assign an owner for each asset; ownerless assets decay into stale records.\n\n## Common Pitfalls\n\n- **Relying on active scanning only.** The gaps — unmanaged switches, serial devices, temporary laptops — are exactly what passive monitoring sees and active scanning misses or disturbs.\n- **Inventory as a one-off project.** A stale inventory is worse than none: it creates false confidence.\n- **Ignoring the human element.** Contractors and engineers plug in laptops and test rigs; the inventory process must include their devices.\n- **No criticality field.** Without criticality, you cannot prioritize patching and protection.\n- **Storing incomplete data.** An IP-only list does not support patching, risk, or lifecycle decisions.\n\n## Summary\n\nA current, complete OT asset inventory is the prerequisite for security, patching, and reliable operations. Build it with continuous passive discovery, supplement with carefully managed active discovery and existing data sources, store it in a tool with change history, and keep it alive through alerting, audits, and change control. Treat every unknown device as either a forgotten asset or a potential intruder — and resolve it either way.\n\n## Apply this to your project\n\n- Identify asset owners, permitted communications, operational dependencies, and consequences of losing the function.\n- Test access restrictions and visibility without disrupting plant operations; agree the activity with the OT owner.\n- Validate an offline recovery path and document who can authorize isolation, restoration, and return to service.\n\n[Follow an ASP project guide](https://wiki.aspotomasyon.com/guides) to connect the fundamentals with implementation and acceptance.\n\n![Engineering review sequence: Inventory → Restrict → Observe → Recover. Keep the recorded evidence with the accepted configuration.](https://wiki.aspotomasyon.com/assets/diagrams/industrial-cybersecurity-review.svg)\n\n*Engineering review sequence: Inventory → Restrict → Observe → Recover. Keep the recorded evidence with the accepted configuration.*\n\n## Primary references and further reading\n\nUse the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.\n\n- [NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security](https://csrc.nist.gov/pubs/sp/800/82/r3/final)\n- [ISA — ISA/IEC 62443 series](https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards)\n\n---\n\nCite the canonical article: https://wiki.aspotomasyon.com/article/ot-asset-inventory-network-discovery (OT Asset Inventory and Network Discovery, ASP OTOMASYON, updated 2026-09-13).\n","headings":[{"id":"why-asset-inventory-matters","title":"Why Asset Inventory Matters"},{"id":"what-to-record","title":"What to Record"},{"id":"discovery-methods","title":"Discovery Methods"},{"id":"building-the-process","title":"Building the Process"},{"id":"keeping-the-inventory-current","title":"Keeping the Inventory Current"},{"id":"common-pitfalls","title":"Common Pitfalls"},{"id":"summary","title":"Summary"},{"id":"apply-this-to-your-project","title":"Apply this to your project"},{"id":"primary-references-and-further-reading","title":"Primary references and further reading"}],"faq":[],"references":[{"name":"NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security","url":"https://csrc.nist.gov/pubs/sp/800/82/r3/final"},{"name":"ISA — ISA/IEC 62443 series","url":"https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards"}],"related":[{"slug":"mitre-attack-for-ics-threat-informed-defense","title":"MITRE ATT&CK for ICS: Using the Matrix for Threat-Informed OT Defense","summary":"ATT&CK for ICS gives OT teams a shared catalog of adversary behavior, so detection and control gaps can be tested against plausible scenarios instead of…","category":{"slug":"industrial-cybersecurity","name":"Industrial Cybersecurity"},"url":"https://wiki.aspotomasyon.com/article/mitre-attack-for-ics-threat-informed-defense","markdown_url":"https://wiki.aspotomasyon.com/article/mitre-attack-for-ics-threat-informed-defense.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/mitre-attack-for-ics-threat-informed-defense","published":"2026-10-11T11:46:21+00:00","modified":"2026-10-11T11:46:21+00:00","reading_minutes":8,"word_count":1676,"image":"https://wiki.aspotomasyon.com/assets/social/mitre-attack-for-ics-threat-informed-defense-dd88cfe7cb9b.png"},{"slug":"iec-62443-zones-conduits-workflow","title":"IEC 62443 Zones and Conduits: A Practical Partitioning Workflow","summary":"A zone groups assets with shared security needs, a conduit carries the controlled communication between zones, and together they give the IEC 62443 workflow…","category":{"slug":"industrial-cybersecurity","name":"Industrial Cybersecurity"},"url":"https://wiki.aspotomasyon.com/article/iec-62443-zones-conduits-workflow","markdown_url":"https://wiki.aspotomasyon.com/article/iec-62443-zones-conduits-workflow.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/iec-62443-zones-conduits-workflow","published":"2026-10-11T11:46:21+00:00","modified":"2026-10-11T11:46:21+00:00","reading_minutes":8,"word_count":1705,"image":"https://wiki.aspotomasyon.com/assets/social/iec-62443-zones-conduits-workflow-9cab65877d4a.png"},{"slug":"opc-da-to-ua-migration-guide","title":"Migrating from OPC DA to OPC UA","summary":"Migrating from OPC DA to OPC UA is one of the most common infrastructure projects in industrial IT. OPC DA (Data Access) has served industry for more than two…","category":{"slug":"opc-solutions","name":"OPC Solutions"},"url":"https://wiki.aspotomasyon.com/article/opc-da-to-ua-migration-guide","markdown_url":"https://wiki.aspotomasyon.com/article/opc-da-to-ua-migration-guide.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/opc-da-to-ua-migration-guide","published":"2026-08-06T12:26:37+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":5,"word_count":999,"image":"https://wiki.aspotomasyon.com/assets/social/opc-da-to-ua-migration-guide-4dc7a9d57cd5.png"},{"slug":"ot-security-architecture-defense-in-depth","title":"OT Security Architecture: Defense in Depth for Industrial Networks","summary":"Operational Technology (OT) environments — including industrial control systems (ICS), SCADA, DCS, and safety instrumented systems (SIS) — present unique…","category":{"slug":"industrial-cybersecurity","name":"Industrial Cybersecurity"},"url":"https://wiki.aspotomasyon.com/article/ot-security-architecture-defense-in-depth","markdown_url":"https://wiki.aspotomasyon.com/article/ot-security-architecture-defense-in-depth.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/ot-security-architecture-defense-in-depth","published":"2026-05-13T12:07:53+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":10,"word_count":2092,"image":"https://wiki.aspotomasyon.com/assets/social/ot-security-architecture-defense-in-depth-427478438d17.png"}],"citation":"ASP OTOMASYON. OT Asset Inventory and Network Discovery. Updated 2026-09-13. https://wiki.aspotomasyon.com/article/ot-asset-inventory-network-discovery"}}