5 OT security mistakes that leave industrial networks expose

Manufacturing plants, energy facilities, and logistics hubs are under growing pressure to connect operational technology (OT) to corporate IT networks. The business case is clear: real-time data from the shop floor feeds better decisions, faster maintenance cycles, and leaner operations. The security risk, however, is equally real and frequently underestimated.

Unlike IT environments, OT networks were designed for availability and determinism, not confidentiality. Patching a PLC mid-shift is not the same as updating a laptop. Downtime is measured in tonnes, not help desk tickets. These constraints make OT environments structurally harder to secure, and they explain why threat actors increasingly target them.

The following five mistakes appear repeatedly in industrial environments that have suffered breaches or near-misses. Avoiding them does not require replacing every asset on the floor. It does require deliberate architecture choices at the point where OT data first crosses into the IT domain.

1. Running industrial protocols without encryption or authentication

Modbus, DNP3, and older variants of OPC DA were designed in an era when air-gapping was the assumed security model. They carry no native authentication and transmit data in plaintext. Once a network is connected to corporate infrastructure or the cloud, even indirectly, those properties become liabilities.

The shift to OPC UA as a transport layer addresses both problems. OPC UA supports certificate-based authentication and TLS-encrypted sessions at the protocol level, without requiring application-layer workarounds. Environments that continue to use legacy protocols on connected segments without compensating controls are accepting a risk that is both well-documented and avoidable.

Industrial connectivity platforms play a critical role here. A properly configured connectivity server sits between field devices and the IT network, translating legacy protocols into authenticated, encrypted sessions before data leaves the OT zone. Selecting and hardening that layer is one of the highest-leverage security decisions an OT engineer can make. Kepware is among the most widely deployed platforms in this role, and its configuration, particularly around OPC UA security policies and user authentication, deserves the same scrutiny as any network appliance.

2. Flat networks with no segmentation between OT zones

A flat OT network means that any device that can communicate with one asset can, in principle, communicate with all of them. This is the architecture that allowed the 2021 Oldsmar water treatment incident to proceed as far as it did: an attacker with access to one workstation had unobstructed reach to the SCADA interface controlling chemical dosing.

The IEC 62443 standard and the Purdue Model both recommend segmenting OT networks into zones based on criticality and function, with conduits controlling traffic between them. In practice, this means firewalls or industrial DMZs separating Level 1 (field devices) from Level 2 (supervisory control) and Level 3 (operations management), with explicit whitelisting of permitted communication paths.

Segmentation is not a one-time project. As new data flows are added, whether historian replication, cloud telemetry, or remote access for vendors, each one represents a new conduit that must be assessed and controlled.

3. Vendor remote access left permanently open

Many industrial installations were commissioned with always-on remote access configured for the OEM or system integrator. VNC ports left exposed, RDP enabled on engineering workstations, or jump servers with shared credentials that were never rotated after handover.

This is one of the most common initial access vectors in OT incidents. Attackers do not need to compromise the plant network directly if a maintenance pathway is perpetually open on a publicly routable address.

The corrective pattern is well established: replace permanent connectivity with session-initiated, time-limited access. Solutions based on encrypted tunnels that are broker-mediated and require explicit approval for each session eliminate the persistent exposure while preserving vendor support capability. Multi-factor authentication on every remote access pathway to OT systems is non-negotiable.

4. No asset inventory, so no baseline for anomaly detection

You cannot detect abnormal behaviour on a network you have not enumerated. Many OT environments lack a current, complete inventory of connected assets, partly because devices are added incrementally over years, partly because legacy controllers do not respond to standard discovery probes, and partly because the task is perceived as a one-off exercise rather than a continuous process.

Without a baseline, intrusion detection systems have no reference point. Traffic that looks unusual to a human analyst looks indistinguishable from normal operations to a tool that has never seen normal operations.

Passive network monitoring tools designed for OT, those that observe traffic without generating queries that could disturb sensitive controllers, can build asset inventories automatically. Platforms such as Claroty, Nozomi Networks, and Dragos are designed precisely for this. The output is both a security asset and a compliance asset: NIS2 requires organisations classified as essential or important entities to maintain documented risk assessments of their OT environments. If you are unsure whether your organisation falls within scope, the NIS2 OT Security Check provides a structured starting point for assessing your classification and readiness.

5. Treating OT security as an IT responsibility alone

The most persistent structural mistake is organisational rather than technical. IT security teams understand firewalls, endpoint detection, and identity management. They typically do not understand the operational constraints of a DCS, the implications of a watchdog timeout on a safety-instrumented system, or why a patch that is trivial to deploy on a Windows server may be untestable on a controller running a 15-year-old firmware version.

When OT security is delegated entirely to the IT security function, the result is either inappropriate controls that create availability risk on the floor, or a stalemate where nothing is implemented because the IT team lacks the authority to act without OT sign-off and the OT team lacks the remit to act at all.

Effective OT security requires a joint model: IT security brings the threat intelligence, tooling, and governance frameworks; OT engineering brings process knowledge, safety constraints, and the authority to implement changes on the floor. The programme needs a named owner who sits at the intersection of both functions, and executive sponsorship that treats OT security as a business continuity issue, not a technology project.

Where to start

Organisations without a formal OT security programme rarely need to address all five areas simultaneously. A pragmatic starting point is a network architecture review: map what is connected, identify where OT traffic crosses into IT or cloud infrastructure, and assess the security posture of those crossing points.

The connectivity layer, the servers and gateways that aggregate data from field devices and expose it northbound, is almost always the highest-priority finding. Locking down that layer, enforcing authenticated and encrypted protocols, and ensuring it is appropriately segmented from both the field network and the IT network addresses the largest share of realistic attack surface in most industrial environments.

The remaining items, vendor access controls, asset inventory, anomaly detection, and governance structure, can be sequenced over a programme of six to twelve months without requiring production downtime or capital expenditure on new control hardware.