Why It Breaks Down
The OT/IT boundary is the most consequential security boundary in an industrial facility — and the one most routinely violated during temporary operations. Turnarounds, construction programs, and remote operations bring large contractor workforces, unmanaged devices, and ad-hoc network connectivity into operational environments where the consequences of boundary violations are not IT incidents — they are process safety incidents. The problems below are not hypothetical. They are the documented failure patterns of temporary industrial connectivity managed as an afterthought.
Temporary Networks Are Deployed With No OT/IT Segmentation
The most common temporary connectivity solution at an industrial site — carrier LTE on contractor devices, a Wi-Fi access point in the site office, a cellular hotspot for the turnaround coordinator — provides zero OT/IT segmentation by design. Every device on the carrier network is on the same logical network as every other device on that carrier. The contractor's smartphone that is also occasionally connected to a CMMS tablet is a lateral movement path between the carrier network and anything the CMMS tablet bridges to. This is not a sophisticated attack vector — it is a structural property of unmanaged shared connectivity.
Contractor Devices Bridge the OT/IT Boundary Without Anyone Knowing
During a large turnaround, hundreds of contractor devices join whatever connectivity is available. Some of those devices — permit tablets, CMMS clients, work order systems — are provisioned with access to plant IT systems. When a contractor's personal smartphone shares a hotspot with a CMMS tablet, or a portable Wi-Fi router is plugged into a site-office ethernet port that connects to plant IT, the OT/IT boundary has been bridged through a path that no one authorized, no one documented, and no one is monitoring. The plant IT team has no visibility into the carrier network; the OT team has no visibility into what the contractors brought; and the TAR manager has no visibility into any of it.
Active OT Asset Discovery Is Dangerous on Live Control Systems
Industrial OT environments — PLCs, DCS systems, RTUs, safety instrumented systems — are not designed to handle the kind of active network scanning that IT security tools use for asset discovery. A network scan that sends probe packets to OT devices can disrupt controller timing, cause unexpected state changes, or trigger fault conditions on systems that were not designed to receive arbitrary network traffic. The IT security team that wants to know what devices are on the temporary TAR network cannot use their standard discovery tooling without risking the exact operational disruptions the TAR is trying to avoid.
The "IT Rules Don't Apply to OT" Gap Creates Ungoverned Network Spaces
Industrial facilities frequently operate with a cultural and organizational divide between IT (which manages corporate and business systems) and OT (which manages control systems and process automation). Temporary networks fall into the gap between these organizations: IT says the temporary TAR network is not their responsibility because it doesn't touch corporate systems; OT says it's not their responsibility because it's not a control system network. The result is a temporary network that is nobody's responsibility, governed by no policy, monitored by no team, and visible to no one — for the duration of the highest-risk operational period the facility experiences.
Incident Response Is Blind Without Network Visibility
When a cybersecurity incident is suspected during or after a turnaround — an unusual process event, anomalous data on a historian, a device that appears in OT network traffic that shouldn't be there — the first question incident responders ask is: what was on the network during the TAR? On a carrier LTE temporary network with no logging, the answer is: we don't know. There is no device inventory, no connection log, no record of what joined the network, when, or from where. The incident timeline cannot be reconstructed from the network record because no network record exists.
Regulatory and Audit Exposure From Ungoverned Temporary Networks
Industrial facilities subject to cybersecurity frameworks — NERC CIP for utilities, IEC 62443 for process industries, sector-specific regulations — face audit questions about network access controls, electronic security perimeters, and device inventories that extend to temporary operations. An auditor who asks how contractor network access was managed during the last major turnaround and receives "they used their own phones and we had a Wi-Fi hotspot in the site office" is looking at a finding, not a compliant answer. The documentation gap is both an audit exposure and a genuine security gap.
What Actually Works
A private 5G network deployed for industrial operations provides the architecture to address each of these problems — not through additional policy enforcement, but through network design that makes boundary enforcement structural rather than behavioral.
VLAN Segmentation That Enforces OT/IT Boundaries Architecturally
The private 5G network is deployed with a VLAN architecture that separates traffic into logical segments from day one: an operations VLAN for contractor work systems and permitted data applications, an OT VLAN for SCADA backhaul and industrial telemetry, a safety VLAN for worker safety devices and PTT, a management VLAN for network infrastructure, and an isolated guest segment if any broader access is required. Traffic between VLANs passes through defined access controls — the "conduits" in IEC 62443 terminology — not through unmanaged shared connectivity.
This segmentation is enforced at the network layer, not through policy documents that assume contractors follow rules under operational pressure. A contractor device on the operations VLAN cannot reach the OT VLAN regardless of what the contractor does or doesn't know about network security. The boundary is structural.
Managed Device Access — Only Provisioned Devices Join the Network
Every device that joins the private 5G network does so with a provisioned SIM credential. There is no open Wi-Fi SSID that any device can join; there is no shared password that a contractor can give to an unauthorized device. The network access list is the device list confirmed during pre-deployment planning — permits tablets, CMMS clients, safety wearables, and leased devices. Any device that is not on that list cannot join the network. This does not prevent contractors from using their personal phones on carrier LTE — it prevents those phones from joining the managed network and from being a lateral movement vector into systems the managed network touches.
Passive OT Asset Discovery — Visibility Without Disruption
The platform supports passive network monitoring on the OT VLAN — observing traffic that flows across the network segment without sending probe packets to OT devices. Passive discovery identifies devices that are communicating on the OT VLAN, builds a device inventory from observed traffic, and flags devices that appear on the OT VLAN that were not in the pre-deployment device list. It produces network visibility without the active scanning that disrupts industrial control systems.
For OT teams that want to understand what devices are present on the temporary network without risking controller disruption, passive monitoring during the temporary deployment provides a discovery capability that is not safely available on the live permanent OT network. The temporary network is a lower-risk environment to observe device behavior — it carries the devices provisioned to the operation, not the full suite of permanent OT infrastructure.
An Audit-Ready Device Inventory for the Duration of the Operation
The platform logs every device that joins the network — device identifier, VLAN assignment, connection timestamps, and data activity summary. This log is the device inventory that incident responders need and auditors ask about. At the end of the TAR or operation, the device inventory and connection log are available as a documented record of what was on the network, when, and in what configuration. The question "what was on the network during the TAR?" has a documented, timestamped answer.
Defined Integration Points Between Temporary and Permanent Networks
Where the operation requires connectivity between the temporary private network and the plant's permanent IT or OT systems — CMMS access from contractor tablets, SCADA backhaul for field instruments — those integration points are defined explicitly during pre-deployment scoping and implemented through specific, access-controlled paths. Not through open bridging between networks; not through a contractor's personal device; through a documented, access-controlled conduit that IT and OT both review and approve before the operation begins. The integration is deliberate, documented, and auditable.
Alignment With IEC 62443 Zones and Conduits Architecture
IEC 62443 — the international standard series for industrial automation and control system security — describes a "zones and conduits" architecture where OT networks are divided into security zones based on the criticality and risk profile of the systems they contain, and communication between zones is limited to defined conduits with documented access controls. The VLAN architecture of the private 5G network follows this framework: the OT VLAN is a defined zone, separated from the operations and guest VLANs; integration points to plant OT are defined conduits. Clover IQ does not provide IEC 62443 compliance assessment — that is the operator's domain with their security advisors — but the network architecture is designed to be compatible with it, not in conflict with it.
The Unit on Your Site
The Clover IQ Mobile Connectivity Unit delivers the network management and segmentation capabilities described above through the Telecom Core rack — the router/firewall, PoE switch, and network management infrastructure that form the backbone of the private 5G platform. Here is how the OT-specific capabilities are configured and operated.
Before the Unit Arrives: OT Architecture
VLAN design
The VLAN architecture is designed during the pre-deployment scoping call in coordination with the plant's IT and OT teams. The specific VLANs, their traffic policies, and the access controls between them are documented before the unit deploys. The IT team confirms the operations VLAN scope; the OT team confirms the OT VLAN scope and any integration points to permanent OT systems. Both teams receive the network architecture document before deployment begins — not after.
Integration point review
Any required connectivity between the temporary private network and plant IT or OT systems is explicitly reviewed and approved during pre-deployment planning. The path, the access controls, the data types permitted, and the logging requirements are documented for each integration point. Undocumented or ad-hoc connectivity between the temporary network and permanent systems is not supported by the platform architecture — it is not possible without deliberate reconfiguration.
Device provisioning list
The complete list of devices to be provisioned on the private network is confirmed during pre-deployment planning: SIM assignments, VLAN assignments, and device types. This list is the network access control policy — devices on the list can join; devices not on the list cannot. Any additions to the list during the operation are reviewed against the VLAN architecture before provisioning.
While the Operation Runs
Active monitoring
The Clover IQ operator monitors the network continuously during active operations — device connection status, traffic patterns, VLAN boundary integrity, and any anomalous activity flagged by the management stack. Unexpected devices that attempt to join the network are logged and flagged; unexpected traffic patterns across VLAN boundaries are reviewed.
Passive OT monitoring
On the OT VLAN, passive traffic observation runs throughout the operation, building the device inventory and flagging any devices observed that were not in the pre-deployment provisioning list. Observations are logged with timestamps. The OT team can review the passive monitoring log at any point during the operation — not just at closeout.
What You Get at Closeout
- Device inventory and connection log: Every device that connected to the private network, the VLAN it was assigned to, connection timestamps, and data activity summary.
- Network architecture document: As-deployed VLAN configuration, integration points, and access control policies — the documented record of how the temporary network was built.
- Anomaly log: Any devices that attempted to join the network but were not provisioned, any VLAN boundary violations observed, and their resolution.
- Demob confirmation: Documented confirmation that the temporary network has been decommissioned and that no persistent connectivity to plant systems remains.
What It's Worth
OT network segmentation and discovery ROI is a risk framing. The cost of an OT/IT boundary violation at an industrial facility — in incident response, operational disruption, and regulatory exposure — significantly exceeds the cost of the network architecture that prevents it. The figures below are illustrative. Validate against your facility's specific risk profile, regulatory environment, and incident history.
The Cost of an OT Cybersecurity Incident at an Industrial Facility
Illustrative scenario — OT network intrusion traced to TAR contractor connectivity
A post-TAR cybersecurity investigation identifies anomalous traffic on a historian network segment that began during the turnaround window. Incident response: forensic analysis of network logs (which don't exist for the carrier LTE segment), interviews with TAR contractor coordinators, review of CMMS and control system access logs. Timeline to root cause: 2–4 weeks of security team time. Direct incident response cost: $50,000–$200,000 depending on the scope of forensic work and whether external incident response support is engaged. If the anomalous traffic represents an actual intrusion rather than a benign misconfiguration: the investigation scope and cost expand significantly. With a documented private network device inventory and VLAN architecture: the same investigation uses actual network logs to answer the root cause question in hours rather than weeks.
Audit and Regulatory Exposure
Illustrative scenario — NERC CIP or IEC 62443 audit finding on temporary network access
An auditor reviewing a utility's CIP-005 Electronic Security Perimeter compliance asks how contractor network access during the last major maintenance window was controlled and documented. The answer "contractors used carrier LTE on their personal devices and we had a site-office Wi-Fi hotspot" results in an audit finding for uncontrolled electronic access to the ESP. NERC CIP violation findings carry penalty exposure of up to $1M per violation per day in serious cases; process industry IEC 62443 audit findings affect certification status and can have customer contract implications. A documented private network with VLAN segmentation, managed device access, and a post-operation network architecture document is a defensible answer to the same audit question.
Operational Value of Network Visibility
Illustrative scenario — unexplained process event during TAR
A process upset during a TAR is investigated as a potential equipment issue. As part of the investigation, the OT team asks whether any network activity could have contributed to a controller state change. On a carrier LTE temporary network: no network log exists, the question cannot be answered from network evidence, and the investigation cannot rule out a network-caused event without eliminating every other cause. On the private network with passive OT monitoring and VLAN logging: the OT VLAN traffic log from the relevant time window is available within minutes. The network-caused event hypothesis is confirmed or eliminated from evidence, not from elimination of alternatives.
Questions from the Field
What is the practical difference between IT and OT security requirements on a temporary network?
IT security requirements on a temporary network are similar to those on any enterprise network: managed device access, traffic encryption, logging, and defined perimeter controls. OT security requirements add a layer that IT security teams may not be accustomed to: OT devices (PLCs, RTUs, controllers) cannot be treated like IT endpoints — they have strict timing requirements, limited processing capacity for non-operational traffic, and cannot be patched or updated on a normal IT schedule. The practical consequence is that OT traffic must be on a logically isolated segment that IT scanning tools, management traffic, and contractor data applications cannot reach — and that the OT VLAN itself must be monitored passively, not actively probed. These requirements are not more complex in a private 5G deployment than in any other network architecture; they are simply explicit in the VLAN design rather than implicit in physical separation.
Can the platform perform passive OT asset discovery without active scanning?
Yes. Passive monitoring observes traffic that is already flowing on the OT VLAN without sending probe packets to OT devices. Devices are identified from the traffic they generate — ARP broadcasts, protocol-specific handshakes, data flows to the SCADA backhaul path — not from active interrogation. The device inventory produced by passive monitoring reflects devices that are actively communicating on the OT VLAN, which is the relevant population for a temporary operational deployment. Devices that are powered down or not communicating during the observation window will not appear in the passive inventory — that limitation applies to passive discovery generally and is not specific to this platform.
How does the VLAN architecture align with IEC 62443 zones and conduits?
IEC 62443 describes security zones as groupings of assets with similar security requirements, and conduits as the defined communication paths between zones with documented access controls. The private network VLAN architecture maps directly to this framework: each VLAN is a zone with a defined device population and traffic policy; inter-VLAN access controls are the conduits. Clover IQ does not provide IEC 62443 compliance certification or assessment — those are performed by qualified third-party assessors working with the operator. What we can say is that the network architecture is designed to be compatible with the zones-and-conduits framework, and that the pre-deployment architecture documentation provides the basis for the compliance record that assessors will ask for.
What happens to the network logs and device inventory after the operation ends?
The device inventory and connection logs are delivered to the operator as part of the post-operation deliverables — in a format suitable for retention in the operator's security documentation. Clover IQ retains operational logs for a defined period per our data handling policy; the operator receives the relevant records for their own retention. For operations subject to regulatory data retention requirements, the retention period and format for network logs should be specified in the engagement agreement, not assumed at demob.
Can the temporary private network integrate with our permanent OT security monitoring platform?
Integration between the temporary private network's monitoring and a permanent OT security platform — a network security monitoring system, an industrial intrusion detection platform, or a SIEM — is possible through a defined integration point reviewed during pre-deployment scoping. The integration path, data types shared, and access controls are documented in the pre-deployment network architecture. This is not a default configuration — it requires explicit scoping with both the operator's OT security team and the permanent platform's access requirements. For facilities that operate a mature OT security monitoring program, feeding the temporary network's monitoring data into the existing platform extends visibility during the TAR without requiring a separate monitoring workflow.
Straight Talk
OT/IT convergence leads and industrial cybersecurity professionals are working in an environment where the security guidance is clear — zones and conduits, managed device access, no active scanning on OT networks — and the operational reality during major events like TARs is that none of that guidance is being followed because nobody took ownership of temporary network security.
The value of a private 5G network for OT security is not primarily in the technology. It is in the fact that someone is responsible for the temporary network architecture. When the TAR network is carrier LTE on contractor personal devices, OT security is nobody's responsibility during the most operationally dense period the facility experiences. When the TAR network is a private 5G deployment with a defined VLAN architecture, managed device access, and a Clover IQ operator monitoring it — someone owns the network, the architecture is documented, and there is a record of what was on it.
The Architecture Document Is as Valuable as the Network
The pre-deployment network architecture document — VLAN design, device list, integration points, access controls — is not a formality. It is the document that the IT team, the OT team, and the auditor all review before the TAR starts and reference when something unexpected happens during it. Producing that document forces the cross-functional conversation between IT and OT that temporary network deployments typically skip. That conversation — who owns each VLAN, what integration points are permitted, what the demob process looks like — is where the boundary violations that happen during TARs are prevented.
We Are Not an OT Cybersecurity Firm
Clover IQ is a systems integrator — we design and deploy industrial wireless networks. We are not an OT cybersecurity assessment firm, we do not provide IEC 62443 compliance certification, and we do not offer industrial intrusion detection or OT-specific security monitoring beyond the network visibility the platform provides. For facilities that need a full OT cybersecurity program — asset management, vulnerability assessment, incident response planning, compliance documentation — that work belongs with qualified industrial cybersecurity specialists. What we provide is a network architecture that supports rather than undermines those programs, and operational documentation that security teams and auditors can work from.
When the Carrier LTE Approach Is a Calculated Risk
For turnarounds and operations at facilities with no OT network connectivity requirements for the temporary workforce, no regulatory cybersecurity obligations, and robust physical security that limits contractor device access to non-critical areas, carrier LTE may represent an acceptable risk rather than an ungoverned exposure. That determination belongs to the facility's security and operations teams. The Clover IQ scoping call is where we understand the actual requirements — if the OT boundary and network governance requirements described in this blog don't apply to your operation, we'll scope accordingly rather than oversell the security architecture.
Start the conversation with your IT/OT team and us together. The pre-deployment architecture review works best when the plant IT lead, the OT lead, and Clover IQ are in the same scoping call — not when we scope with one team and the other discovers the network design after deployment.
