Operational Technology (OT) Networks

OT networks manage industrial control systems, SCADA, and physical infrastructure. Learn OT network characteristics, IT/OT segmentation, and how to model OT address space in LightMesh IPAM for attribution, audit, and change planning.

Operational Technology (OT) networks connect programmable systems that interact with the physical environment: SCADA masters, PLCs, RTUs, HMIs, DCS controllers, historians, engineering workstations, and building automation systems. OT networks govern industrial control systems (ICS) across critical infrastructure, including power generation, water treatment, manufacturing, transportation, and more.

IPAM for OT is not about active scanning or configuration push. It is about attribution, segmentation evidence, change history, and safe network intelligence. LightMesh provides a read-only source of truth for OT address space: who owns each IP, which zone it belongs to, what changed recently, and how planned state compares to live state.

This guide covers OT network architecture, common operational challenges, and practical LightMesh modelling recommendations. For industry-specific applications, see Water & Wastewater, Manufacturing, and Utilities & Energy.

Why OT networks matter

OT networks are critical infrastructure. A misallocated IP address, an undocumented vendor remote access path, or a stale NAT rule can affect control-room visibility, field operations, and incident response. Unlike enterprise IT, where a misconfigured IP means a helpdesk ticket, an OT IP conflict can affect physical processes.

OT environments carry structural challenges that compound over time. Equipment has long lifecycles: PLCs and RTUs may operate for 15-20 years. Documentation lives in spreadsheets maintained by a single engineer who may retire next year. Vendor-maintained systems introduce remote access paths that are rarely documented in network records. The result is address space that is poorly understood, hard to audit, and risky to change.

IT/OT convergence, Industry 4.0, and IIoT are increasing connectivity between enterprise and control networks. This creates new address planning requirements and new audit obligations. Organisations need a single, trusted view of address space that spans both environments, not a spreadsheet that is six months out of date.

Common OT architecture

OT networks commonly follow the Purdue Model, which defines layers from enterprise systems down to physical field devices. ISA/IEC 62443 extends this with zone-and-conduit modelling for industrial automation and control system (IACS) cybersecurity.

flowchart TB
  subgraph Enterprise["L5 - Enterprise"]
    ERP["ERP / Business Systems"]
    Email["Email / Corporate"]
  end
  subgraph DMZ["L3.5 - Industrial DMZ"]
    Jump["Jump Hosts"]
    Vendor["Vendor Access"]
    HistProxy["Historian Proxies"]
  end
  subgraph Control["L3 - Control Network"]
    SCADA["SCADA Masters"]
    HMI["HMIs"]
    Eng["Engineering Workstations"]
    Hist["Historians"]
  end
  subgraph Field["L1-L2 - Field Network"]
    PLC["PLCs"]
    RTU["RTUs"]
    Sensor["Sensors / Actuators"]
  end
  Enterprise -->|"Firewall"| DMZ
  DMZ -->|"Firewall"| Control
  Control -->|"Industrial Protocol"| Field

The Purdue Model creates distinct zones. Each zone has different security requirements, different device types, and different addressing needs. LightMesh models these zones as Zones with custom attributes for site, process area, device class, and support ownership.

Common operational challenges

