Factory OT IP Address Management: Choosing IPAM Without Disrupting PLCs

Deploying an IP address management system on a factory OT network is more than moving a spreadsheet into software. Each address must be linked to a line, cabinet, device, owner and approved change. The team must also know how to restore the setting when a PLC, HMI or inspection terminal is replaced. This guide explains how a manufacturer in Thailand can specify an IPAM system, migrate its records and accept it through factory and site tests. The example configurations in this article are illustrative, not data from a particular plant.

Why OT IP address management becomes a production issue

One line can often be managed with equipment drawings and a spreadsheet. As more lines, inspection machines, MES connections and vendors are added, the “current” address may live in several places: the PLC engineering project, a maintenance notebook and a network team’s file. An address can then be allocated twice, remain reserved after equipment retirement or be changed on a device without the corresponding firewall rule being updated. The weakness is the change process, not merely the ability to search a list.

RFC 5227 explains that two hosts using the same IPv4 address on the same link can cause problems for either or both hosts. The actual production impact depends on the plant’s topology and control application. It is therefore inappropriate to promise a universal amount of downtime or savings from IPAM. The more useful question is whether the plant can identify an address conflict, the affected asset and the approved configuration quickly enough to restore the intended state.

The joint CISA OT asset inventory guidance lists IP address, MAC address, hostname, physical location and criticality among priority attributes. That guidance is a reference for sound inventory practice; it does not impose a US federal requirement on a Thai factory. IPAM manages the address and subnet portion of this information. It does not become a complete OT asset register unless it is connected to device identity, location and responsibility.

This article covers allocation and change control on an existing or planned network. For the wider network architecture, see our industrial network construction guide. For ring and parallel redundancy options, see our industrial network redundancy comparison.

Define the source of truth before buying IPAM

IPAM, DHCP, DNS, the OT asset register and the controller project have different jobs. IPAM records subnets, addresses, reservations, occupancy and approved changes. DHCP distributes configuration and records leases. DNS maps names to addresses. The OT asset register covers the device’s identity, model, location, criticality and maintenance owner. The controller project contains the parameters that are actually deployed to a PLC or HMI. A product that integrates these systems does not make their data automatically consistent.

Set the authoritative system for each field. An IPAM entry marked “in use” does not prove that the PLC was configured. A change on the PLC does not automatically update IPAM. Link the approved value, observed device value and project backup to one change request. This makes a later replacement reproducible rather than dependent on someone’s memory.

NIST SP 800-82 Rev. 3 describes OT security in the context of performance, reliability and safety. Active discovery that is routine on an office network should not be enabled across production equipment without defining the scope, protocol, window and recovery procedure with the equipment owner. Start the inventory from existing project files, switch information, maintenance records and other approved sources. Validate uncertain devices in a limited, agreed test rather than treating a discovery scan as proof of completeness. A silent or disconnected device may not appear in passive observations.

Static addresses, DHCP reservations and PROFINET names require separate decisions

Neither “all OT must use static IP” nor “all devices should use DHCP” is a safe design rule. Record the assignment method per interface, the control protocol, server dependency at startup and vendor support condition. RFC 2131 defines the DHCP lease process; it does not certify that a particular controller can use DHCP in a particular mode.

PROFINET device names and IP parameters have distinct functions. The Siemens PROFINET with STEP 7 manual describes a DHCP option and notes that a PROFINET interface configured for that option no longer supports PROFINET IO functionality in the stated configuration. This is a device and configuration specific warning, not a claim that all PROFINET devices reject DHCP. Check the actual model, firmware and controller project before changing the assignment method. A management port and a control port on one device may have different rules.

For every interface, record the assignment method, engineering tool, device name if applicable, communication peers and replacement procedure. A DHCP reservation based solely on MAC address needs a planned update when hardware is replaced. Add a stable asset ID, cabinet location and device role so a technician can identify the intended replacement. Reservations also govern only the DHCP server’s allocations; they do not prevent someone from manually configuring the same address on another device.

Where DHCP is used, test its failure behavior. Microsoft’s DHCP failover documentation explains how two Windows servers can share IPv4 lease and scope state. It is an implementation option, not a universal mandate for OT. Check DHCP relay, server location, power, DNS and each device’s lease behavior. The production team needs to know which devices can continue working during a server outage and which cannot.

Does IPAM help when PLC addresses remain static?

Yes. It can reserve ranges, distinguish available addresses from spare equipment assignments, detect suspected duplicate records and document approvals. It does not write a configuration to the PLC simply because an address is entered. Include comparison with the actual device in the acceptance test.

Inventory by production context, then collect addresses

An address alone does not tell whether two records are an illegal conflict or legitimate reuse on isolated networks. Define the hierarchy first: site, building, line, cell, network or VLAN, cabinet, device and interface. Account for dual port devices, redundant paths, virtual IPs and spares. Avoid assuming one address equals one machine.

