IT vs OT Security: Why Your Enterprise Firewall Isn't Enough
Most industrial operators assume the security stack that protects the corporate network will extend naturally to the plant floor. It won't — and the assumptions behind enterprise security are the exact reason it fails in OT environments.
Walk into any critical-infrastructure site that's had a breach in the last few years, and the story tends to start the same way. Corporate IT had a mature security program. Endpoints were patched. There was an EDR agent on every laptop. Logs flowed to a SIEM. By every enterprise yardstick, the organization was doing the right things.
Then something got into the plant network — and suddenly none of it mattered.
This isn't a failure of IT security teams. It's a failure of assumptions. The security stack that protects the corporate network was designed around a very different set of priorities than the ones that govern the plant floor. Treating the two environments as if they were the same is how incidents escalate from nuisances into unplanned shutdowns.
The priorities are inverted
In IT, the classic security triad is confidentiality, integrity, availability — usually in that order. Losing data is the worst outcome. A laptop can be reimaged. A SaaS account can be rotated. Brief downtime for a patch window is a mild inconvenience.
In OT, the triad flips: availability, integrity, confidentiality. The reactor has to keep running. The pumps have to keep pumping. The SCADA view that the operator depends on has to be accurate in real time. An attacker stealing process recipes is bad — an attacker causing a shutdown is catastrophic, and an attacker quietly corrupting sensor data is worse still.
Every tool, process, and policy that works in an IT environment was built around the first triad. Drop it into an OT environment and the mismatch shows up fast.
Where enterprise tools break
A few of the most common failure modes we see when corporate security extends naively into the plant:
Agent installs on legacy endpoints. The HMI driving a production line might be running an operating system that went out of support a decade ago. The vendor's warranty is void the moment you install anything on it. Your EDR agent isn't going there — and if you force it, you're the one who owns the next unplanned outage.
Active vulnerability scanning on live process networks. A standard network scan that's routine on the corporate LAN can crash a programmable logic controller. PLCs were not designed to gracefully reject malformed packets — many were designed with the assumption that no one hostile would ever talk to them. "Just scan it" is how you end up writing an incident report instead of a finding.
Patch windows that don't exist. The corporate side has monthly Patch Tuesdays. The plant has a scheduled shutdown every eighteen months, if you're lucky. The math of "apply this critical patch within 30 days" does not survive contact with a continuous process.
MFA in front of a process alarm. It's easy to forget that the operator staring at a SCADA screen at 3 a.m. may need to make a decision in seconds to prevent something very expensive from breaking. A login flow that makes sense for a finance analyst is a safety hazard in a control room.
None of these are edge cases. They are the normal, predictable consequences of applying IT controls to OT assets without translating them first.
What actually works
A real OT security program doesn't look like a smaller version of the IT program. It looks like a different program that shares vocabulary.
Passive first. Before you touch anything on the process network, you listen to it. Passive monitoring tells you what's there, what's talking to what, and what normal looks like — without injecting a single packet into traffic that controls physical equipment.
Segmentation that follows the process, not the org chart. Zones and conduits aligned to actual process boundaries, reviewed by the people who understand what each asset does, not just where it sits on the network diagram. The goal isn't to stop lateral movement in the abstract — it's to make sure a compromise in one cell can't propagate into another cell that controls something dangerous.
Asset inventory as a living document. You cannot protect what you cannot see. In OT that inventory is harder to build than in IT — assets are often decades old, rarely inventoried in any modern CMDB, and frequently owned by process engineers rather than IT. Building the inventory is usually where a credible program starts.
Change control that respects process safety. Security changes in OT go through the same rigor as any other engineering change on the plant. That's slower than IT teams are used to, and that's the point.
The short version
If your security program treats the plant floor as "the network with the weird stuff on it," you do not have an OT security program. You have an IT security program with blind spots shaped like your most important assets.
The organizations getting this right aren't the ones with the biggest budgets. They're the ones who stopped trying to make the plant look like the office, and started asking what the plant actually needs. That's a harder conversation — and it's the right one.
If you're in the middle of that conversation and want a second set of eyes from a team that lives in OT every day, we'd be glad to help.