OT teams face challenges that enterprise IPAM tools rarely address:

  • Undocumented address space. Decades of incremental deployments leave subnets allocated in spreadsheets, on sticky notes, or in the memory of a single engineer. When that engineer retires, the address history retires with them.

  • Active scanning is unsafe for OT devices. Many PLCs, RTUs, and HMIs react unpredictably to network scanning. A port scan can trigger device reboots, process interruptions, or alarm conditions. OT environments require passive discovery methods: DHCP observation, nmap on safe protocols only, or manual import.

  • Vendor remote access is undocumented. Integrators and vendors maintain remote access paths through VPNs, jump hosts, or cellular gateways. These paths are rarely recorded in network documentation, creating blind spots during incident response.

  • Incident attribution latency. When the SOC detects suspicious traffic on an OT IP, they need to know: which site, which zone, which device, who owns it, and what changed recently. Without a central source of truth, this requires phone calls and spreadsheet archaeology, taking hours rather than minutes.

  • Overlapping RFC1918 across sites. Many OT environments use the same private address ranges (10.0.0.0/8, 172.16.0.0/12) at multiple sites. This creates conflicts when sites connect via VPN, during M&A integration, or when vendors bridge networks.

  • Change windows constrain address planning. OT changes happen during scheduled maintenance windows, often quarterly or annually. Planning must be precise because there is no opportunity for quick rollback if an address conflict surfaces during cutover.

  • Audit evidence gaps. Frameworks like NERC CIP, NIST SP 800-82, CISA CPGs, and ISA/IEC 62443 require evidence of asset inventory, segmentation, and change governance. Spreadsheets do not satisfy auditors.

How LightMesh helps

Model OT zones

LightMesh uses Sites to model physical locations, Zones to model Purdue Model layers with rich custom attributes, and Network Containers as a view feature to group similar subnets across Sites or cloud accounts for visibility. A typical OT deployment might include:

Zone Purpose Custom Attributes
Enterprise ERP, email, corporate systems site, business unit
Industrial DMZ Jump hosts, vendor access, historian proxies zone type, vendor contacts
Control Network SCADA, HMIs, engineering workstations process area, safety criticality
Field Network PLCs, RTUs, sensors asset class, maintenance owner, change window
Vendor Zone Integrator remote access vendor, contact, purpose, NAT mapping, expiry

Custom attributes on Zones and Subnets let you attach site-specific metadata (asset class, process area, vendor, maintenance owner, change window) without modifying the IPAM schema.

Incident attribution without active scanning

When the SOC calls about a suspicious IP, LightMesh answers the attribution question in seconds:

  1. Search the IP in LightMesh
  2. See the zone, subnet, site, process area, and device class
  3. View the support group and maintenance owner
  4. Check recent changes: who modified this subnet, when, and what changed
  5. Identify NAT mappings if the IP is translated

This workflow resolves IP → site → zone → owner → recent changes without active scanning or phone calls.

Vendor access documentation

Use custom attributes to document vendor remote access paths:

  • Vendor name and contact information
  • Purpose of access (maintenance, troubleshooting, upgrade)
  • NAT mapping (external IP → internal IP)
  • Access window and expiry date
  • Support group responsible for the access path

Review these records quarterly. Expired vendor access should be archived.

Segmentation evidence

LightMesh documents which zones exist, which subnets belong to each zone, and how address space is partitioned across the Purdue Model layers. This provides evidence for auditors assessing segmentation under NIST SP 800-82, ISA/IEC 62443, or CISA CPGs.

LightMesh does not enforce segmentation. That belongs to firewalls, NAC, and network access control. LightMesh provides the documentation layer that supports those controls.

Planned-vs-live reconciliation

Compare what is planned in LightMesh against what is live on the network. Before any change window, review:

  • Planned subnet allocations vs. actual allocations
  • Overlap detection across zones and sites
  • Stale reservations that can be released
  • Address space reserved for equipment that was never deployed

This workflow is described in Getting Started and demonstrated with nmap scan sync.

Best practices

  1. Model your zone hierarchy before importing data. Define your Purdue Model layers, site groupings, and custom attribute schema before importing subnets. A good model makes import faster and audit evidence easier to generate.

  2. Import passively. Use DHCP lease sync (DHCP Discovery Agent), nmap scan sync (lightmesh scan sync), or spreadsheet import (Import) to populate LightMesh. Do not run active scans against OT devices.

  3. Document every vendor access path. Record vendor name, contact, purpose, NAT mapping, and expiry as custom attributes on the relevant subnet or zone. Review quarterly.

  4. Use consistent custom attributes across all OT zones. Define a standard schema (site, process area, asset class, safety criticality, vendor, maintenance owner, change window) and apply it uniformly. Consistency makes filtering and reporting reliable.

  5. Separate overlapping ranges by Site or Zone. If two sites use 10.0.0.0/24, model them in separate Sites or Zones. LightMesh tracks uniqueness within a Zone, but overlapping ranges across sites need clear separation.

  6. Link NAT mappings to IP assignments. Use the NAT feature to document source and destination translations. This makes vendor access paths and remote connectivity visible during incident response.

  7. Review drift regularly. Run planned-vs-live reconciliation before every change window. Compare what LightMesh says should be in use against what is actually live.

  8. Export audit evidence on demand. Use audit logging and roles and RBAC to generate evidence for NERC CIP, NIST SP 800-82, ISA/IEC 62443, or CISA CPG assessments.

