OT Security for Industrial Facilities — Why the IT Playbook Doesn't Transfer
Why IT security methods fail in a plant — from Modbus having no auth to PLCs that can't be patched, with real zcrOT examples and where to actually start.
OT Security for Industrial Facilities — Why the IT Playbook Doesn't Transfer
Picture yourself running IT at a manufacturing plant. Security sends over a report: critical vulnerability found on one of your devices, patch it within 48 hours. You look it up and find the device is a PLC controlling the main production line. Patching it means stopping the line — and the next scheduled shutdown is in October.
This is where IT security thinking runs out of road, and it's why OT security needs an approach of its own.
What actually makes OT different
The difference isn't only technological. It's that OT operates under a completely different set of constraints.
On patching. In IT, an update ships and you apply it. In OT, you wait for a maintenance window when equipment can safely stop — at some plants that comes once a year. A vulnerability sitting unpatched for eight months isn't negligence; it's a real production constraint.
On authentication. Modbus, the most widely deployed industrial protocol, was designed in 1979 when the working assumption was a closed, physically isolated network. So the protocol has no built-in authentication. Anyone who can put a command on the network can issue that command.
On scanning. The active vulnerability scanners that are routine in IT can genuinely hang certain PLC models. These devices were built to handle predictable traffic patterns, not unexpected probes.
On impact. An IT breach means data loss and reputational damage. An OT breach means the production line stops, with losses measured by the hour.
It's this specific combination of constraints that makes passive monitoring a better first layer for OT than the patch-and-scan cycle that works in IT.
So if you can't patch and can't scan, what can you do?
Start by seeing everything. If you don't yet know what's talking to what on your OT network, defending it is premature.
Passive monitoring means observing traffic that's already flowing without injecting anything into the network. You learn which device talks to which, over what protocol, at what times.
Once you have a baseline, the abnormal starts standing out on its own.
What the zcrOT Security Exposure page shows
The Security Exposure page of the zcrOT demo sums up a time window in four measures: all security events, the high and critical ones, events from clients that are not yet mapped to a known device, and a behavioral verdict on whether the pattern looks like an attack. Next to the verdict, the system says whether the events fell inside or outside business hours. The demo runs on simulated data, so it shows what the view looks like, not a measurement from a real plant.
The interesting part isn't the numbers. It's the phrase "outside business hours." In a plant where normal shift patterns are known, OT traffic appearing at 2 AM carries different weight than the same traffic at 2 PM. That context is something a general-purpose IT security tool doesn't have, and a purpose-built OT platform does.
Signs your facility should start on OT security
- You can't say how many devices are currently connected to the OT network
- External contractors can perform remote maintenance, but there's no record of when they actually connect
- The OT network touches the office network somewhere, and you're not certain where
- Devices are running years-old firmware because updating them isn't practical
If more than one of those lands, the highest-value starting point is visibility — not buying another protective tool, because you don't yet know what you're protecting.
For how raw traffic becomes an investigable incident, read How OT Detection Rules Work. For what these kinds of incident look like, see 4 OT Incident Types.
How zcrOT approaches this
zcrOT is an OT visibility platform that monitors passively through dedicated syslog ports, sending nothing into the network that could disturb equipment on the line. It pairs that with a detection-rule engine you write conditions for yourself, and an incident view that groups related events with a risk score.
To see what's visible on your own OT network, look at zcrOT plans or open the demo first.
Get in touch
Want to know what's currently invisible on your plant's OT network? Talk to our team — the consultation is free.
Sources
- Modbus Organization — Introduction to Modbus — confirms Modbus was designed by Modicon in 1979 for closed networks, and has no built-in authentication mechanism
- NIST SP 800-82 Rev. 3 — Guide to Operational Technology (OT) Security — supports the OT constraints described in the article, including the risk that routine active scanners can hang certain PLC models