Begin with an evidence tagged candidate inventory. Import the network diagram, PLC project, switch configuration, DHCP lease file, handover package and maintenance log, retaining the source and its date. Mark an address copied from an old drawing as “unverified,” not “confirmed.” Next, reconcile cabinet labels, device settings and approved monitoring data with the candidate records. Return uncertain or duplicate entries to the line owner for a decision. The first milestone is a list of verified, unresolved and out of scope records, with named owners and deadlines.

For illustration, imagine three lines with a PLC, HMI, inspection PC and switch on each line. The resulting 12 devices are a planning example, not a license estimate for a real plant. Count actual interfaces and subnets before obtaining commercial quotes. Even if all 12 records are populated, the rollout is incomplete if nobody owns the unknown devices or future changes.

The joint OT inventory guidance supports including address data within a broader asset record. IPAM still needs a link to the register holding model, firmware, support contract and operational criticality. A shared asset ID is usually more maintainable than having staff type the same attributes into two systems after every replacement.

Do not mark every inherited address scheme as simply right or wrong during migration. Two buildings may use overlapping ranges safely while their networks remain isolated. A later MES connection or remote maintenance route could make that overlap a routing problem. Record both the current boundary and planned connections, then classify ranges as “change now,” “change before interconnection,” or “retain as an approved exception.” Renumbering everything during the initial import widens the validation scope to PLC peer settings, HMI references and inspection PC destinations.

Likewise, a device that does not respond to a probe is not evidence that its address is available. It may be stopped, held as a spare, blocked by a firewall or located on another VLAN. Compare the reservation, controller project, cabinet label and maintenance record. Return an address to the free pool only after its owner confirms retirement. A temporary diagnostic laptop needs an owner and removal date; automatically treating every observed endpoint as a permanent asset will obscure the devices that matter most.

Across sites, names such as “Line 1” or “PLC 1” can recur. Define a unique key from site code, asset ID and network boundary. Reuse that key in engineering project backups, maintenance tickets and physical labels where safe, so a change request can be traced to the cabinet. Confirm label placement with the equipment owner so it does not interfere with safety markings. “Unknown” findings in a pilot are useful: record whether documentation is old, the owner is absent, the vendor controls the setting or the machine cannot be stopped for inspection. Assign a next action and deadline for each class. Test whether IPAM preserves unknown values and who verified them later, rather than reporting an unsupported “100% registered.”

How to compare factory IPAM products and proposals

Assess how the system reaches the OT environment and how changes are controlled before looking at dashboards. Candidates may be a plant hosted platform, a cloud service or an extension of an existing enterprise IPAM. Compare required connections from OT segments, read only operation, backups, offline reference access and local support. In Thailand, verify that maintenance staff can use the workflows, exports, alerts and escalation instructions, while headquarters can audit changes. A translated interface alone does not solve an English only emergency procedure.

Specify whether an IPAM change merely edits the register or also changes DHCP/DNS. If there is automated propagation, require a demonstration of when it happens, who approves it and how to reverse it. It is reasonable to disable automatic production changes during the first phase. IPAM integration does not imply that it can or should program a PLC address directly.

The RFP should name the target models, software versions, direction of integration, failure behavior and test evidence. Ask bidders to handle two records claiming the same address in the same subnet, and to preserve both records for investigation rather than overwriting one. Pricing models differ by address, subnet, user, module or server. Request separate lines for license, cleanup, field validation, training, maintenance and later site expansion. A single total hides the work that is most likely to determine success.

Make every address change reproducible

The operational workflow should follow five stages: request, reservation, device change, reconciliation and closure. The change request identifies the asset ID, old and proposed address, interface, line, maintenance window, communication peers, related DHCP/DNS/firewall settings and rollback method. Reserve the proposed address in IPAM only after checking the live subnet and any protected or spare ranges. Backup the controller project before applying a change using the equipment maker’s method. Then compare the deployed device setting with IPAM, its peers and the expected data flow. Close the change only after deciding when the old address may be reused.

An emergency replacement needs a defined variant. If an HMI fails overnight and a spare must take its old address, staff may not be able to wait for an ordinary approval meeting. They should still record the operator, time, reason, failed unit’s isolation, replacement unit’s identity and deadline for retrospective approval. Verify that the old device is disconnected; otherwise returning it to the network may create a duplicate. Retrospective entry alone is a weak control if it loses the actual order of events.

Split headquarters and local authority by the type of change. A planned swap into an existing reservation can often be performed locally under a rehearsed procedure. Creating a new subnet or changing intersite routing warrants joint review. Requiring headquarters for every routine swap can prolong a stop, while unrestricted local changes can undermine the cross site address plan. Document who may stop the line, who may restore it and how the decision is recorded.

Can duplicate detection replace the change procedure?

No. RFC 5227 covers detection of an address conflict on a link, including precautions before use and detection afterwards. Detection does not resolve a double reservation in the planning system, a stale peer setting or an obsolete firewall rule. Use conflict alerts, approval and device verification as complementary controls.

FAT and SAT: what evidence proves the register is usable?

