Five Critical Controls for ICS/OT Cybersecurity

What the five controls are trying to achieve

The five controls are not meant to be a full OT security program. They are the minimum practical baseline for reducing common ICS exposure while preserving availability and safe operation. Together, they address the most frequent ways OT environments are reached, changed, or disrupted: weak visibility, exposed remote access, slow remediation, unauthorised software execution, and flat networks.

That baseline logic is reflected in OT guidance from NIST SP 800-82 Rev 3, OT Security Guide and CISA’s industrial control systems materials, which both treat segmentation, remote access control, and inventory as foundational rather than optional.

Why these controls are grouped together in OT

ICS and OT differ from typical enterprise IT because safety, uptime, and deterministic control often matter as much as confidentiality. That changes the security design problem. Controls that are common in corporate environments must be adapted so they do not interrupt controllers, HMIs, historians, or engineering workstations.

The five controls therefore form a defensive sequence. Asset visibility tells you what exists. Secure remote access limits how outsiders or central teams reach it. Patch and vulnerability management reduces known exposure where change windows allow. Application whitelisting constrains what code can run on critical hosts. Network segmentation limits how far a compromise can move across zones and conduits. This is the same logic used in CISA Industrial Control Systems guidance and in the OT hardening and segmentation models in OT Security Guide.

How each control reduces ICS attack surface

Asset visibility reduces blind spots, especially for unmanaged engineering assets, legacy devices, and shadow connections that can never be protected if they are not discovered. Secure remote access reduces the abuse of vendor support paths, jump hosts, and remote desktop exposure, which are common entry points in OT incidents.

Patch and vulnerability management matter because many industrial environments cannot patch on the same cadence as IT, so the real control is disciplined prioritisation and compensating measures, not speed alone. Application whitelisting helps when only a small set of approved binaries should ever execute on HMIs or servers. Network segmentation contains compromise and supports safer recovery by limiting lateral movement between business networks, supervisory layers, and field environments. Those priorities align closely with the structure of OT Asset Visibility Guide, OT Patch Management Guide, and HMI and SCADA Server Hardening Guide.

What the controls do not do on their own

The five controls are useful because they are simple enough to apply across many sites, but they are not sufficient by themselves. They do not replace secure engineering, safety review, identity governance, logging, backup strategy, or vendor assurance. In OT, a control that works well on paper can still fail if it cannot be operated during maintenance, tested against plant constraints, or sustained through lifecycle change.

For that reason, these controls should be treated as a baseline to be adapted to site criticality, process hazard, and the architecture of the control system. In practice, the control set is most effective when it is paired with triage rules for advisories, exception handling for unpatchable assets, and a clear segmentation model such as zones and conduits. The CISA CPG baseline and OT maturity guidance are useful reference points for that broader operating model.

Risk and Threat Considerations

ICS and OT environments are exposed when this baseline is incomplete or only partially enforced. Attackers often look for the easiest path into a plant, such as weak remote access, stale software, exposed engineering workstations, or a route from a less trusted network into a more sensitive one. Once inside, poor segmentation and weak application control can let them move, persist, or disrupt operations.

Failure mechanism: In OT, the main failure pattern is usually not a single broken control but a chain of weak controls that lets an attacker or fault reach a high-value process asset.

Impact: The result can be unauthorised command execution, process disruption, loss of visibility, unsafe recovery work, or broader operational downtime that affects safety and production.

Practitioner Guidance

Why practitioners should care: The five controls are best used as a prioritisation model, not a checklist. They help teams decide where to start when the environment is legacy-heavy, availability-sensitive, and too large to harden all at once.

Governance implication: Ownership should be explicit across operations, engineering, security, and vendor support, because each control depends on a different part of the OT operating model. A site can only sustain this baseline if exceptions, maintenance windows, and approval paths are assigned and reviewed.

Practitioner takeaway: Treat the five controls as the minimum defendable OT baseline, then expand into asset-specific hardening, monitored exceptions, and zone-based design as the site matures.

Related resources from NHI Mgmt Group

• ICS/OT Cybersecurity
• OT Cybersecurity
• Cybersecurity
• How should critical infrastructure teams validate cybersecurity controls under Bill C-8?