IT vs OT: Why Traditional Cybersecurity Doesn't Just Transfer

The single biggest mistake an experienced IT security professional makes on their first OT project is assuming the same instincts apply. They mostly do not, and understanding why is the foundation of every good OT security decision that follows. In IT, patching quickly is almost always the right default response to a vulnerability. In OT, patching a controller that has been running a specific firmware version for eight years, validated against a specific safety case, can introduce more operational risk than the vulnerability itself -- an untested patch that causes an unplanned outage in a live process can be far more damaging than a theoretical exploit that has never been seen against that asset. This is why OT patching decisions are usually made jointly with process engineers, on planned maintenance windows, after compatibility testing -- not pushed automatically overnight. In IT, rebooting a server to apply a fix is routine. In OT, rebooting a controller can mean a physical process stops -- a pump, a valve, a signal -- and depending on the system, that can have safety consequences, not just downtime cost. Availability requirements in OT are often measured in the ability to run continuously for years, not the ability to tolerate brief planned outages. In IT, replacing an asset every three to five years is normal. In OT, a PLC or an RTU might run for two or three decades, which means many OT environments are permanently running systems that will never receive a vendor security update again -- making network-level compensating controls (segmentation, monitoring, strict access control) far more important than patch management as a primary defense.