Most OT networks are run from a spreadsheet: one file, a list of IP addresses, a column for the device. It works, right up until it doesn't. As the network grows, that spreadsheet quietly stops matching reality, and that gap is where outages start.
Why IPAM is critical in OT environments
In industrial environments, IP address management goes well beyond simple address allocation. Unlike office networks, OT environments contain PLCs that must keep the same IP for decades, safety systems that require guaranteed address ranges, and production equipment where a single IP conflict halts an entire manufacturing line. Proper IPAM is therefore not a documentation exercise but the foundation for secure industrial networks: it enables effective network segmentation, cuts troubleshooting time during production outages, and produces the evidence standards such as IEC 62443 ask for.
Why OT addressing is different
In an office network an address is disposable: DHCP hands one out, a laptop leaves, the address is recycled. OT does not work that way. A PLC controlling a production line typically keeps the same IP address for ten to twenty years. When it fails and is replaced, the new device must come up on the exact same address, or the HMIs and SCADA systems that talk to it simply cannot find it.
Safety systems need guaranteed, isolated ranges. Production equipment cannot tolerate an address conflict: two devices answering on one IP can halt a manufacturing line. Addresses here are not disposable. They are part of the plant.
Where the spreadsheet breaks
A spreadsheet records what someone believed was true on the day they saved it. It is never checked against the network. New devices get added in a hurry and not written down; a contractor reuses an address that looks free; a row is copied and the IP comes with it. The file and the network drift apart from day one, and nobody knows by how much.
When a conflict finally surfaces, it surfaces as downtime: a production line drops, and the troubleshooting starts from a document that cannot be trusted.
A plan you can read at a glance
A better spreadsheet won't fix it, structure will. A deliberate addressing scheme gives every zone its own range (safety systems in 10.10.x.x, production control in 10.20.x.x, process monitoring in 10.30.x.x) and nests function-level /24s underneath.
Once the address itself carries meaning, you can read the network from it. An engineer who sees 10.10.1.40 knows immediately: safety, emergency shutdown. And a firewall can act on it: a safety PLC has no business talking to an office printer, and a rule on the range enforces exactly that. Structured addressing is what makes network segmentation practical: only once the ranges are cleanly cut can VLANs and firewall rules between the zones be enforced in any meaningful way.
What's specific to OT
Several constraints make industrial IPAM its own discipline. Many OT devices (PLCs, HMIs, sensors) do not support DHCP, or have it disabled; they need static configuration. Legacy PLCs may be locked to a specific range, like 192.168.1.x, and cannot be reconfigured. Safety systems require ranges completely isolated from production traffic. When a production line is expanded, engineers need to find free addresses fast, without risking a conflict. And during an outage, they need to locate a device by its address in seconds.
Faster troubleshooting, and an audit you can pass
Well-managed addresses pay back twice. When a line fails, every device in that zone is identifiable by its range, so the search space collapses. And for compliance (IEC 62443 requires documented segmentation and access control; ISO 27001 expects an asset inventory with network configuration), clear, current IP documentation is what an auditor actually asks for. The same structure that speeds up troubleshooting is the evidence that passes the audit.
From spreadsheet to managed
Moving off the spreadsheet does not mean throwing it away. The existing file is imported as the starting point, then validated against a live discovery of the network, and the discrepancies are the point. Every address that is documented but not found, and every device that is on the network but not in the file, is exactly the risk the spreadsheet was hiding.
Frequently asked
Why doesn't DHCP work in OT environments?
Many OT devices (PLCs, HMIs, sensors) don't support DHCP, or have it disabled; they need static addresses for predictable communication. In a critical production environment, changing an address causes outages, because HMIs and SCADA systems expect their devices at fixed IPs.
How do I prevent IP conflicts during device expansion?
A structured IPAM system documents every address in use and shows the ranges that are free. Reserve ranges for future expansion, put an approval step on new assignments, and use network discovery to find undocumented devices before they cause a conflict.
What IP ranges should I use for different OT zones?
A common pattern is a dedicated /16 per zone (10.10.0.0/16 for safety, 10.20.0.0/16 for production control, 10.30.0.0/16 for monitoring), with /24 subnets for specific functions inside each. The real scheme depends on your requirements and history, though: a brownfield network has to work with the addressing it already has.
How do I document legacy devices without network access?
Physical audits: read the address off the device, its service interface or its local display. Most IPAM tools allow a manual import from a spreadsheet for these. Mark them as "not discoverable" and re-validate during maintenance work.
Should IPv6 be disabled in OT networks?
If IPv6 is not actively used, yes. Many OT devices enable it automatically and use link-local addresses that no IPAM manages, which creates uncontrolled communication paths that can bypass segmentation. Disable it at both device and switch level unless it is explicitly needed.
What compliance requirements apply to IPAM in industry?
IEC 62443 requires documented network segmentation and access control. ISO 27001 expects an asset inventory including network configuration. In pharmaceuticals, FDA 21 CFR Part 11 requires audit trails for configuration changes. Document every assignment, change and approval as compliance evidence.
