March 2026 · 7 min read

​

When an abnormal situation occurs in a production network, the first challenge is not how to respond. It is that there is no clear understanding of what actually happened.

​

Not where it started. Not which assets were involved. Not whether it is still happening.

​

In industrial environments, this is where the most serious consequences occur. Not because organisations lack effort or investment, but because the visibility required to answer those questions was never established.

​​

​

The assumption at the core of most OT security programmes

​

Industrial environments have been secured, predominantly, at the perimeter. Firewalls, segmentation, and controlled remote access remain essential. In normal conditions, they work.

​

But perimeter controls rest on an assumption: that if you control what enters and exits, you control the risk. That assumption breaks in two specific ways.

​

First, perimeters can be bypassed. A misconfigured remote access path, a vendor connection that remained open, an IT–OT interface that was never fully understood: these are the documented entry points in the majority of significant OT incidents.

​

Second, conditions inside the network change regardless. Devices age, configurations drift, connections form between systems never intended to communicate. In many environments, no one has a current and accurate picture of what is actually running, what it is doing, and what it is connected to. When an incident occurs, the organisation is not managing a known situation. It is discovering one.

​​

​

What visibility actually means in an OT context

 

Visibility is not an asset list populated two years ago. Not a network diagram drawn at commissioning. Not a SIEM ingesting syslog from the IT boundary.

​

In OT, meaningful visibility means a continuous, current understanding of:

 

• Which devices exist in the production network, including those never formally documented

• How those devices communicate, what industrial protocols they speak, and what those exchanges represent

• What the actual software versions and configurations of process control devices are, not what they are assumed to be

• Which connections extend beyond the production network, and whether they behave as expected

• What normal looks like, so deviations are detectable before they become incidents

​

That last point is the operational pivot. Without a defined baseline, every anomaly requires human judgment from scratch. With it, deviations surface automatically. The question shifts from did something happen to what exactly happened and what does it mean for this process.

​​

​

Why industrial environments make this harder

 

Establishing visibility in IT is well understood. Agents can be deployed, active scanning is acceptable, logs are centralised. OT environments permit almost none of that.

​

Possible legacy devices such as PLCs, RTUs, and HMIs often have a limited logging capability. Active scanning can cause unexpected behaviour in devices never designed for that traffic. In a production environment, the risk of disrupting a process is not abstract. It has direct consequences for safety, availability, and in regulated industries, compliance.

​

This is not an obstacle to work around. It is a defining constraint that shapes how visibility must be established.

​

Passive observation over active interrogation

Traffic analysis using industrial protocol-aware inspection, understanding Profinet, Modbus, EtherNet/IP and OPC-UA natively, provides a detailed picture of network behaviour without generating a single packet that could affect the process.

​​​​

Protocol-native asset discovery

When a PLC is identified by observing its own protocol traffic rather than by sending a probe, the identification is accurate and the process is undisturbed. Firmware versions, configuration states, and communication patterns surface without risk.​​

​

Topology-aware deployment

In ring topologies, mirror ports, and air-gapped segments, where traffic is captured matters enormously. Getting this wrong means blind spots. Getting it right means complete coverage without touching a single production device.​​

​

The difference between a solution designed for IT networks and one built for OT becomes apparent the moment it is deployed.

​​

​

From visibility to decisions

 

When a PLC begins communicating with a device it never has before, that is observable if visibility exists. When a firmware version changes outside a maintenance window, that is detectable. When a remote connection that should have closed 48 hours ago is still active, that is visible.

​

None of those situations are automatically emergencies. In an industrial environment, every response must be evaluated against production continuity, process criticality, and safety constraints. You cannot isolate a device the way you might in IT. The consequences of getting that wrong can be physical.

​

But the ability to evaluate those situations, to make an informed decision about what is safe to do and in what sequence, depends entirely on having an accurate picture of what is actually happening. Without it, decisions are made on assumptions, under pressure, with incomplete information. That is where mistakes happen.

​

With visibility, an anomaly is detected. Its scope is understood. Affected assets are identified with precision. A response can be planned that accounts for what the process can tolerate, not just what a generic playbook prescribes.

​​

​

​

​

​

​​​​

​

A question worth asking directly

 

If an abnormal situation occurred in your production network today, say unexpected traffic, an unfamiliar connection, or a device behaving outside normal parameters, could you answer these with confidence?

​

• Which assets are involved?

• When did the behaviour begin?

• Is it still active?

• What is the likely cause?

• What is safe to do about it, given your process constraints?

​

If the honest answer to any of those is I don't know or it would take us significant time to find out, that is not a gap in your response capability. It is a gap in your visibility.

​​​​

​

What we consistently find in Finnish industrial environments

 

Across manufacturing, energy, and critical infrastructure in Finland, one pattern repeats itself more than any other when visibility is first established: the asset inventory is wrong.

​

Not slightly wrong. Significantly wrong.

​

Devices appear that no one expected: equipment connected years ago during a project, a vendor's maintenance laptop that never left the network, a legacy PLC that was supposed to have been decommissioned. In several cases, organisations have discovered active devices they could not immediately attribute to any known system or vendor.

​

This is not a reflection of negligence. It is a reflection of how industrial environments actually evolve: incrementally, across years, across teams, across projects that each made local decisions without a complete picture of the whole. The documentation never kept up because no one had a reliable way to make it keep up.

​

When those organisations saw their network for the first time as it actually was, not as it was assumed to be, the reaction was consistent. Not panic. Recognition. And then the immediate question: how long has this been the case?

​

That question is the beginning of a security programme built on reality rather than assumption.​​​