Modeling OT Infrastructure in NetBox: Device Types, Custom Fields, and Handling Duplicate IPs

In Part I of this series, we looked at why OT documentation is fragmented and what good looks like. Now let’s get practical: how do you actually model PLCs, HMIs, and isolated assembly line networks in NetBox?

Every PLC on a production line shares characteristics with others of the same model. The manufacturer, the part number, the available interfaces, the default platform. When these details live in spreadsheets, variance creeps in through manual entry: one technician abbreviates the manufacturer name, another spells it out, a third uses a different model number format entirely. Over time, the data becomes difficult to query and impossible to trust.

Device types in NetBox solve this by serving as templates for devices. A device type captures the manufacturer, model, part number, and default platform in a single definition. When you create a new device of that type, it inherits all those characteristics automatically. The result is a high degree of consistency across the environment, regardless of who enters the data or when.

For traditional IT equipment like routers and switches, a community-curated device type library provides ready-made templates. You can copy the YAML definition and import it directly. For OT equipment, the process typically involves pulling specifications from data sheets and creating custom device types that match the actual hardware. The upfront work pays off immediately: once the device type exists, every device of that type starts from a consistent, accurate foundation.

Device Roles and Custom Fields for OT

NetBox does not impose a fixed taxonomy on your infrastructure. Device roles are user-defined, which means you can create roles that match how your organization thinks about OT equipment: PLCs, thin clients, barcode readers, access switches, conveyor motors, SCADA servers, HMIs. The vocabulary belongs to you.

Beyond the core data model, custom fields allow you to capture information specific to your operational requirements. Compliance status, policy assignments, end-of-life dates, maintenance windows. These fields can be grouped visually so that related information appears together when viewing a device. A compliance group might include certification status, last audit date, and regulatory classification. A policy bucket might track change management requirements and approval workflows.

Custom fields also support validation rules and data types. If you need to track end-of-life dates, you can enforce date formatting. If a field should be unique across all devices, you can require uniqueness. This prevents the data quality issues that plague spreadsheet-based documentation, where formatting inconsistencies accumulate over time.

Handling Duplicate IPs in Isolated Networks

Assembly lines often operate as isolated network segments, and sometimes IP addresses are baked directly into the devices. A PLC might ship with a default address of 192.168.1.10, and when you have ten assembly lines running identical equipment, you have ten devices with the same IP address. They never collide because the networks are air-gapped, but traditional IPAM systems struggle to represent this reality.

NetBox handles this through VRFs, or Virtual Routing and Forwarding instances. A VRF defines a separate IP address space where you can enforce or relax uniqueness constraints. By assigning each isolated network segment to its own VRF, you can document duplicate IP addresses without triggering collision errors. The data in NetBox accurately reflects the environment as it actually exists.

The relationship between IP addresses, interfaces, and devices creates a holistic view of network connectivity. An IP address is assigned to an interface, and that interface belongs to a device. When you look at a device, you see its interfaces, their MAC addresses, and the IP addresses assigned to each. When you look at an IP address, you see exactly which device and interface it belongs to. This bidirectional visibility matters when troubleshooting connectivity issues or planning network changes.

Getting OT Data Into NetBox

Data population is where theory meets reality, and the reality of OT environments requires flexibility.

For many teams, the starting point is existing documentation, however imperfect. If you have Excel spreadsheets or CSV files that you trust, NetBox can import that data directly. You can copy and paste CSV content or upload files, mapping columns to NetBox fields. This approach works well for the initial heavy lift of getting baseline data into the system.

Discovery tools can augment static imports, but coverage varies significantly in OT environments. NetBox Discovery uses network scanning, SNMP, and API-based collection to identify devices and gather configuration details. For networks that are connected and accessible, discovery can automate much of the data collection. For air-gapped assembly lines that are not connected to the broader network, discovery simply cannot reach the devices.

The practical reality is that discovery might cover roughly half of an OT environment, sometimes more, sometimes less depending on network architecture. Static documentation from spreadsheets, floor plans, and manual audits fills the remaining gaps. The combination of trusted static data with automated discovery where possible creates a path to comprehensive documentation without requiring either approach to solve the entire problem alone.

With a solid foundation of device types, custom fields, and accurate data, teams can move beyond documentation into automation, using NetBox as the source of truth that drives configuration management and operational workflows for OT.