This article defines Operational Technology (OT) as distinct from traditional IT, highlighting its core characteristics, such as real-time control, safety-critical processes, long-lifecycle assets, and minimal security by design. It is the first in a short series of articles that argues that failure to recognise OT environments as such leads to systemic cybersecurity blind spots, particularly in sectors like healthcare, logistics, and building management.

Contents

Introduction

Operational Technology (OT) refers to systems designed to interact with and control the physical world. Unlike Information Technology (IT), which centres on the flow, storage, and protection of data, OT systems are concerned with process control, equipment behaviour, and environmental outcomes. OT governs the interface between digital instructions and real-world consequences.

Historically, OT emerged in manufacturing, utilities, and heavy industry domains where supervisory control and data acquisition (SCADA), distributed control systems (DCS), and programmable logic controllers (PLCs) became the backbone of process automation. These systems were physically isolated, vendor-specific, and designed for deterministic behaviour—predictability, not agility, was the operating principle.

But as digital transformation has swept across sectors, OT has proliferated into environments not traditionally seen as industrial. The problem is that the cyber risk model hasn’t followed suit. We continue to apply IT-based thinking, firewalls, endpoints, and network monitoring to environments where the threats, failure modes, and risk tolerances are entirely different.

Before exploring environments that are OT in all but name, it’s essential to clarify what defines OT from a functional and security standpoint.

Core Characteristics of an OT Environment

Cyber-Physical Interaction

• OT systems directly affect physical processes: heating a fluid, adjusting a valve, directing a conveyor belt, activating a surgical device.
• This tight coupling between cyber inputs and physical outputs means the consequences of failure can be tangible, dangerous, or even life-threatening.

Availability and Safety Take Precedence

• In IT, confidentiality often trumps all. In OT, availability and physical safety are paramount. The system must work, even if it’s vulnerable.
• Patching and scanning may be deprioritised if there’s any risk of service interruption or patient harm.

Long Lifecycle Equipment

• OT assets typically operate for decades, not years. They may run legacy operating systems, unsupported firmware, or even proprietary protocols.
• Replacement is expensive and risky… “if it isn’t broken, don’t touch it” becomes a functional doctrine.

Highly Deterministic Behaviour

• OT environments require predictable, real-time behaviour. Latency, jitter, or unexpected updates can introduce instability.
• Systems are finely tuned; even a minor change (e.g. a firewall rule or VLAN misconfiguration) can halt operations.

Tightly Coupled Systems with Low Tolerance for Change

• Components in OT networks often depend on fixed IPs, hardcoded credentials, or fixed timing signals.
• Security measures like encryption, authentication, or segmentation—standard in IT—can break workflows or disrupt service delivery.

Legacy Protocols and Minimal Security by Design

• Many OT protocols (e.g. Modbus, BACnet, DICOM in healthcare) were never designed with security in mind. They assume trusted environments.
• Encryption, authentication, and auditability are often retrofitted, if at all.

Flat, Unsegmented Networks

• In many OT contexts, devices share a broadcast domain. This makes deployment and maintenance simpler but exposes the entire environment to lateral compromise.
• The ethos is: “Keep it running”, not “secure by default.”

Mixed Ownership and Governance

• OT assets are frequently managed by non-IT teams, facilities, engineering, clinical staff, or third-party vendors.
• As a result, patching cycles, logging, and even asset inventories may fall outside the remit of central IT or security teams.

Real-Time or Near-Real-Time Constraints

• Many OT systems require a response within milliseconds or seconds, particularly in safety-critical domains.
• This limits the feasibility of security tools that add latency or unpredictability, such as deep packet inspection or inline scanning.

High Stakes, Low Visibility

• A security incident in an OT environment might not involve a data breach—it could be a factory fire, a failed surgery, or a halted train.
• Yet many such environments lack basic intrusion detection or monitoring, operating in what is effectively a cyber blind spot.

Conclusion

In short, OT is defined not by technology stack but by function: if a system’s primary purpose is to monitor or control physical operations, then it is OT, regardless of whether it runs on Linux, Windows, or something bespoke. The failure to recognise this distinction is not just a semantic oversight; it is a strategic vulnerability.

With this lens in mind, we can now revisit a range of environments across industry, public services, and everyday life that function as OT, even though they are governed, secured, and funded as if they were merely IT.