Operational Technology (OT) Security

Operational Technology encompasses the hardware and software systems that detect or cause changes in physical devices, processes, and events. This includes programmable logic controllers (PLCs), supervisory control and data acquisition (SCADA) systems, distributed control systems (DCS), human-machine interfaces (HMIs), building automation systems, facility-related control systems, and the industrial networks that connect them. OT is the digital nervous system behind the physical world: it controls the flow of electricity across a regional grid, regulates chemical treatment in a municipal water supply, manages the assembly line in a defense manufacturing facility, and governs environmental systems inside a data center or military installation.

For decades, OT environments operated in relative isolation from corporate networks and the public internet. Control systems were often deployed on proprietary hardware, using specialized protocols, physically separated from IT networks — a condition commonly referred to as an "air gap." This isolation, combined with the specialized nature of industrial protocols, created a form of security through obscurity. Attackers needed deep domain knowledge of industrial processes to cause meaningful harm, and the cost of entry was high.

That isolation has eroded steadily over the past two decades. The drive toward operational efficiency, remote monitoring, predictive maintenance, and data-driven decision-making has pushed organizations to connect OT environments to IT networks, cloud platforms, and third-party vendor systems. This convergence — commonly called IT/OT convergence — has delivered significant operational and financial benefits, but it has also expanded the attack surface for systems that were never designed with cybersecurity as a primary requirement.

The stakes in OT security differ fundamentally from those in traditional IT security. A breach of a corporate database may result in data theft, financial loss, or reputational damage. A breach of an OT environment can result in loss of electrical power to hospitals and homes, contamination of drinking water, unsafe conditions in a manufacturing plant, or disruption of military logistics and readiness. Because OT systems directly control physical processes, the consequences of a successful attack can include equipment damage, environmental harm, mission failure, and — in the most severe cases — loss of human life.

Why OT Security Is a Distinct Discipline

Cybersecurity practitioners moving from IT into OT quickly discover that the underlying engineering assumptions are different. In IT, the objective is generally to protect information. In OT, the objective is to protect a physical process — and the security program exists to support, not compete with, safety and reliability engineering that has often existed at a facility for far longer than any cybersecurity function. This distinction changes how risk is assessed, how incidents are handled, and who ultimately owns the outcome of a security decision.

A useful way to frame this for executives is to think in terms of consequence rather than likelihood alone. A phishing email that compromises an office workstation is a common, moderate-consequence event. A cyber event that manipulates the logic controlling a pressure relief valve, a water disinfection process, or an electrical protection relay is a low-frequency but potentially catastrophic-consequence event. OT security programs are built around this consequence-driven view of risk, which is why asset criticality and safety impact — not just technical vulnerability severity — drive prioritization throughout this guide.

Federal and Defense Relevance

For federal agencies and Department of Defense organizations, OT security is inseparable from mission assurance. Installation utilities, microgrids, fuel systems, airfield systems, water and wastewater treatment, HVAC and building automation, physical access control systems, shipyards, depots, arsenals, and defense industrial base manufacturing facilities all depend on OT. A disruption to any of these systems can directly affect installation resilience, readiness, and the ability to execute a mission — independent of whether any traditional IT system is ever touched.

This mission linkage is why OT security increasingly intersects with formal federal risk management processes, including the Risk Management Framework (RMF), Authorization to Operate (ATO) decisions, and continuous monitoring obligations under FISMA. Later chapters in this guide address how these processes apply specifically to OT and facility-related control systems, and how organizations can avoid the common pitfall of applying an IT-centric RMF approach to a fundamentally different class of system.

This guide is intended to serve as a practical reference for understanding the OT security landscape — from the industrial control systems that make up the OT environment, to the threats targeting them, to the architectures, standards, governance models, and best practices organizations use to defend them. It is written to be accessible to executives, installation leadership, and program managers seeking to understand risk and investment priorities, as well as to engineers, ISSOs, ISSMs, and cybersecurity practitioners responsible for designing and operating the technical controls that protect these environments.

Industrial Control Systems (ICS) is the umbrella term for the various types of control systems and associated instrumentation used for industrial process control. ICS is a subset of OT and includes the specific devices, controllers, and software that sense and manipulate physical processes. Understanding the components of ICS is foundational to understanding OT security, because each component type carries its own risk profile, communication protocols, engineering constraints, and security considerations.

Programmable Logic Controllers (PLCs)

A Programmable Logic Controller is a ruggedized industrial computer designed to execute logic that controls machinery and physical processes in real time. PLCs read input from sensors — such as temperature, pressure, or flow rate — and execute programmed logic to control outputs such as motors, valves, pumps, or relays. PLCs are the workhorses of industrial automation, found in manufacturing plants, water treatment facilities, energy generation sites, and building automation systems.

PLCs are typically programmed using specialized languages defined in the IEC 61131-3 standard, including ladder logic, function block diagrams, and structured text. From a security perspective, PLCs present unique challenges: many were designed decades ago without authentication for programming access, lack the processing overhead required for encryption, and cannot support traditional endpoint security agents such as antivirus software. An engineer with a laptop and vendor programming software can often upload or download logic to a PLC with no credential check whatsoever — a design assumption from an era when physical proximity to the device was considered sufficient authorization.

SCADA (Supervisory Control and Data Acquisition)

SCADA systems provide centralized monitoring and control over geographically distributed industrial processes. A SCADA system aggregates data from field devices — often spread across large physical areas such as a pipeline network, electrical transmission grid, or water distribution system — and presents that data to operators through a centralized interface. SCADA systems are common in utilities, oil and gas, and other infrastructure sectors where assets are widely dispersed.

A SCADA architecture typically consists of field devices (sensors and actuators), remote terminal units or PLCs that interface with those devices, a communication network connecting remote sites to a central control location, and a master station where operators monitor and control the overall system. Because SCADA systems often rely on wide-area communication links — including radio, cellular, satellite, and leased telecommunications lines — they introduce additional attack surface beyond the physical plant floor, including the risk of signal interception, spoofing, or jamming on wireless backhaul links.

Distributed Control Systems (DCS)

Distributed Control Systems are used primarily in continuous process industries such as oil refining, chemical manufacturing, and power generation, where the control system is physically and logically distributed across a single facility rather than spread across a wide geographic area. Unlike SCADA, which is optimized for monitoring dispersed assets, DCS is optimized for high-density, high-reliability control of a single complex process with many interconnected control loops.

DCS architectures typically feature redundant controllers, high-speed proprietary or standardized industrial networks, and tight integration between process control and safety systems. Because DCS environments often manage processes with significant safety implications — such as a chemical reactor or a refinery distillation column — DCS security must be closely coordinated with process safety engineering, and any proposed security control must be reviewed for its potential to interfere with control loop timing.

Human-Machine Interfaces (HMIs)

