What is OT Security?

Operational technology is the hardware and software that detects or causes a change in physical processes through direct monitoring or control of physical devices such as valves, pumps, motors and sensors. OT security is the set of practices, controls and architecture decisions that protect that technology from failure, misuse and attack.

NIST SP 800-82 Revision 3 defines OT broadly enough to include industrial control systems, building automation, physical access control systems and other cyber-physical systems. In practice, most organisations use "OT security" and "ICS security" fairly interchangeably, with ICS treated as the industrial subset of the wider OT category.

A useful OT security programme starts with a precise inventory of what is actually on the estate. The following asset classes recur across almost every OT and ICS environment.

PLC

Programmable logic controller. Executes the control logic that runs a machine or process step.

RTU

Remote terminal unit. Gathers field data and relays it to supervisory systems, common in distributed sites such as pipelines.

DCS

Distributed control system. Coordinates control across a large, continuous process, typically within one site.

SCADA

Supervisory control and data acquisition. Provides centralised monitoring and control across geographically dispersed assets.

HMI

Human-machine interface. The screen and controls an operator uses to view and act on the process.

Historian

A database that records time-series process data for trending, reporting and forensic analysis.

Engineering workstation

The computer used to program, configure and update controllers and supervisory systems.

Safety instrumented system (SIS)

An independent layer of sensors, logic and final elements that brings the process to a safe state on a defined hazardous condition.

These asset classes typically sit at different levels of a Purdue-style reference architecture, from physical process at the bottom to enterprise IT at the top. For a full treatment of how those levels relate to each other and to network segmentation, see the Purdue Model explainer.

IT security commonly follows the confidentiality, integrity, availability (CIA) ranking, in that order. Losing confidentiality of a document is usually a serious but contained problem. OT security inverts that ranking to availability, integrity, then confidentiality, because losing availability of a control system can mean losing control of a physical process, which can create a safety event, not just a business one.

Many OT environments, particularly those covered by process safety regulation, operate under a documented safety case: an analysis that shows the risks of a process have been reduced to a tolerable level. Security controls that change timing, add network hops or introduce new failure modes must be assessed against that safety case before they are deployed.

This is why a control that is routine in IT, such as an endpoint agent that quarantines a host on suspicious activity, can be inappropriate in OT. An automatic isolation action taken against a controller mid-process could itself cause the unsafe condition the safety case was designed to prevent.

OT assets are commonly in service for fifteen to thirty years, running firmware and operating systems that were current when they were installed. Patching typically requires vendor validation, a planned outage or maintenance window, and in some cases physical presence on site. Continuous, automatic patching of the kind common in IT is rarely available in OT.

OT networks run deterministic industrial protocols, such as Modbus, DNP3, PROFINET and EtherNet/IP, that were designed for reliability and real-time performance rather than authentication or encryption. Many of these protocols have limited or no built-in security, which is why network-level controls, rather than protocol-level fixes, carry much of the security burden in OT.

Introducing a control that adds latency, such as inline deep packet inspection, can itself become a safety issue if it interferes with the timing a process depends on. This is one reason OT monitoring is more often built around passive network taps than inline appliances.

A small number of references dominate OT security practice internationally. None of them replace the others; most organisations map their controls against several at once, depending on sector and geography.

A common misunderstanding is treating the CAF as something an organisation can be "certified" against in the way a management system can be certified to an ISO standard. The NCSC CAF is explicitly outcome-based: an organisation and its regulator assess how well existing arrangements achieve the stated outcomes, rather than checking off a fixed list of technical requirements.

Because prevention cannot be guaranteed to succeed, OT security programmes increasingly treat recovery as a first order requirement rather than a fallback. OT gold data is the verified set of configurations, firmware images, PLC logic and engineering documentation needed to rebuild a control system after a fault, misconfiguration or cyber incident.

NIST SP 1800-11 sets out the general principle behind this: recovery depends on having a verified, trustworthy copy of the data and configuration needed to rebuild, separate from the systems that may themselves be compromised.

When assessing an OT security control, the following questions are a useful starting point before any technical detail is decided.

1. Safety impact. Could this control, or its failure mode, affect the process safety case?
2. Timing sensitivity. Does the control add latency or jitter that the process cannot tolerate?
3. Vendor support. Is the change validated by the equipment vendor for this specific system version?
4. Maintenance window. Can the change be deployed only during a planned outage, and if so, when is the next one?
5. Recovery position. If the change goes wrong, is a verified gold copy available to restore from?

OT security has real limits that are worth stating plainly. Legacy assets sometimes cannot be patched at all within their remaining service life. Passive monitoring can detect anomalies but cannot always block them without risking the process. Segmentation reduces exposure but does not eliminate the risk of insider error, supply chain compromise or a vendor's remote access credentials being misused.

Because of these limits, most mature OT security programmes accept that some level of compromise is possible and focus proportionate effort on detection, containment and, critically, on being able to recover quickly from a known good state.

Firevault's role in an OT security programme is narrow and specific: it protects the OT gold data and recovery assets described above with a physically disconnected copy, so that a verified restore point exists independently of the network that a ransomware attack or destructive event may have compromised. Offline Secure Storage® holds configurations, firmware and engineering documentation in a state that cannot be reached, altered or encrypted over a network connection. Firevault Control governs when a connection to that storage is permitted, so that the data path is closed by default and opened only for a defined recovery or verification operation, consistent with the Disconnect to Protect® principle. This sits alongside, not instead of, the safety, segmentation and monitoring controls described in this explainer.

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

  The primary US reference for OT/ICS asset classes, threats, network architecture and security controls.

• ISA/IEC 62443 series

  International standards for industrial automation and control systems security, including security levels, zones and conduits.

• NCSC, Operational Technology guidance collection

  UK guidance on OT architecture, secure connectivity and asset visibility.

• NCSC, Cyber Assessment Framework (CAF)

  Outcome-based framework commonly mapped against OT and essential-services environments rather than used as a pass or fail certification.

• NIST SP 1800-11, Data Integrity: Recovering from Ransomware and Other Destructive Events

  Practice guide on recovery architecture, applicable to OT gold data and configuration backups.

Related Firevault guides