Use factory acceptance testing (FAT) to exercise imports, roles and abnormal cases away from production. Test that a duplicate within one subnet is flagged, spare addresses are not offered as free, unauthorized changes are blocked, uncertain CSV rows remain visible and the backup restores both values and history. If DHCP/DNS integration is included, demonstrate that approval boundaries control production propagation. Keep test addresses separate from live plant ranges.

Use site acceptance testing (SAT) to compare a representative PLC, HMI, inspection terminal and switch against cabinet labels, device configuration, controller project and IPAM. A FAT cannot prove the real wiring and labels. A SAT limited to happy path checks cannot prove rollback. Include equipment replacement, suspected address conflict, IPAM server outage, DHCP outage where relevant, network partition and mistaken entry. Simulate failures where a live test would create unacceptable production risk. Record who declares recovery complete.

Acceptance scope is a project decision. If all high criticality devices are checked but others are sampled, state the sample and unresolved count in the contract. No generic percentage in this article should be treated as a standard. NIST SP 800-82 Rev. 3 emphasizes OT reliability and safety; a working IPAM dashboard alone cannot establish either outcome.

Estimate cost and value from measured work

License is only one cost. Include document reconciliation, cabinet and port verification, subnet cleanup, data import, approval design, integration tests, training and post launch corrections. For a site managed from Japan and Thailand, include the asset naming convention, bilingual instructions and after hours ownership. Ask vendors what happens commercially if more unverified records are found during migration.

Potential benefits include less time locating an address before replacement, shorter configuration checks, faster diagnosis of IP related incidents and less effort producing audit evidence. Count only incidents that can reasonably be attributed to address management. Do not assume that all past stops were address related or that IPAM eliminates downtime. If baseline data is absent, run a pilot and measure actual work time before writing a return on investment case. A statement such as “20 minutes per swap” would be an illustrative assumption here, not a plant result.

A staged deployment for one line, then the site

Start by defining one line and its connected equipment as a pilot, including who owns each field. Build the evidence tagged candidate inventory and identify unresolved addresses. This work can begin before a product is bought and makes demonstrations more meaningful. Test bidders with the same small dataset and the same bad records. Select for how well they prevent and recover from mistakes, not simply how fast staff can populate a screen.

Next, migrate the pilot, run actual replacement and new terminal change requests, close the FAT/SAT findings and extend the proven model to other lines. Reuse field names and approval classes, while preserving maker specific controller settings. After launch, track unresolved addresses, mismatch count, time to reflect an approved change, delayed emergency approvals and failed replacement restorations. Set numerical targets only after a baseline is measured. A one time complete import is not sustained accuracy unless routine maintenance work updates the record.

Frequently asked questions about factory OT IPAM deployment

Can we extend the IT department’s current IPAM into the factory?

Possibly. Validate static PLC addresses, PROFINET device names, isolated networks, maintenance permissions, outage access and actual device settings with a pilot. Strong DHCP/DNS integration in an IT product is not proof that automatic changes are suitable for control devices. Centralize the register first and automate only paths whose constraints are understood.

Is IPAM implementation cost determined by device count?

No. Licensing may depend on device count, but migration depends on subnet count, source quality, physical checks, sites, integrations and training. Two plants with the same number of devices can require very different cleanup. Quote the same verified scope and unresolved inventory to every bidder.

Can we implement IPAM without changing PLC addresses?

Yes. Start with visibility, reservation and approval. If the inventory finds an overlap or poor address plan, treat remediation as a separate change with a maintenance window and rollback. Inventory migration need not trigger a network renumbering project.

Should we replace static PLC settings with DHCP reservations?

Not as a blanket rule. Check the equipment specification, PROFINET IO or other control mode, startup dependency and replacement identity. A device’s control and maintenance interfaces may differ. Confirm the actual configuration in FAT before changing the plant.

Who should approve addresses: headquarters or the Thai plant?

Divide authority by impact. A rehearsed swap into an existing reservation can be local. New subnets or changes to intersite routing should involve both teams. Document emergency authority and retrospective approval so the procedure still works when a device fails outside office hours.

Summary: the value is a repeatable change, not a prettier address list

Useful factory IPAM links addresses to asset IDs and processes, distinguishes static assignment from DHCP by device, and makes replacement and expansion repeatable. Start with one line, identify uncertain addresses and compare proposals on reconciliation, approvals and acceptance evidence. Include field validation and operational handover in the quote.

If address records for PLCs and inspection terminals at your Thai plant are scattered, contact TOMAS TECH. We can help define the inventory boundary, ownership and acceptance tests while you are still evaluating options.

References

• NIST SP 800-82 Rev. 3: Guide to Operational Technology Security
• CISA and partners: OT Asset Inventory Guidance
• IETF RFC 5227: IPv4 Address Conflict Detection
• IETF RFC 2131: Dynamic Host Configuration Protocol
• Siemens: PROFINET with STEP 7 Function Manual
• Microsoft Learn: DHCP failover in Windows Server