An HMI is the interface through which human operators monitor and interact with industrial processes. HMIs display real-time data such as tank levels, pressure readings, and equipment status, and allow operators to issue commands such as starting a pump or adjusting a setpoint. HMIs range from dedicated industrial panels mounted on plant floor equipment to software applications running on standard Windows-based workstations in a control room.

Because many HMIs run on general-purpose operating systems, they are often the most IT-like component in an OT environment — and consequently one of the more common initial access points for attackers, particularly when HMI software is unpatched, uses outdated operating systems, or is reachable from broader network segments than operationally necessary.

Remote Terminal Units (RTUs)

RTUs are field devices that interface directly with sensors and actuators, collecting data and transmitting it to a central SCADA master station, often over long-distance communication links. RTUs are common in geographically dispersed environments such as pipelines, electrical substations, and water distribution networks. RTUs are functionally similar to PLCs but are generally optimized for remote telemetry and communication over lower-bandwidth links rather than high-speed local control logic.

Engineering Workstations and Historians

Engineering workstations are the systems used by control engineers to configure, program, and troubleshoot PLCs, DCS controllers, and HMIs. Because these workstations typically hold the credentials, software, and access required to modify controller logic, they represent one of the highest-value targets in an OT environment — a compromise of an engineering workstation can translate directly into unauthorized changes to physical process behavior.

Historians are databases that record time-series process data for trending, reporting, and regulatory purposes. While historians are not control systems themselves, they often bridge OT and IT — collecting data from Level 1 and Level 2 devices and making it available to business systems at Level 3 and above — which makes them a common target for reconnaissance and a frequent point of IT/OT boundary crossing that must be carefully governed.

Safety Instrumented Systems (SIS)

Safety Instrumented Systems are independent control systems, separate from the primary process control system, designed specifically to bring a process to a safe state if it deviates outside defined safe operating limits. An SIS typically has its own sensors, logic solver, and final control elements, and is engineered to fail safe. Because an SIS exists specifically to prevent catastrophic outcomes, it warrants the highest level of architectural and access protection within an OT environment, a topic explored further in Chapter 3.

Building Automation and Facility-Related Control Systems

Building Automation Systems (BAS) and the broader category of Facility-Related Control Systems (FRCS) manage HVAC, lighting, electrical distribution, fire and life safety, physical access control, elevators, and utility monitoring within a facility. These systems are frequently overlooked in enterprise cybersecurity programs because they are managed by facilities or public works organizations rather than the IT or cybersecurity department, yet they are fully capable of being remotely accessed, misconfigured, or compromised — and on a military installation, FRCS can be directly tied to mission-critical infrastructure such as data center cooling, hospital environmental controls, or perimeter security systems.

Industrial Networks

Industrial networks connect the various components of an ICS environment — PLCs, RTUs, HMIs, historians, and engineering workstations — enabling the exchange of control and monitoring data. Industrial networks differ from enterprise IT networks in several important respects: they often prioritize deterministic, low-latency communication; they may use protocols not designed with security in mind; and they frequently contain a mix of legacy and modern equipment with vastly different capabilities and lifecycles.

Industrial networks are typically organized into a hierarchical architecture, often described using the Purdue Model (discussed in Chapter 5), which segments the environment into levels ranging from the physical process itself up to enterprise business systems.

Common OT Protocols

OT environments rely on a range of communication protocols, many of which were designed decades ago for reliability and real-time performance rather than security. Most of these protocols predate widespread cyber threat awareness in industrial engineering and were built to prioritize deterministic timing and interoperability among field devices on isolated networks — an assumption of physical isolation that no longer holds in most modern environments. Understanding these protocols is important because many lack native authentication, encryption, or integrity verification — meaning that anyone with network access can often issue commands or read data without restriction.

Sensors, Actuators, Drives, and Field Devices

At the lowest level of the ICS environment sit the field devices that directly interact with the physical process: sensors that measure conditions such as temperature, pressure, level, and flow; actuators and final control elements such as valves and dampers; and variable frequency drives that control motor speed. These devices typically communicate with PLCs or RTUs over dedicated field-level buses and generally have no independent security capability of their own — their protection depends entirely on the integrity of the controller and network layers above them, reinforcing why layered network and access controls are essential rather than optional in ICS environments.

Although IT and OT security share common underlying principles — such as the importance of asset visibility, access control, and monitoring — the two disciplines diverge significantly in their priorities, risk tolerance, and operational constraints. Organizations that apply IT security practices to OT environments without adaptation often introduce operational risk rather than reducing cybersecurity risk. This chapter goes beyond the familiar "availability versus confidentiality" framing to examine the practical engineering realities that separate the two domains.

Key Differences

Operational Priorities

In IT security, the well-known CIA triad — Confidentiality, Integrity, Availability — is typically applied in that order of priority. Protecting sensitive data from unauthorized disclosure is often the primary concern, followed by ensuring data has not been tampered with, followed by ensuring systems remain available.

In OT environments, this priority order is frequently inverted. Availability is paramount because industrial processes must continue operating safely and reliably; an unplanned shutdown of a power generation unit, a water treatment process, or a manufacturing line can have significant safety, financial, and public health consequences. Integrity is a close second, since corrupted sensor data or manipulated control commands can cause a process to behave in unsafe or damaging ways. Confidentiality, while still important — particularly for engineering drawings, control logic, and configuration data — is generally a lower priority than keeping the physical process running safely.

Availability vs Confidentiality

This inversion of priorities has direct implications for how security controls are designed and deployed. In IT environments, security teams may quarantine a compromised endpoint immediately, force a password reset, or take a system offline pending investigation. In OT environments, the same action — abruptly isolating a controller or forcing a system reboot — could interrupt a physical process mid-cycle, potentially causing equipment damage, product loss, or a safety event.

As a result, OT security controls must be designed to detect and respond to threats without introducing operational risk. This often means favoring passive monitoring over active scanning, coordinating any intrusive action with operations and engineering teams, and building incident response procedures that account for safe shutdown and restart sequences specific to each process.

Practical Examples of IT Actions Causing OT Disruption

These are not theoretical concerns. They reflect patterns observed repeatedly across industrial environments when IT security practices are applied without adaptation.

Lifecycle and Support Realities

Asset lifecycles measured in decades mean that OT environments routinely include unsupported operating systems, proprietary hardware with no available replacement, and vendor software that has not been updated in years. Unlike IT, where an unsupported operating system is a clear finding requiring remediation, OT organizations often cannot simply replace the asset — the controller may be integral to a certified process, tied to safety documentation, or embedded in equipment with a multi-decade capital replacement cycle. This reality does not eliminate the risk; it changes the response, shifting the emphasis toward compensating controls, network isolation, and enhanced monitoring rather than direct remediation.

Specialized Engineering Knowledge and the Need for Operator Involvement

