How to plan the network for equipment on site
Before equipment on site is connected, write how addresses are assigned, which segment is kept apart from the others, where remote access stops, and who receives the cables, labels, and diagram at handover. Acceptance checks the paths on that diagram: an address that should answer does answer, and a boundary the diagram forbids is not crossed.
On this page
- Keep the site network apart from telemetry and the business system
- Choose a private range, and write the boundary
- Write the reason for each segment on the diagram
- Stop remote access at the boundary
- Put cables, labels, and power on the same diagram
- Hand over the diagram and the labels together
- Check only the paths the diagram names
- Leave remote access off until the boundary is drawn
Keep the site network apart from telemetry and the business system
This plan covers addresses, segmentation, the remote-access boundary, cable labels, the diagram, and the paths checked on acceptance day. Whether a reading uses MQTT or HTTP, and which business field receives it, comes after the equipment has an address and the paths have been checked against the diagram. Those notes are How to choose MQTT or HTTP for equipment telemetry and How to connect equipment to existing business systems.
A device on the diagram uses the same identifier it received at delivery. Connecting it to the network does not create a second number. How that identifier, the model, the serial number, and the place were written on delivery day is in What to check when equipment is delivered. Equipment can be bought, rented, or taken forward in the same project as development; see Buy, lease, or plan it with development on the homepage.
Choose a private range, and write the boundary
Read on 21 October 2026, RFC 1918 says IANA has reserved three blocks for private internets: 10.0.0.0 through 10.255.255.255 (10/8), 172.16.0.0 through 172.31.255.255 (172.16/12), and 192.168.0.0 through 192.168.255.255 (192.168/16). An enterprise may use these addresses without coordinating with IANA or an Internet registry. They are unique only within the enterprise, or among enterprises that agree to share that private space. The document is dated February 1996 and is a Best Current Practice.
The same document says private addresses have no global meaning. Routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks not using private address space, especially those of Internet service providers, are expected to filter out routing information about private networks. The address plan therefore names which prefix this site uses, which subnet is for equipment, which subnet is for the office, which address is the gateway, and which hosts do not need connectivity outside the enterprise. A private address is not a security boundary. A host that needs a globally unique address still obtains it from a registry. A registry will not assign an address from these three blocks for external connectivity.
Write the reason for each segment on the diagram
Read on 21 October 2026, the catalog page for NIST SP 800-82 Rev. 3 gives the publication date as September 2023 and says it supersedes Rev. 2 of 3 June 2015. The text below is from that publication, DOI 10.6028/NIST.SP.800-82r3. The guide describes operational technology as programmable systems and devices that interact with the physical environment, or that manage devices which do, detecting or causing a direct change by monitoring or controlling devices, processes, and events. Its examples include industrial control, building automation, physical access control, and monitoring or measurement of the physical environment. It generally recommends separating the OT network from the corporate network. Internet access, email, and remote access are typically permitted on the corporate network and not on the OT network. Using the corporate network for OT protocols can expose the equipment to attack. Where a connection is required, the guide says it adds risk, and that organizations may minimize those connections and add further controls.
The same guide says devices may be segmented by management authority, level of trust, functional criticality, data flow, or location, and that an organization may consider an existing model such as the Purdue model, ISA-95 levels, or the three-tier IIoT architecture. Those are options the guide names. A site is not required to adopt Purdue. A DMZ may be added as an enforcement boundary between segments. Grouping components into levels, tiers, or zones comes before isolation devices are applied. Firewall rules should permit connections only between adjacent levels, tiers, or zones. The guide's example, for organizations that use Purdue, is to prevent Level 4 from communicating directly with Level 2, 1, or 0. The appendix describes a VLAN as logical separation on a switch, by port, when physical separation is not feasible, and it says VLANs can be a lower-cost approach while high-criticality devices such as safety systems should consider physically separate switches. The diagram names the reason for each segment, whether separation is a VLAN or a separate switch, and whether any safety-related device has been called out.
Stop remote access at the boundary
Section 6.2.10 says controls should prevent unauthorized remote access to the organization's networks, systems, and data. It describes a virtual private network as a set of protocols for secure remote access, and it discusses IPsec, TLS, and SSH. It says only TLS 1.2 or above should be considered. For OT, the guide says to develop and communicate a process for requesting and enabling remote access; to provide it only when justified and only to the extent the business need requires; that remote access should not circumvent or negate safety or security controls; and that multi-factor authentication should be considered for remote access to the OT system.
When a supplier needs temporary access, the guide says the procedure is still followed. The techniques it lists include temporarily permitted users or protocols such as RDP or SSH, screen sharing, modems, and VPNs. Whichever is used, the considerations it lists include not leaving default credentials in place, removing access when it is no longer required, making sure operations staff know about planned remote activity, considering a connection initiated from the OT environment, and labeling remote-connection devices so operations can disconnect them quickly if use is unauthorized. The plan names who may request access, where the session lands (the DMZ or a named jump host on the diagram, not the equipment segment itself), who is told before it starts, and who removes it afterwards. The guide names no product and no wait in seconds.
Put cables, labels, and power on the same diagram
In the physical-protection section the guide says unshielded twisted pair may be acceptable in an office and may be unsuitable in some OT environments, because of interference from magnetic fields, radio waves, temperature extremes, moisture, dust, and vibration. Organizations should consider cabling or shielding that suits those conditions. The same passage says to consider color-coded cables, connectors, and conduits, plus labeling, so OT and IT segments stay distinct and cross-connections are less likely. Wiring should be neat and contained in cabinets or under floors. Equipment cabinets should be locked when they are not required for operation or safety.
The diagram names which cabinet holds the switch, which circuit feeds it, and which cable color means which segment. Elsewhere the guide says communications and power that support physical-security devices should be considered for added redundancy, isolation, protection, and monitoring. That sentence is about power for devices such as cameras and sensors. It is not a clearance stated in centimetres. The plan does not invent one. The circuit name is on the diagram so a later inspection does not treat the network cabinet and the lighting as one circuit and open both.
Hand over the diagram and the labels together
Both ends of a cable carry the same number. That number appears on the diagram and points at the equipment identifier, the switch port, and the VLAN or segment name. The remote boundary is a line on the diagram: one side names the sources allowed in, the other side is the equipment network. Labels without a diagram, or a diagram whose cables have no labels, is not a completed handover. The person who accepts it signs and writes the date.
A label uses words the next person on site can find. It does not use a short name only the drafter knows. When a port changes, the diagram and both labels change the same day, and the person who changed them is named. Identifiers stay the ones from delivery. The diagram does not start a second series. The diagram version is on the cover and points at the version of the address plan.
Check only the paths the diagram names
The guide says organizations typically map data flows, then put the required communications into the policy of the network devices and permit only authorized communications. Acceptance makes two checks against that map. From inside the same segment, a device address the diagram names can be reached. From a stated host, a boundary the diagram forbids cannot be completed. Both checks record the time, the person, the address, and the result.
The same guide says an active scan introduces traffic and touches devices directly. On an operating OT network it calls for extreme caution, because a scan may make a device unstable or disturb the process, and it says active scans should be scheduled during planned outages whenever possible. A passive scan adds no traffic, but it cannot see a device that is not communicating, and it cannot inspect encrypted traffic. Acceptance is not an unbounded sweep of the whole network. The path check is aimed only at addresses the diagram already names, in a window the operations owner has agreed.
Leave remote access off until the boundary is drawn
If the address plan, the reason for a segment, or the remote boundary is missing from the diagram, remote access stays off. The diagram and the labels are finished before a supplier session is discussed. A remote device is not installed while the diagram does not name who may disconnect it.
Latency, availability, and arrival times stay in the contract and in the company's own rules. Neither RFC 1918 nor this guide assigns those numbers to a site network. Before the plan is handed over, three things are visible: every segment has an address and a reason, remote access stops at a boundary, and acceptance has recorded both a path that should pass and a boundary that should not. The network is given to daily operations when those three are on the diagram and in the record.