The short answer
OT Security vs IT Security
In information technology, the usual priority order is confidentiality, then integrity, then availability. In operational technology it inverts: safety first, then availability and integrity, with confidentiality last. A control system that stops running can flood a neighborhood or injure someone, so controls that are routine in IT, such as automatic patching and active scanning, require far more caution in OT.
Key points
- Safety and availability outrank confidentiality on a control network.
- Systems run for years without reboot, and patch windows may be annual or rarer.
- Active scanning can crash legacy control devices; passive discovery is preferred.
- Equipment lifecycle is fifteen to twenty-five years, so unsupported software is normal, not exceptional.
- Compensating controls carry most of the load where patching is impossible.
The inversion
An IT team protecting a records system reasons about disclosure first. Losing confidentiality is the catastrophe; a server rebooting is an inconvenience. On a control network the calculation is different, because the system is connected to equipment that moves, heats, and pressurizes things in the physical world.
Nobody is much harmed by learning the wet well level at a lift station. A controller that stops responding during a storm event is a sanitary sewer overflow, a regulatory report, and a public health problem. Safety comes first, availability follows, and confidentiality is genuinely last for most process data.
Practical differences
| Topic | IT practice | OT reality |
|---|---|---|
| Patching | Frequent, often automatic | Scheduled outages, vendor validation, sometimes annual or less |
| Uptime expectation | Rebooting is routine | Years of continuous operation; a reboot is an event |
| Equipment lifespan | Three to five years | Fifteen to twenty-five years |
| Vulnerability scanning | Active scanning is standard | Active scanning has crashed production controllers; prefer passive |
| Authentication | Individual accounts, MFA | Shared operator accounts are common and hard to remove safely |
| Antivirus | Standard on endpoints | Often unsupported by the control vendor; may interfere with real-time operation |
| Encryption | Broadly applied | Many control protocols have no encryption capability at all |
| Incident response | Isolate and rebuild | Isolating may mean losing control of a physical process |
What actually protects a control system
Where patching is constrained, the controls that carry the load are architectural and procedural rather than software updates.
- 01Segmentation. Separate the control network from the business network with a controlled boundary. This single measure prevents more incidents than any other.
- 02Controlled remote access. No direct inbound paths to control devices. Vendor access is brokered, authenticated with multi-factor, time-limited, and logged.
- 03Tested backups. Controller programs, HMI applications, server images, and network device configurations, stored offline, and restored on a test bench at least once so you know the restore works.
- 04Asset inventory. A current list of what is on the network, with firmware versions, so an advisory can be assessed in minutes rather than weeks.
- 05Removing default credentials. Still the most common finding in every assessment of every sector.
- 06Monitoring. Knowing what normal traffic looks like, so abnormal is visible.
- 07Physical security. A panel that anyone can open is not protected by any amount of network engineering.
Where IT and OT have to meet
The most common organizational failure is not technical. It is an IT department applying enterprise policy to plant equipment without understanding the process, or an operations group treating the control network as nobody else business until something happens.
- IT usually owns the network expertise, the identity systems, and the monitoring tooling. Those are genuinely needed.
- Operations owns the process knowledge and the consequence of downtime. Only they can say what a control can safely do.
- The boundary between the networks needs a named owner, agreed rules, and a change process both sides follow.
- Every OT security decision should be able to answer one question: what happens to the process if this control fails or misfires?
Frequently asked questions
- Should OT and IT networks be completely separated?
- Physically air-gapped networks are rare and often less secure in practice, because data still moves by USB drive and remote support still happens, just without controls. A segmented architecture with a controlled, monitored boundary is the realistic and generally recommended approach.
- Can I run antivirus on an HMI or SCADA server?
- Sometimes, and only with the control vendor guidance on exclusions and versions. Real-time process software has been disrupted by on-access scanning. Application allowlisting is often a better fit for a machine whose software set never changes.
- How do we handle an unsupported operating system on a control workstation?
- Treat it as unfixable and wrap it: strict segmentation, no internet path, no email or browsing, removable media controls, tight firewall rules, and monitoring. Then plan its replacement with a real budget line rather than an intention.
- Who should own OT cybersecurity?
- It has to be shared, with a single accountable owner named. The failure mode is a gap where IT assumes operations handles the plant network and operations assumes IT handles security. Write down who owns the boundary.
Related topics
- The Purdue ModelThe reference architecture most segmentation designs still start from: what each level contains, where the DMZ goes, and how it maps to a water utility.
- Zones and ConduitsThe IEC 62443 way to segment a control system: grouping assets into zones with a shared security level, inventorying every conduit between them, and turning the drawing into firewall rules. With a worked water utility example.
- Vendor Remote AccessIntegrators and equipment vendors need to get in. How to let them without leaving a permanent door open: utility-controlled sessions, named accounts, MFA, a jump host, session recording, and what to do about the modem you did not know was there.
- What to Back Up in a Control SystemWhat a utility must be able to restore after a failure or attack: controller programs and firmware, SCADA and historian, HMI panels, drive and instrument parameters, network configurations, licenses, installers, and documentation, and how often each changes.
- IEC 62443The international standard series for industrial automation and control system security: how it is organized, what security levels and foundational requirements mean, and how a utility or integrator actually uses it.
- OT Risk AssessmentRanking what could go wrong in a control system and what it would cost: the consequence-first method for utilities, the assets and scenarios to list, likelihood without pretending to know it, the risk matrix, and turning the ranked list into a work plan.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.