A cybersecurity professional cannot safely make unilateral decisions about an OT environment without understanding the physical process being controlled. A network change that appears routine — adjusting a firewall rule, adding a monitoring tap, or restricting a communication path — can have consequences that are invisible to someone without process engineering context. For this reason, mature OT security programs require every architectural or operational change to be reviewed jointly by cybersecurity and engineering/operations personnel, and incident response plans must explicitly define when and how operators are brought into a cyber decision in real time.

Safety Considerations

Perhaps the most distinguishing characteristic of OT security is the direct link to physical safety. Many OT environments include dedicated Safety Instrumented Systems (SIS) — independent control systems designed to bring a process to a safe state if it deviates outside safe operating parameters, regardless of what the primary control system is doing. A cyberattack that disables or manipulates an SIS, or that manipulates the primary control system in a way that triggers unsafe conditions, can result in consequences far beyond data loss.

Why This Distinction Matters for Governance

Because OT decisions carry physical and safety consequences that IT decisions typically do not, OT security cannot be governed using an IT change advisory process alone. Organizations that succeed in this space establish joint decision rights between cybersecurity, engineering, and operations, ensuring that no single function can unilaterally take an action that affects the physical process. This governance model is explored in greater depth in Chapter 5 and Chapter 8.

OT environments face a distinct threat landscape shaped by the criticality of the systems involved, the age of much of the installed equipment, and the operational constraints that limit how quickly defenders can respond. The following threat categories represent the most consequential risks facing OT operators today, along with the mechanisms through which they typically manifest inside a control environment.

Ransomware

Ransomware has emerged as one of the most disruptive threats to OT environments, even when the ransomware itself targets IT systems rather than OT directly. Because many organizations lack strong segmentation between IT and OT networks, ransomware that compromises corporate IT systems frequently forces a precautionary shutdown of OT operations to prevent lateral spread — resulting in production stoppages, service interruptions, and significant financial impact even without a single OT device being directly infected.

In some cases, ransomware operators have developed OT-aware capabilities, specifically identifying and targeting industrial software, historians, and engineering workstations to maximize operational disruption and increase pressure to pay a ransom. From a governance standpoint, ransomware readiness in OT is as much about segmentation and offline backups as it is about endpoint protection, since many affected OT devices are never directly touched by the malware itself.

Insider Threats

Insider threats in OT environments can be intentional or unintentional. A disgruntled employee or contractor with legitimate access to control systems can cause significant harm given the direct physical consequences of OT manipulation. Equally common — and often more damaging in aggregate — are unintentional insider actions: an engineer connecting an infected laptop to the control network for a legitimate maintenance task, a misconfigured firewall rule opening unintended access, or a vendor technician bypassing security controls to expedite troubleshooting. Removable media, such as USB drives used to transfer logic files or firmware updates, remains a persistent unintentional insider vector, particularly in environments without a controlled media transfer process.

Nation-State Attacks

Nation-state actors have demonstrated sustained interest in critical infrastructure OT environments, motivated by espionage, pre-positioning for potential future disruption, and geopolitical signaling. Documented incidents have targeted electric grid operators, water utilities, oil and gas infrastructure, and manufacturing facilities tied to defense supply chains. These actors are often well-resourced, patient, and capable of developing custom malware specifically designed to manipulate industrial protocols and control logic.

For federal agencies and defense organizations, nation-state targeting of OT is a persistent and elevated concern, particularly for installations supporting critical mission functions, energy resilience, and logistics. Pre-positioning — establishing and maintaining quiet access inside OT networks without taking immediately disruptive action — is a documented pattern of concern, since it can allow an adversary to hold critical infrastructure at risk for use during a future crisis or conflict rather than for immediate financial or espionage gain.

Supply Chain Risks

OT environments depend on a complex supply chain of hardware manufacturers, software vendors, systems integrators, and third-party maintenance providers. A compromise introduced anywhere in this supply chain — whether through malicious firmware, a compromised software update mechanism, or counterfeit hardware — can propagate to end users with limited visibility into the original point of compromise. Supply chain risk is especially acute in OT because equipment lifecycles are long, vendor relationships are often deeply embedded in operational processes, and verifying the integrity of firmware and software updates can be technically challenging.

Federal and defense organizations should treat OT supply chain risk management as a distinct discipline from IT software supply chain security, since it must account for firmware provenance, hardware sourcing, and the long tail of legacy components that remain in service well beyond a typical IT hardware refresh cycle.

Legacy Systems

A substantial proportion of OT assets in operation today were deployed before modern cybersecurity practices existed, and many will remain in service for years or decades to come due to the cost and operational risk associated with replacement. Legacy systems frequently run unsupported operating systems, lack the processing capacity to support encryption or endpoint agents, and may not have been designed to withstand modern network-based attacks. These systems cannot simply be patched or upgraded in the way IT systems can, requiring compensating controls at the network and architectural level.

Remote Access Abuse

The expansion of remote access for vendors, integrators, and internal engineering staff has introduced one of the most common initial access vectors into OT environments. Remote access solutions that lack multi-factor authentication, use shared or default credentials, or provide overly broad network access once connected, create a direct pathway from the internet into the industrial control environment. Numerous documented OT incidents have originated through compromised or poorly secured remote access connections, including VPNs, remote desktop services, and vendor-supplied remote support tools.

Additional Threat Patterns Worth Tracking

Beyond the primary categories above, several specific attack patterns recur across documented OT incidents and warrant explicit attention in a threat model.

Mapping Threats with MITRE ATT&CK for ICS

The MITRE ATT&CK for ICS knowledge base catalogs tactics and techniques specific to industrial control system environments, providing a structured, non-vendor-specific reference for understanding adversary behavior against OT — from initial access and execution through impact on the physical process. Organizations building threat models, tuning monitoring use cases, or preparing for a security control assessment benefit from mapping their own environment's exposure against this framework rather than relying solely on generic IT-oriented threat intelligence.

A mature OT security architecture is built on layered controls that account for the operational, safety, and reliability requirements unique to industrial environments. Rather than a single product or control, effective OT security architecture integrates asset visibility, network segmentation, identity and access management, secure remote access, continuous monitoring, and incident response into a coordinated defense-in-depth strategy.

The Purdue Model as an Architectural Reference

Many OT architectures are still described using the Purdue Enterprise Reference Architecture, which segments industrial environments into hierarchical levels. While modern architectures increasingly incorporate cloud connectivity and flatter network designs, the Purdue Model remains a useful conceptual reference for understanding functional separation within OT environments.

Designing the IDMZ