What LightMesh does not do

LightMesh is a read-only source of network intelligence for OT environments. It does not:

  • Control PLCs, RTUs, HMIs, relays, or SCADA systems. LightMesh does not push configuration into industrial control equipment. Operational changes remain under your engineering controls and change windows.

  • Push network configuration. LightMesh does not configure routers, switches, or firewalls. It is a documentation and planning layer, not a control plane.

  • Guarantee compliance. LightMesh provides evidence and audit trails that support NERC CIP, NIST SP 800-82, ISA/IEC 62443, and CISA CPG assessments. It does not certify compliance. That requires your security and compliance teams.

  • Replace your SIEM, CMDB, or OT monitoring platform. LightMesh complements these tools by providing IP attribution context. It does not replace them.

  • Safely discover every OT asset. Active scanning against OT devices can cause process interruptions. LightMesh supports passive discovery (DHCP, nmap safe protocols) and manual import. Some OT devices may need to be documented manually.

FAQ

What is an OT network? An OT (Operational Technology) network connects programmable systems that interact with the physical environment: SCADA systems, PLCs, RTUs, HMIs, DCS controllers, and building automation. OT networks govern industrial control systems across critical infrastructure including power generation, water treatment, manufacturing, and transportation.

Can LightMesh scan my OT network? LightMesh supports passive discovery methods: DHCP lease sync via the DHCP Discovery Agent, nmap scan sync via the CLI, and spreadsheet import. Active scanning against OT devices (PLCs, RTUs, HMIs) can cause process interruptions and should be avoided. Some OT devices must be documented manually.

Does LightMesh control PLCs or SCADA? No. LightMesh is a read-only source of network truth. It documents address space, provides attribution, and supports audit evidence. It does not push configuration into PLCs, RTUs, HMIs, relays, SCADA systems, or any industrial control equipment.

How does LightMesh help with IT/OT segmentation? LightMesh documents which zones exist and how address space is partitioned across Purdue Model layers. This provides the documentation layer that supports segmentation controls (firewalls, NAC). LightMesh does not enforce segmentation; it provides evidence for auditors that segmentation exists.

Can LightMesh help with NERC CIP or ISA/IEC 62443? LightMesh provides audit trails, asset inventory evidence, and segmentation documentation that support assessments under NERC CIP, ISA/IEC 62443, NIST SP 800-82, and CISA CPGs. LightMesh does not guarantee compliance; it provides evidence that your compliance teams can use.

How do I model overlapping RFC1918 ranges? If two sites use the same private address range (e.g., 10.0.0.0/24), model them in separate Zones. LightMesh tracks IP uniqueness within a zone, so overlapping ranges across sites require clear zone separation to avoid attribution ambiguity.

What is the Purdue Model? The Purdue Model defines layers for industrial control system networks: Enterprise (L5), Industrial DMZ (L3.5), Control Network (L3), and Field Network (L1-L2). ISA/IEC 62443 extends this with zone-and-conduit modelling for cybersecurity. LightMesh maps these layers to Zones (logical network areas) and Sites (physical locations).

How does LightMesh handle vendor remote access? Document vendor access paths using custom attributes on subnets or zones: vendor name, contact, purpose, NAT mapping, access window, and expiry. Review these records quarterly and archive expired access. This documentation supports incident response and audit evidence.

References

Previous