Why OT Cybersecurity Is Not IT Cybersecurity: Where Cyber Risk Meets the Physical World
- ICS cyber security, ics security, ics security assurance, industrial cybersecurity, ot cybersecurity, process safety
OT Cybersecurity Fundamentals — S1E1
Estimated reading time: 6 minutes
A cybersecurity incident in a business environment can disrupt email, data, applications, or customer-facing services. In an Operational Technology (OT) environment, the consequences can extend into the physical world, such as: loss visibility of such process, equipment may behave unexpectedly, process trip or production stop, or safety safeguards may be affected that can trigger further safety incident.
That is why OT cybersecurity cannot be treated as simply as “IT security with industrial devices.”
OT cybersecurity still needs many familiar cybersecurity capabilities: identity management, segmentation, monitoring, patch management, backup, incident response, and governance. The difference is the environment in which those capabilities operate. In OT, cybersecurity decisions must be made with a clear understanding of the process being controlled, its operational constraints, and the consequence of failure.
Failed to understand this context will lead to improper cybersecurity assurance capability and strategy, due to OT environment has its unique operations philosophy, each facility may have different behaviour regardless it is located and operated by the same institution, with the same production output.
What is OT?
Before we continue to the further discussion, it is important to understand the term that being used on this article. We are using the term OT, it stands for Operational Technology, as the term to cover the broad category of programmable systems and devices that interact with, monitor, or control the physical environment. It includes industrial control systems as well as technologies used in building automation, transportation, physical access control, and environmental monitoring. NIST SP 800-82 Rev. 3 describes OT security in the context of its unique performance, reliability, and safety requirements.
Other term that still being used to refer to the same entities, such as ICS (Industrial Control System), Cyber-Physical System, IACS (Industrial Automation Control System), or other terms, are not being used on this article, since we will use only one term, OT, to refer to the above system under consideration.
In typical industrial environment, common OT assets may include:
- Distributed Control Systems (DCS)
- Programmable Logic Controllers (PLCs)
- Remote Terminal Units (RTUs)
- Supervisory Control and Data Acquisition (SCADA) systems
- Human-Machine Interfaces (HMIs)
- Safety Instrumented Systems (SIS)
- Engineering workstations
- Historians
- Industrial switches, firewalls, and gateways
- Sensors, actuators, valves, drives, and field instruments
These assets are not just storing or processing information. They help measure temperature, pressure, flow, and level as the main process variable measurement, with some derivative variable measurement such as speed, position, chemical composition, and other process conditions also part of the OT asset capability (monitoring and surveillance). They can also issue commands that open valves, start motors, change setpoints, or stop equipment, based on specific process variable setting, or manually driven by the operators (via HMI), to ensure the normal operations behaviour of the facility is under safe form.
The key difference: cyber events can become process events
An IT-focused question might be:
What happens if this server, laptop, or account is compromised?
In OT, that remains important, but it is not enough. A more useful question is:
What happens to the physical process if this system loses availability, due to system compromised?
A cyber event may lead to a control system impact, means a process event which triggered by certain control action related to this process. This impact may cause a process deviation, which may lead to safety, production operations, environment, or financial consequences.
| Step | Example question |
| Cyber event | Has a system, account, remote connection, or communication path been compromised? |
| Control-system impact | Could logic, settings, commands, data, or visibility be affected? |
| Process deviation | Could pressure, temperature, flow, or level move outside their intended range? |
| Operational consequence | Could the event cause downtime, reduced quality, equipment damage, or loss of production? |
| Safety/environmental consequence | Could people, environment, or critical safeguards be exposed to unacceptable risk? |
This cyber-to-process relationship is the central idea behind OT cybersecurity.
IT and OT share foundations, but their operating context differs
It is tempting to describe IT and OT as entirely separate worlds. They are not. Both depend on people, process, and technology to build the security assurance in place. , Both need strong identity management, asset management, risk management, secure configuration, monitoring and surveillance, emergency response management (BCP/DRP, incident response, and recovery management).
However, the operating context is different.
| IT environment | OT environment |
| Primarily manages information and digital services | Primarily monitors or controls physical processes |
| Frequent updates may be expected | Changes often require engineering review, maintenance windows, and operational validation |
| Reboots may be disruptive but manageable | Reboots can interrupt production or affect process stability |
| Standardized endpoints are common | Specialized, long-lived, and vendor-specific devices are common |
| Security teams often own most controls | Responsibility is shared among operations, engineering, maintenance, safety, vendors, and cybersecurity teams |
| A primary concern may be data loss or service disruption | A primary concern may be a process consequence caused by lost control, lost visibility, or altered behaviour |
These are tendencies, not universal rules. A data breach can be highly consequential in an OT organization, and confidentiality remains important for engineering data, intellectual property, credentials, and remote access. Likewise, some IT systems support critical services that demand very high availability.
The practical lesson is not to replace the familiar confidentiality, integrity, and availability model. It is to expand the discussion so that safety, reliability, process consequence, and operational constraints are considered explicitly.
Safety, Reliability, and Availability Shape the OT Environment
In OT environments, security controls have to work without creating unacceptable operational side effects.
For example, a poorly planned security change could introduce communication latency, block a legitimate engineering activity or certain critical services, interrupt a production dependency, or make incident recovery harder. That does not mean security should be delayed or weakened. It means security must be engineered and validated in the same disciplined way as other changes to a physical process.
Three questions are especially useful:
- Safety: Could a cyber event contribute to unacceptable harm to people or the environment?
- Reliability: Could it prevent a system from performing its intended function consistently?
- Availability: Could it prevent a required system or process from operating when needed?
The relative importance of these objectives depends on the process, asset, and scenario. A safety instrumented function, a production controller, an engineering workstation, and a historian may each have a different consequence profile. Effective OT cybersecurity strategy recognizes those differences rather than applying identical controls everywhere.
Five Realities that make OT Cybersecurity Different
1. The process must be understood before security controls are selected
A firewall rule, patch frequency and approach, service blocked list, remote-access solution, or even changing the default credentials should be evaluated thoroughly, as put it as part of the entire system and see how it interacts with the other system, ensuring not issue if certain security controls are being deployed. OT engineering and cybersecurity teams need to understand what the asset does, which process it supports, who depends on it, and what could happen if it is unavailable or altered.
2. Availability is more than Uptime
A system can be technically online while still failing its operational purpose. For example, an HMI may be available but display incorrect data, or a controller may be running but unable to communicate with a required supervisory system.
Availability in OT therefore has to be considered alongside correctness, process timing, operator visibility, and operational recovery.
3. Change is a Controlled Operational Activity
In enterprise IT, patching and configuration updates can often be automated and deployed quickly. In OT, the same activity may require vendor consultation, a maintenance outage, engineering validation, rollback planning, and coordination with operations and safety teams.
Proper backup and restore management should also in place, to ensure there is always a way to return back to the previous version prior to any update deployed.
This does not justify leaving vulnerable systems unmanaged. It means remediation needs to be risk-based and compatible with the process lifecycle.
4. OT Environments often include Long-Lived and Specialized Assets
Industrial systems may operate for many years, even more than decade. They can depend on proprietary software, legacy operating systems, specific controller firmware, or specialized communications protocols. Their technical limitations must be understood when designing compensating controls such as segmentation, application allowlisting, monitored remote access, or stronger backup and recovery management.
5. OT Cybersecurity is a Shared Responsibility
No single team has complete knowledge of an OT environment.
Operations understands how the process is run. Engineering understands control logic and system design. Maintenance understands equipment lifecycle and field realities. Safety teams understand safeguards and consequence. Cybersecurity teams bring threat, security control, and cybersecurity assurance expertise. Vendors and integrators may hold essential product knowledge.
A mature OT cybersecurity program creates a common language among these groups and makes risk decisions collaboratively.
A Practical Starting Point
Organizations do not need to begin with a large technology purchase. A strong starting point is to answer five basic questions:
- What physical processes do we operate?
- Which OT assets monitor or control those processes?
- Which assets and functions are most critical to safety, production operations, an financial?
- How are these assets connected to each other, to enterprise systems, and to remote users or vendors?
- Who is accountable for approving and validating OT cybersecurity changes?
The NIST Cybersecurity Framework (CSF) 2.0 provides a useful common language for organizing this work through its six Functions: Govern, Identify, Protect, Detect, Respond, and Recover. It describes cybersecurity outcomes rather than prescribing one technical implementation, which makes it useful for coordinating OT stakeholders with different responsibilities. NIST CSF 2.0
Key Takeaway
OT cybersecurity is not only about protecting devices and networks. It is about reducing the likelihood and consequence of cyber events affecting physical operations, which can lead to HSE risk exposure.
The most effective starting point is process understanding: know what the environment does, what assets support it, who depends on them, and what could happen when availability, integrity, visibility, or control is lost.
Next in the series
Understanding why OT is different is the foundation. The next article will map the architecture in which OT systems operate: the Purdue Model, industrial trust boundaries, and why system connections matter for cybersecurity design.
References
- NIST SP 800-82 Rev. 3: Guide to Operational Technology Security
- NIST Cybersecurity Framework 2.0
- NIST CSF 2.0 Resource and Overview Guide