An effective IDMZ is not a single firewall but a dedicated network segment containing the specific systems required to broker communication between IT and OT — data historians replicas, patch and antivirus definition relays, jump hosts for remote access, and, where required, one-directional data replication services. No system at Level 4 or above should be able to initiate a direct connection into Level 3 or below; all such communication should originate from, or be brokered through, the IDMZ. Unidirectional gateways, sometimes called data diodes, are commonly used where OT process data needs to leave the environment for reporting or analytics purposes but no return path into OT is operationally required.

Asset Visibility

Organizations cannot secure what they cannot see. Asset visibility is the foundation of any OT security program, yet it remains one of the most significant gaps in many industrial environments. Unlike IT environments, where asset inventory can often be automated through active scanning, OT asset discovery must typically rely on passive network monitoring to avoid disrupting sensitive control devices with active probing.

A comprehensive OT asset inventory should capture, at minimum, device type and function, manufacturer and model, firmware and software versions, network location and communication patterns, and criticality to the physical process and to the supported mission. This inventory forms the basis for vulnerability management, network segmentation design, and incident response planning.

1. Deploy passive network monitoring sensors at key network segments to observe traffic without introducing risk to sensitive devices.
2. Correlate observed network traffic with known device fingerprints and protocol behaviors to identify device type, vendor, and firmware where possible.
3. Supplement passive discovery with manual physical walkdowns to capture devices that do not communicate over monitored network segments, including serial and isolated field devices.
4. Establish a centralized asset inventory system that is kept current through both automated discovery and change management processes.
5. Classify assets by criticality to the physical process, safety impact, and mission impact to prioritize protection efforts.
6. Assign an accountable system owner to every asset category so that inventory accuracy is a shared, ongoing responsibility rather than a one-time project.

Network Segmentation and Microsegmentation

Network segmentation limits the ability of an attacker to move laterally from a lower-consequence network segment into a higher-consequence one. In OT environments, segmentation should be designed around the Purdue Model or a comparable zone-and-conduit approach, as described in IEC 62443, with clearly defined trust boundaries between IT, the IDMZ, and each level of the OT environment.

Effective segmentation relies on industrial firewalls, unidirectional gateways, and virtual LAN (VLAN) architectures that enforce strict rules about what traffic is permitted to cross each boundary. Segmentation should also be applied within the OT environment itself — separating different process areas or production lines through microsegmentation — to contain the impact of a compromise to the smallest practical zone rather than allowing an incident in one process area to spread across an entire facility.

Identity and Access Management

Identity and access management (IAM) in OT environments must reconcile modern access control principles with the operational realities of legacy equipment, shift-based operations, and safety-critical workflows. Many legacy OT devices cannot support modern authentication mechanisms directly, which means IAM controls are often enforced at the network or jump-host layer rather than the device layer.

Key principles for OT identity and access management include enforcing least privilege for all users and service accounts, eliminating shared or generic credentials wherever feasible, implementing multi-factor authentication at all IT/OT boundary crossings, and maintaining strict separation between engineering (configuration-capable) access and operator (monitoring and control-only) access. Where operationally necessary, organizations should also define a documented, auditable break-glass or emergency access procedure for use during safety events or outages, ensuring emergency access is tightly logged and reviewed after every use rather than left permanently open. For deeper implementation guidance, see Anchor Defense's identity and access management resources.

Secure Remote Access

Remote access into OT environments — whether for internal engineers, systems integrators, or original equipment manufacturers — should be architected as a tightly controlled, monitored pathway rather than a general-purpose network extension. A well-designed secure remote access architecture typically includes a dedicated jump host or remote access gateway located in the IDMZ, multi-factor authentication for all remote sessions, time-bound and task-scoped access approvals, full session recording and logging, and the ability for operations personnel to immediately terminate any remote session.

1. Require all remote access requests to be submitted and approved through a formal workflow prior to connection.
2. Route all remote sessions through a centralized jump host in the IDMZ — never allow direct remote connections into Level 1–3 OT networks.
3. Enforce multi-factor authentication for every remote session, including vendor and integrator access.
4. Limit each session to the minimum set of systems and duration required for the approved task, using just-in-time access provisioning where possible.
5. Record and retain all remote access sessions for audit and incident investigation purposes.
6. Automatically disable or expire remote access credentials that are not actively in use.

Monitoring

Continuous monitoring provides the visibility necessary to detect anomalous activity, policy violations, and potential compromise within the OT environment. Monitoring architecture is discussed in greater depth in Chapter 6, but at the architectural level, monitoring capabilities should be integrated at each network boundary and within critical process zones, feeding into a centralized security operations capability with OT-specific context and expertise.

Incident Response

OT incident response differs from IT incident response in that response actions must account for safe shutdown and restart procedures, potential safety implications, and the operational cost of downtime. OT-specific incident response plans should be developed in close coordination with engineering, safety, and operations teams, and should be tested through regular tabletop exercises that include realistic OT-specific scenarios such as loss of view, loss of control, or manipulation of safety systems.

Redundancy and High Availability

Because availability is a primary security objective in OT, architecture decisions must account for redundancy at the points most likely to affect operational continuity — including redundant controllers in critical process areas, redundant network paths across segmentation boundaries, and high-availability configurations for monitoring and access infrastructure so that a failure of a security control does not itself become a source of operational disruption. Security architecture in OT should be designed to fail in a way that preserves safe operation, not simply to fail closed as might be acceptable in an IT context.

Continuous monitoring is essential for detecting threats in OT environments where preventive controls alone cannot address every risk, particularly given the prevalence of legacy equipment that cannot be patched or protected with traditional endpoint tools. OT monitoring architectures must be designed to provide visibility without introducing operational risk to sensitive control systems, and must produce output that is actionable by analysts who understand industrial context.

Passive Monitoring vs. Active Scanning

Passive monitoring involves observing network traffic without actively interacting with OT devices, typically through a network tap or switch port mirroring configuration. This approach avoids the risk associated with active scanning techniques, which can cause unpredictable behavior in fragile legacy devices — including, in documented cases, causing PLCs to fault or enter a safe-stop state simply from receiving unexpected network traffic.

Active scanning, by contrast, sends probe traffic directly to devices to elicit a response, and is standard practice in IT vulnerability management. In OT, active scanning should only be used with explicit engineering approval, during a planned maintenance window, on devices confirmed to tolerate it, and never as a default or scheduled activity across a production control network. Passive monitoring solutions analyze industrial protocol traffic to identify connected devices, communication patterns, and command sequences, building a baseline understanding of normal operational behavior against which deviations can be detected.

Industrial Anomaly Detection

Anomaly detection in OT environments identifies deviations from established baselines of normal process and network behavior. Because industrial processes tend to exhibit highly repetitive and predictable communication patterns — unlike the more variable traffic patterns typical of IT environments — anomaly detection can be particularly effective in OT once an accurate baseline has been established.

Common anomaly categories include new or unauthorized devices appearing on the network, unexpected communication between devices that do not normally interact, unusual command sequences or parameter changes, and communication using protocols or ports that fall outside established norms for a given zone.

