OT vs IT Security: The Real Differences That Matter

NIST SP 800-82 Revision 3 frames OT security as a discipline that shares tools and terminology with IT security but must be adapted for environments where availability, safety and physical consequence take precedence over data confidentiality. The table below summarises the highest-level distinctions covered in this explainer.

IT security commonly follows the confidentiality, integrity, availability ranking. OT security inverts this, placing availability first because the unavailability of a control system can mean loss of control over a physical process, which can create a safety event rather than a purely commercial one.

IT hardware and operating systems typically refresh on a three to five year cycle, aligned with vendor support lifecycles. OT assets are commonly specified to run for fifteen to thirty years, often on operating systems that reached end of vendor support long before the equipment is retired.

This longevity means OT change control is inherently more conservative. A change that would be routine in IT, such as installing a security update, requires engineering sign-off in OT because it may interact with control logic, timing or safety interlocks that were validated against the original, unpatched configuration.

Patch management is one of the clearest points of divergence. IT patching is frequent, often automated, and designed around minimising the window of exposure to a known vulnerability. OT patching is infrequent, manual, and designed around minimising the risk of an untested change disrupting a live process.

Conventional endpoint detection and response (EDR) agents assume spare processing capacity, a supported operating system and the ability to take automated action such as quarantining a process or blocking network traffic. Many OT endpoints, particularly older PLCs, RTUs and embedded HMI devices, cannot meet any of those assumptions.

Where EDR-style tooling is deployed in OT, it is typically limited to modern engineering workstations and servers rather than field controllers, and any automated response action is usually disabled or replaced with an alert to a human operator, consistent with the safety-first priority described above.

IT monitoring commonly combines host-based agents with inline network security appliances. OT monitoring leans heavily on passive network taps and span ports, precisely because an inline device that fails or adds latency can itself interrupt a deterministic industrial protocol and create a safety issue.

• IT: host agents, inline firewalls, SIEM correlation across cloud and on-premises systems
• OT: passive network taps, protocol-aware sensors, asset inventory built from observed traffic
• IT: automated blocking on detection is standard practice
• OT: detection generally routes to a human decision before any blocking action is taken

The default IT incident response instinct, isolate the affected host immediately, does not transfer safely to OT. A controller isolated mid-process can leave a valve, pump or safety system in an undefined state. OT incident response plans assess safety impact before availability impact, and any isolation or shutdown decision is made jointly with process engineering, not by the security team alone.

In many organisations, IT security reports through a CISO with clear enterprise-wide authority. OT security ownership is more varied: it may sit with plant or engineering leadership, with a dedicated OT security function, or nominally under the CISO without matching operational authority on the plant floor.

NCSC and NIST guidance both recommend documented, unambiguous accountability for OT security decisions, including who can authorise a change, who can approve an emergency isolation, and who owns the relationship with equipment vendors. Without this, IT and OT teams can each assume the other has covered a given risk.

Commercial pressure for real-time production data, predictive maintenance and remote vendor support is increasing connectivity between OT and enterprise IT. This IT/OT convergence brings genuine operational benefit, but it also means a compromise that starts in enterprise IT, such as a phishing-led ransomware attack, can reach further into OT than it could when the two networks were fully separated.

Convergence therefore increases, rather than reduces, the need for the segmentation and recovery architecture described in the Purdue Model explainer.

Not every IT security control needs reinventing for OT, and not every OT constraint is as absolute as it first appears. The following distinctions are a practical starting point.

1. Asset inventory. Transfers well. Knowing what is on the network is foundational to both disciplines.
2. Network segmentation. Transfers with adaptation. The principle is the same; the implementation must respect deterministic protocols and safety zones.
3. Least-privilege access. Transfers well, though OT access models must also account for vendor and third-party maintenance access.
4. Automatic patch deployment. Does not transfer. OT patching needs vendor validation and a planned window.
5. Automated containment on detection. Does not transfer without modification. OT response must weigh safety before availability.
6. Offline, verified recovery data. Transfers and strengthens both disciplines. A known good, disconnected copy protects IT and OT against the same class of destructive attack.

Firevault sits at the point where OT and IT recovery planning genuinely converge: the need for a verified, offline copy of critical data that survives a compromise of either network. Offline Secure Storage® holds OT gold data, configurations and recovery assets, or IT backup data, in a state that is physically disconnected by default. Firevault Control governs when a connection is permitted, so the decision to open a data path is deliberate rather than automatic, in keeping with the safety-first approach described throughout this explainer, and consistent with the Disconnect to Protect® principle. This does not replace the segmentation, monitoring or incident response processes native to either discipline; it protects the recovery point both disciplines ultimately depend on.

• NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security

  Sets out how OT security priorities, architecture and controls differ from conventional IT security practice.

• ISA/IEC 62443 series

  Industrial automation and control systems security standards, including zones, conduits and security levels.

• NCSC, Operational Technology guidance collection

  UK guidance on OT architecture, connectivity and the practical limits of applying IT controls to OT.

• CISA, Cross-Sector Cybersecurity Performance Goals

  US guidance distinguishing baseline expectations for IT and OT/ICS environments.

• NIST CSF 2.0

  Framework functions referenced by both IT and OT security programmes, applied differently in each context.

Related Firevault guides