CONTRIBUTED ARTICLE

OT Security: Check the Field Conditions Before the Solution

Successful OT security starts with understanding the environment, not just selecting a product

Kyungkuk Park, Principal Engineer and TS Team Lead, COONTEC

Ransomware and supply chain attacks have extended into industrial control environments, and awareness of the need for OT security is rising rapidly. Security frameworks such as IEC 62443 and the NIST Cybersecurity Framework 2.0 are also becoming more sophisticated.

Across manufacturing, energy, and power sectors, many industrial organizations are now asking the same question: where should OT security begin? On paper, the process appears straightforward—identify assets, segment the network, establish monitoring, and then respond to anomalies.

In the field, however, the reality is different. Even when projects follow the manual, unexpected issues arise, and tasks that appear technically simple often lead to schedule delays or operational disruption.

The difficulty of OT security does not stem from a lack of technology. It stems from the fact that OT environments were originally designed for operational continuity, not security. Methods that work in IT do not translate directly into the OT field.

In other words, the environment—not just the technology—must be considered first. The following five on-site conditions are among the most common obstacles to OT security adoption.

1. Legacy equipment that cannot support agent-based security solutions

A significant portion of field equipment—including PLCs, HMIs, and SCADA systems—remains in operation for 10 to 20 years or longer. Some systems still run legacy operating systems or are no longer covered by vendor maintenance.

In such environments, installing agent-based security solutions is often impractical. Installation itself may affect performance or void vendor maintenance guarantees.

2. Environments where production downtime is not allowed

In plants that run 24/7/365, the time available to install security equipment or change network settings is extremely limited.

Even the one or two planned maintenance windows available each year are often already filled with equipment servicing, calibration, and external vendor work.

3. Mismatches between documentation and the actual network

Network documentation is another major variable in OT security. On paper, switch and port structures may look clear, but in the field, equipment may have been replaced or undocumented devices may have been added.

In some cases, a security deployment was designed based on the network diagram, only for the project team to find on-site that a target switch had been replaced by a dummy hub that could not support SPAN configuration, or that all ports were already occupied and mirroring was impossible. The design had to be revisited and the schedule slipped.

Even a single configuration detail can affect detection quality. Configuring a SPAN port is not enough by itself. If a switch is set for one-way mirroring, for example, only partial traffic may be captured. In OT security, it is not enough to confirm that a setting exists—the direction of the setting and the quality of collected data must also be verified.

4. Different priorities across teams

Security teams typically prioritize threat detection, while operations teams prioritize preventing production stoppages. This gap often remains even after a solution has been deployed.

In one case, hundreds of alerts remained unreviewed six months after implementation. The IT security team had difficulty interpreting what those alerts meant in the context of plant operations, while the OT operations team had not received sufficient training to interpret the security console.

As a result, no one regarded the alerts as part of their job. A security solution is only a tool. Unless there is a clear guideline for who reviews alerts, how they are interpreted, and what response procedure is followed, the system will not function effectively.

5. Constraints created by vendor contracts

Maintenance contracts for industrial equipment often include clauses such as “any configuration change without prior approval voids the warranty.”

In one facility, even the simple act of opening a switch port for traffic mirroring required a lengthy vendor approval process. A technically minor task ended up determining the overall project schedule because of contractual constraints.

Five on-site conditions that make OT security adoption difficult (Source: COONTEC)

Why OT security is often perceived as risky—and how to address it

One of the biggest risks during deployment appears when IT-style security methods are applied directly to OT environments. Many OT protocols are designed around millisecond-level response times and predictable communication patterns. A delay that seems negligible in IT can be interpreted as a process anomaly in OT.

For example, there have been cases where a production line stopped after a security device was inserted inline to strengthen blocking functions and the timing between PLC and HMI communications was disrupted.

These experiences create the perception that “introducing security may stop the facility.” But this is not a limitation of OT security itself. It is a risk created when active, inline approaches designed for IT are applied to OT without adaptation.

From an OT security perspective, passive monitoring—copying and analyzing traffic without interfering with the operational network—should be the default approach. At the same time, passive monitoring alone is not enough. Baseline learning is needed so the system can distinguish abnormal activity from normal communication patterns.

If too many false positives and alerts appear at the beginning, the operations team may lose trust in the system and overlook real threats. A baseline-learning period of at least two to four weeks, followed by alert prioritization and tuning, is a core operational requirement.

Field conditions come before solutions

OT security should begin by checking field conditions before choosing a solution. Organizations need to assess the ratio of legacy equipment, available maintenance windows, the accuracy of network diagrams, the collaboration channel between IT and OT, and contractual restrictions on configuration changes.

At the design stage, on-site inspections should take priority over documents. After deployment, baseline learning and alert operations must be established together.

The goal of OT security is not simply to install security equipment. It is to visualize previously unseen assets and communications without interrupting operations, and to build a system that can detect and respond to anomalies in a way the field can understand.

Ultimately, OT security is not completed by a product alone. It must be designed together with site surveys, network verification, cross-functional collaboration, baseline learning, and alert tuning.

Since 2019, COONTEC has served as the official Korean partner of Claroty, a global industrial cybersecurity platform, providing OT and ICS security consulting, deployment, and operational support tailored to industrial environments. Based on deep packet inspection (DPI), COONTEC supports asset identification, communication pattern analysis, detection of known and unknown threats, and abnormal behavior—strengthening security without compromising productivity.