Behavioral Analytics

Behavioral analytics extends beyond simple anomaly detection by modeling the expected operational behavior of specific devices and processes over time, accounting for legitimate variation such as scheduled maintenance windows, seasonal operational changes, or shift-based process adjustments. Effective behavioral analytics requires close collaboration between cybersecurity teams and process engineers to distinguish between benign operational variation and genuinely suspicious activity.

Threat Hunting in OT

Threat hunting in OT differs from IT threat hunting in that hypotheses must be grounded in process knowledge as much as in adversary tradecraft. A useful OT threat hunt might investigate whether any engineering workstation has communicated with a controller outside of a documented change window, whether any device is issuing write commands to a controller it has not historically interacted with, or whether historian data shows a process parameter trend that does not correlate with any known operational event. Threat hunting programs should be built jointly with engineering staff so that hunts are testable against ground truth about how the process is supposed to behave.

Logging

Comprehensive logging across OT network infrastructure, jump hosts, engineering workstations, and — where technically feasible — control devices themselves, provides the forensic foundation necessary for incident investigation and threat detection. Given that many legacy OT devices have limited or no native logging capability, logging strategies often rely on network-level visibility and logging at IT/OT boundary points such as the IDMZ.

Alert Triage in OT

Effective alerting in OT environments requires careful tuning to avoid alert fatigue while ensuring that genuinely significant events reach the appropriate personnel promptly. Because OT security teams are often smaller and more specialized than their IT counterparts, alerting strategies should prioritize high-fidelity, context-rich alerts over high-volume, low-context notifications. Alerts involving potential safety system interaction, unauthorized logic changes to controllers, or new external connections should be treated as highest priority and escalated immediately.

An effective triage process assigns each alert category a defined escalation path and a defined operational decision-maker — not simply a cybersecurity analyst — because many alerts require a judgment call about process risk that only an engineer or operator can make with confidence. Organizations that route every OT alert through a generic IT SOC queue without this operational context frequently experience either dangerous under-response or unnecessary, costly precautionary shutdowns.

OT Monitoring Deployment Checklist

• Identify and document all network segments and boundary points requiring monitoring coverage, prioritized by criticality.
• Confirm passive tap or mirror port capacity exists at each identified location before procurement.
• Establish an initial baseline period sufficient to capture normal seasonal and shift-based operational variation before enabling alerting.
• Define alert severity tiers and corresponding escalation paths jointly with operations and engineering stakeholders.
• Identify the specific personnel authorized to receive and act on each alert tier, including after-hours coverage.
• Establish a documented process for tuning alert rules based on confirmed false positives without disabling detection for genuine threat categories.
• Integrate OT monitoring output with the broader SOC while preserving OT-specific context in the workflow.

A number of established standards and frameworks provide structured guidance for building and maturing an OT security program. These frameworks are particularly important for federal agencies, defense organizations, and critical infrastructure operators subject to regulatory or contractual compliance requirements. It is important to distinguish among frameworks that provide voluntary guidance, standards that define technical architecture, and regulations that carry mandatory, enforceable compliance obligations.

IEC 62443

IEC 62443 is a series of international standards specifically developed for the security of industrial automation and control systems. It provides a comprehensive framework covering security for asset owners, system integrators, product suppliers, and service providers. Key concepts introduced by IEC 62443 include the zone and conduit model for network segmentation, Security Levels (SL 0 through SL 4) that define the capability of a system to resist increasingly sophisticated threat actors, and Foundational Requirements covering areas such as identification and authentication control, use control, system integrity, and data confidentiality. IEC 62443 is a voluntary technical standard rather than a regulatory mandate, but it is widely referenced as the de facto architectural framework for ICS security programs across sectors.

NIST Cybersecurity Framework

The NIST Cybersecurity Framework (CSF) provides a widely adopted, sector-agnostic structure for managing cybersecurity risk, organized around core functions: Govern, Identify, Protect, Detect, Respond, and Recover. While not OT-specific, the CSF is commonly used by critical infrastructure operators as an overarching risk management structure, often supplemented with OT-specific guidance such as NIST SP 800-82 for technical implementation detail. The CSF is a voluntary framework rather than a regulation, though many organizations reference it in policy and contractual requirements.

NIST SP 800-82

NIST Special Publication 800-82, "Guide to Operational Technology Security," provides detailed technical guidance specifically for securing ICS environments, including SCADA systems, DCS, and PLCs. It addresses ICS-specific risk management, recommended security architectures, and detailed control recommendations tailored to the operational constraints of industrial environments. SP 800-82 is a foundational reference for U.S. federal agencies and is widely used by critical infrastructure operators as a technical companion to the broader NIST Cybersecurity Framework and to NIST SP 800-53 control catalogs.

NIST SP 800-53 and the Risk Management Framework

NIST SP 800-53 provides the catalog of security and privacy controls used within the federal Risk Management Framework (RMF), and includes overlays and tailoring guidance applicable to industrial and platform information technology systems. For federal OT environments, RMF implementation typically requires tailoring the standard control baseline to account for systems that cannot support certain IT-centric controls — for example, a legacy PLC may not be able to support session lock or automated account lockout — with compensating controls documented accordingly. This tailoring should be performed with direct input from control engineers, not applied generically by security assessors unfamiliar with the physical process, and should be clearly documented for review by the Authorizing Official and Security Control Assessor.

CISA Guidance

The Cybersecurity and Infrastructure Security Agency (CISA) publishes a range of guidance, advisories, and tools specific to OT and ICS security, including vulnerability advisories for specific industrial products, sector-specific guidance for critical infrastructure operators, and resources such as the Cross-Sector Cybersecurity Performance Goals, which provide a baseline set of voluntary practices applicable across critical infrastructure sectors. CISA also operates coordination mechanisms for reporting and responding to OT-related incidents affecting U.S. critical infrastructure.

NERC CIP

The North American Electric Reliability Corporation Critical Infrastructure Protection (NERC CIP) standards are mandatory, enforceable cybersecurity requirements applicable to the bulk electric system in North America. NERC CIP standards cover areas including asset identification and categorization, security management controls, personnel and training, electronic security perimeters, physical security, systems security management, incident reporting and response planning, recovery plans, configuration change management, and supply chain risk management. Compliance with NERC CIP is mandatory for applicable entities and is subject to audit and enforcement, distinguishing it clearly from the voluntary frameworks described above.

DoD Considerations

Department of Defense organizations operating OT — including installation energy systems, utility infrastructure, industrial control systems supporting weapons platforms, and logistics infrastructure — must account for additional considerations beyond civilian critical infrastructure frameworks. These include the DoD Risk Management Framework as applied to control systems and Platform Information Technology, DoD-specific control overlays for facility-related control systems, and the broader mission assurance context in which OT security supports operational readiness and installation resilience.

Coordination between installation energy managers, facility engineers, and cybersecurity personnel is essential, as DoD OT environments frequently span both traditional installation infrastructure and mission-critical operational systems. Categorizing an FRCS or platform IT system correctly, engaging the right stakeholders early in the ATO process, and documenting tailored controls appropriately are among the most common sources of delay and rework in DoD OT authorization efforts.

MITRE ATT&CK for ICS

As referenced in Chapter 4, MITRE ATT&CK for ICS provides a structured taxonomy of adversary tactics and techniques specific to industrial environments. While not a compliance framework, it is increasingly used to inform detection engineering, red team scoping, and gap analysis against known adversary behavior in OT contexts.

The following best practices represent widely accepted, foundational elements of a mature OT security program. While the specific implementation will vary based on sector, organizational size, and regulatory environment, these practices form a common baseline applicable across critical infrastructure and defense OT environments.

Asset Inventory

Maintaining a complete, current, and accurate inventory of all OT assets is the foundation upon which every other security control depends. Without knowing what devices exist, where they are located, and how they communicate, organizations cannot effectively assess risk, prioritize patching, design segmentation, or detect anomalies.

Patch Management

Patch management in OT environments must account for the operational risk of applying updates to systems that directly control physical processes. Unlike IT environments, where patches can often be deployed automatically, OT patches typically require vendor validation, scheduled maintenance windows, and testing in a representative non-production environment before deployment.

1. Maintain a current vulnerability and patch inventory mapped against the OT asset inventory.
2. Prioritize patches based on exploitability, exposure, and criticality of the affected asset to the physical process and mission — not solely on published vulnerability severity scores.
3. Validate patches in a test or staging environment that mirrors production configuration where feasible.
4. Schedule patch deployment during planned maintenance windows in coordination with operations.
5. For assets that cannot be patched due to vendor unsupportability or operational constraints, document compensating controls such as network isolation or enhanced monitoring.

Network Segmentation

As detailed in Chapter 5, network segmentation remains one of the most effective controls for limiting the blast radius of a compromise. Organizations should regularly validate that segmentation controls are functioning as designed, since firewall rule drift and undocumented network changes over time can quietly erode segmentation effectiveness. Segmentation design should always begin with a communications mapping exercise — documenting which devices actually need to talk to which other devices — rather than being designed around assumed or convenient network boundaries.

Backups

Reliable, tested backups of PLC and controller logic, HMI configurations, engineering project files, golden configurations, and historian data are essential for recovery from both cyber incidents and non-malicious failures. OT backup strategies must account for the specialized formats used by different control system vendors and should include offline or immutable copies to protect against ransomware that specifically targets connected backup repositories.

Recovery Planning

Recovery planning for OT environments must go beyond data restoration to address the safe restart of physical processes following an incident. Recovery plans should define the sequence in which systems must be brought back online to ensure safety interlocks and process dependencies are respected, identify the personnel authorized to approve restart, define manual operating procedures that allow limited continuity of operations if automated control is unavailable, and include procedures for verifying system integrity — confirming that restored systems have not been altered — before returning to production operation.

Vendor Access

Third-party vendor and integrator access represents one of the most persistent risk vectors in OT environments. Vendor access should be governed by formal agreements specifying security requirements, subject to the same secure remote access controls described in Chapter 5, and reviewed periodically to ensure access remains necessary and appropriately scoped.

Change Management

Formal change management processes ensure that modifications to OT systems — whether configuration changes, logic updates, or network changes — are reviewed, approved, tested, and documented before implementation. Robust change management not only reduces the risk of unintended operational disruption but also provides a critical baseline against which unauthorized changes can be detected.

Incident Response

As discussed in Chapter 5, OT incident response plans must be tailored to the operational and safety context of the environment, developed in coordination with engineering and operations stakeholders, and validated through regular exercises. Incident response readiness should be treated as an ongoing program rather than a static document.

Governance: Why OT Security Cannot Be Owned by Cybersecurity Alone

OT security decisions frequently carry safety and operational consequences that fall outside the traditional authority of a cybersecurity function. A cybersecurity team can identify a risk, but the decision to accept, mitigate, or act on that risk in a live process environment must involve the people accountable for the safe and continuous operation of that process. Mature programs establish formal, joint decision rights across the functions below.

OT Security Maturity Model

Organizations at different stages of OT security investment benefit from a shared reference point to assess current state and plan next steps. The maturity model below describes five stages across the core capability areas addressed throughout this guide.

Common Implementation Mistakes

Organizations pursuing OT security improvement frequently encounter the same set of avoidable missteps. Understanding why these occur helps program leaders sequence work correctly.

• Assuming the environment is air-gapped. Undocumented connections are common; verify isolation rather than assuming it.
• Deploying active scanners without engineering approval. Active probing can fault legacy devices; passive discovery should be the default.
• Treating IT and OT assets identically. Applying IT patch cadence, endpoint agents, or password policies uniformly can destabilize control systems.
• Installing controls without understanding process dependencies. A firewall rule or monitoring tap deployed without engineering review can disrupt timing-sensitive communication.
• Allowing direct vendor access. Bypassing the jump host "just this once" for convenience creates an unmonitored path that often persists.
• Using shared administrator credentials. Shared accounts eliminate accountability and make incident attribution difficult.
• Failing to inventory controller logic and firmware. Without a logic baseline, unauthorized changes cannot be reliably detected.
• Collecting alerts without an OT triage process. Alerts routed to a generic SOC queue without operational context are often ignored or mishandled.
• Designing segmentation without mapping communications. Segmentation built on assumptions rather than actual traffic data frequently breaks operations or leaves gaps.
• Patching solely based on vulnerability severity. Severity alone ignores exposure and asset criticality, misdirecting limited maintenance windows.
• Failing to test recovery procedures. Untested backups frequently fail to restore correctly when actually needed.
• Treating compliance as proof of security. A passed audit does not guarantee operational resilience against a determined adversary.
• Excluding facility and engineering teams from governance. Cybersecurity-only governance produces policies that operations cannot safely execute.
• Buying a monitoring platform before establishing ownership and response processes. Tooling without a defined triage and response process generates alerts no one is positioned to act on.

Initial OT Security Assessment Checklist

• Identify and document all OT system owners and mission dependencies across the organization.
• Confirm whether a current, accurate OT asset inventory exists and assess its completeness.
• Map existing network topology and identify all points where IT and OT networks connect.
• Confirm whether an IDMZ exists and, if so, validate that no direct IT-to-OT connections bypass it.
• Identify all remote access pathways into the OT environment, internal and third-party.
• Determine whether passive monitoring exists in any part of the environment and assess coverage gaps.
• Confirm whether a documented, OT-specific incident response plan exists and when it was last exercised.
• Confirm whether offline backups of controller logic and configurations exist and when they were last tested.
• Review vendor access agreements for security requirements and time-bound access provisions.
• Identify applicable regulatory and framework obligations (NERC CIP, DoD RMF, sector-specific requirements) and current compliance status.

The OT security landscape continues to evolve as new technologies reshape how industrial environments are designed, connected, and operated. Organizations planning long-term OT security strategy should account for several emerging trends that will shape the risk landscape over the coming years.

Industrial Internet of Things (IIoT)

The proliferation of IIoT devices — sensors, actuators, and edge computing devices designed for direct connectivity and data sharing — is expanding the OT attack surface at a rapid pace. Unlike traditional OT devices, many IIoT devices are explicitly designed for cloud connectivity, often communicating directly with vendor cloud platforms outside the boundaries of traditional OT network segmentation. This trend requires organizations to rethink traditional segmentation models, extending security architecture principles to account for devices that may bypass the IDMZ entirely through cellular or direct internet connections.

For installations evaluating IIoT and sensor connectivity outside a traditional wired network — including tactical or expeditionary environments — Anchor Defense's guidance on tactical 5G and wireless wide-area networking addresses considerations specific to managing connectivity and segmentation for mobile and edge OT deployments.

Artificial Intelligence

Artificial intelligence is increasingly applied on both sides of the OT security equation. Defensively, AI-driven analytics enhance anomaly detection capabilities by identifying subtle deviations in process behavior that would be difficult for human analysts to detect manually, particularly across large, complex environments. Offensively, AI is lowering the barrier to entry for adversaries by accelerating vulnerability research, enabling more convincing social engineering campaigns targeting OT personnel, and potentially assisting in the development of protocol-aware attack tools. Organizations should approach AI-enabled security tools with the same rigor applied to other OT technology decisions — validating that these tools do not introduce new risk through cloud dependencies or unvalidated automated actions taken directly against control systems.

Zero Trust

Zero Trust principles — which assume no implicit trust based on network location and require continuous verification of identity and authorization — are increasingly being adapted for OT environments. Applying Zero Trust in OT requires careful consideration of the unique constraints of legacy devices that cannot support modern authentication natively; in practice, this often means enforcing Zero Trust principles at the network and access-broker layer, using microsegmentation, strong identity verification at boundary points, and continuous monitoring, rather than requiring every legacy field device to independently authenticate every transaction. Anchor Defense's Zero Trust architecture guidance and network access control resources provide additional detail on adapting these principles to environments with a significant population of legacy, non-authenticating devices.

Cloud Connectivity

The growing use of cloud platforms for historian data, predictive maintenance analytics, and remote monitoring is extending OT data flows beyond the traditional facility boundary. While cloud connectivity can deliver significant operational value, it also introduces new considerations around data governance, third-party risk, and the security of the connectivity mechanisms bridging OT environments to cloud services. Organizations pursuing cloud connectivity for OT data should ensure that data flows are one-directional where possible, that cloud integration points are treated as additional IDMZ-equivalent boundaries, and that vendor cloud platforms are evaluated with the same rigor as any other third-party access into the OT environment.

Autonomous Operations

Increasing adoption of autonomous and semi-autonomous industrial operations — including self-optimizing control systems and reduced human-in-the-loop decision-making — raises new questions about the security and resilience of the algorithms and models driving these systems. As autonomous decision-making becomes more prevalent in safety-relevant processes, ensuring the integrity of the data and models feeding these systems will become an increasingly important dimension of OT security, alongside traditional network and endpoint protections.

Continuous Controls Monitoring and Automation

As OT security programs mature, manual validation of segmentation, access, and configuration controls becomes difficult to sustain at scale. Continuous controls monitoring — the ongoing, automated verification that security controls remain correctly configured and effective over time — is an increasingly important complement to point-in-time assessments, particularly for organizations managing continuous monitoring obligations under RMF. Similarly, workflow automation and orchestration can reduce the manual burden of access approvals, patch validation tracking, and evidence collection for security control assessments, provided that any automated action affecting the OT environment itself is scoped, tested, and approved with the same rigor as a manual change.

What is the difference between OT and ICS?

Operational Technology (OT) is the broader category encompassing all hardware and software that monitors or controls physical devices and processes. Industrial Control Systems (ICS) is a subset of OT that specifically refers to the control systems — such as SCADA, DCS, and PLCs — used to manage industrial processes. All ICS is OT, but OT also includes broader categories such as building automation and physical access control systems.

What is the difference between OT security and IT security?

IT security generally prioritizes confidentiality, integrity, and availability in that order, and operates on systems with relatively short refresh cycles. OT security generally prioritizes availability and safety first, operates on systems that remain in service for decades, and must account for the direct physical and safety consequences of a compromise. The two disciplines share common principles but require different tools, priorities, and governance.

What is SCADA and how is it different from a DCS?

SCADA systems provide centralized monitoring and control over geographically distributed assets, such as a pipeline or electrical grid. A DCS is optimized for high-density, high-reliability control of a single complex process within one facility, such as a refinery. SCADA prioritizes wide-area visibility; DCS prioritizes tightly integrated, high-speed local control.

What is a PLC and why is it hard to secure?

A Programmable Logic Controller is an industrial computer that executes logic to control physical equipment such as motors, valves, and pumps. Many PLCs were designed without authentication for programming access and lack the processing capacity for encryption or endpoint security agents, so protection typically relies on network-level and access controls rather than the device itself.

What is the Purdue Model, and is it still relevant?

The Purdue Model is a hierarchical reference architecture that segments industrial environments into distinct levels based on function, from the physical process at Level 0 up to enterprise business systems at Level 5. While modern architectures increasingly incorporate cloud connectivity and more flexible network designs that don't map perfectly to the traditional hierarchy, the underlying principle of enforced segmentation between IT and OT — and among different levels within OT — remains a foundational concept in OT security architecture.

What is an Industrial Demilitarized Zone (IDMZ)?

An IDMZ is a dedicated network segment that sits between the enterprise IT network and the OT environment, containing the systems needed to broker data exchange — such as jump hosts, data replicas, and patch relays — so that no direct connection exists between the two environments.

Why do many industrial protocols lack built-in security?

Protocols such as Modbus and DNP3 were designed decades ago for reliability and real-time performance on physically isolated networks, at a time when cybersecurity was not a design consideration. As a result, many lack native authentication, encryption, or integrity verification, and organizations must compensate with network-layer controls.

What is an air gap, and is it still an effective security strategy?

An air gap refers to a complete physical separation between a network and any external connectivity, including the internet and corporate IT networks. True air gaps still exist in some highly sensitive environments, but they have become increasingly rare due to the operational benefits of connectivity for monitoring, maintenance, and analytics. Organizations that believe they maintain an air gap should verify this assumption regularly, as undocumented connections are a common source of unexpected exposure.

Why can't OT environments simply use the same security tools as IT?

Many traditional IT security tools, particularly active vulnerability scanners and endpoint agents, can cause unintended disruption when applied to OT devices that were not designed to handle unexpected network traffic or additional processing load. OT security tools are generally designed to operate passively and with an understanding of industrial protocols and operational constraints.

What is the difference between passive monitoring and active scanning in OT?

Passive monitoring observes network traffic without interacting with devices, typically through a network tap or mirrored port, and is the default approach in OT. Active scanning sends probe traffic directly to devices to elicit a response and can destabilize fragile legacy equipment; it should only be used with engineering approval during a planned maintenance window.

How does asset discovery work in an OT environment?

OT asset discovery typically relies on passive network monitoring to identify devices based on their observed communication patterns and protocol behavior, supplemented by manual physical walkdowns to capture devices, such as serial-connected field equipment, that do not appear on monitored network segments.

How often should OT systems be patched?

There is no universal answer, as patching cadence in OT must be balanced against operational risk and vendor validation requirements. Organizations should prioritize patches based on exploitability, exposure, and the criticality of the affected asset, applying compensating controls such as network isolation for systems that cannot be patched promptly.

What should be done about legacy systems that cannot be patched or replaced?

Legacy systems that cannot be patched or replaced should be protected through compensating controls, primarily network segmentation and isolation, enhanced monitoring for anomalous activity, and restricted access limited to only the personnel and systems that require interaction with the device. Organizations should also maintain a documented risk acceptance and mitigation plan for each unsupportable legacy asset.

What is network segmentation and why does it matter in OT?

Network segmentation divides a network into zones with defined trust boundaries and controlled communication paths, known as conduits, limiting an attacker's ability to move laterally from a lower-consequence segment into a higher-consequence one. In OT, segmentation should be based on an actual mapping of device communications rather than assumptions.

What is microsegmentation in an OT context?

Microsegmentation applies fine-grained segmentation within the OT environment itself — for example, separating individual production lines or process areas — so that a compromise in one area cannot easily spread across the entire facility.

How should vendor and third-party remote access be secured?

Vendor remote access should be routed through a dedicated jump host in the IDMZ, require multi-factor authentication, be scoped to the minimum systems and duration needed for the task, and be fully session-recorded for audit purposes. Direct, unmonitored vendor connections into the OT network should never be permitted.

Is multi-factor authentication realistic for OT environments with legacy devices?

Yes, though it is typically enforced at the network or access-broker layer rather than on the legacy device itself, since most legacy OT devices cannot support modern authentication natively. MFA should be mandatory at every IT/OT boundary crossing and for all remote access sessions.

Can Zero Trust be applied in OT environments?

Zero Trust principles can be adapted for OT by enforcing continuous identity verification, microsegmentation, and monitoring at the network and access-broker layer, rather than requiring every legacy field device to independently authenticate every transaction, which most cannot support.

How does ransomware typically affect OT environments?

Ransomware often compromises IT systems first and forces a precautionary OT shutdown to prevent lateral spread, causing significant operational disruption even without directly infecting OT devices. Some ransomware operators have also developed OT-aware capabilities that specifically target industrial software and engineering systems.

What does OT-specific incident response look like?

OT incident response must account for safe shutdown and restart sequencing, potential safety implications, and the operational cost of downtime, and should be developed jointly with engineering and operations teams rather than adapted directly from an IT incident response plan. It should be tested through regular tabletop exercises using realistic OT scenarios.

What backup and recovery practices are most important for OT?

Organizations should maintain offline, immutable backups of controller logic, HMI configurations, and engineering project files, and test restoration procedures at least annually. Recovery plans should also define the safe sequencing required to restart a physical process, not just the technical steps to restore data.

What is the role of a Security Operations Center (SOC) in OT environments?

A SOC monitoring OT environments requires personnel with specific training in industrial protocols and operational context, since activity that appears anomalous from a pure IT lens may be entirely normal within an industrial process, and vice versa. Many organizations establish a dedicated OT monitoring capability with direct coordination pathways to operations and engineering teams.

How does OT security relate to physical safety systems?

Safety Instrumented Systems (SIS) are independent systems designed to bring a process to a safe state if it deviates outside safe operating parameters. Because a cyberattack targeting an SIS could directly endanger human safety, these systems warrant the highest level of protection and should be treated as a distinct, tightly controlled security domain.

What frameworks should a federal agency or critical infrastructure operator start with?

Most organizations benefit from using the NIST Cybersecurity Framework as an overarching risk management structure, supplemented by NIST SP 800-82 for OT-specific technical guidance, and IEC 62443 for detailed architectural and lifecycle security practices. Organizations subject to sector-specific regulation, such as NERC CIP for electric utilities, must also incorporate those mandatory requirements. CISA's Cross-Sector Cybersecurity Performance Goals provide a useful prioritized starting point for organizations early in their OT security maturity journey.

How does the Risk Management Framework (RMF) apply to OT systems?

Federal OT systems are typically categorized and authorized under RMF using NIST SP 800-53 controls, tailored to account for systems that cannot support certain IT-centric controls natively. This tailoring should be performed jointly with control engineers and clearly documented for review by the Authorizing Official and Security Control Assessor, since applying a generic IT control baseline to a legacy control system often produces findings that cannot realistically be remediated.

What is the difference between a voluntary framework and a mandatory regulation in OT security?

Frameworks such as the NIST CSF and standards such as IEC 62443 provide voluntary, widely referenced guidance for structuring a security program. Regulations such as NERC CIP and the DoD RMF process carry mandatory, enforceable compliance obligations for applicable entities, subject to audit and formal authorization decisions.

Why can't OT security be owned by the cybersecurity team alone?

OT security decisions frequently have direct safety and operational consequences that fall outside the traditional authority of a cybersecurity function. Sustainable programs require joint decision rights among cybersecurity, engineering, operations, and facility or mission leadership, since only those functions collectively have full visibility into both the cyber risk and the physical process risk.

How does OT security apply to a military installation beyond weapons platforms?

Installation utilities, microgrids, water and wastewater treatment, fuel systems, HVAC and building automation, and physical access control systems are all OT, and a disruption to any of these can affect installation resilience and mission readiness independent of any traditional IT system being involved. These facility-related control systems are frequently managed by public works or facilities organizations and require deliberate coordination with cybersecurity and RMF processes.

Is compliance with a framework the same as being secure?

No. Passing an audit or completing an authorization confirms that specific documented controls are in place at a point in time, but it does not guarantee resilience against a determined adversary. Compliance should be treated as a baseline and a governance mechanism, not a substitute for continuous monitoring, tested incident response, and validated recovery capability.