Operational technology breaches are no longer theoretical scenarios discussed in conference rooms. They stop production lines, corrupt safety instrumented systems, and in documented cases have created conditions with direct physical consequences. Yet many OT environments still operate with flat networks, unpatched controllers running decade-old firmware, and remote access pathways provisioned for convenience rather than security.
The challenge is structural. OT environments were built for reliability and safety, not for network defense. Integrating security without compromising uptime requires discipline, vendor coordination, and a fundamentally different mindset than IT security. Generic cybersecurity frameworks do not translate directly into control system environments where a misconfigured firewall rule can interrupt a safety function.
This article delivers ten pragmatic, prioritized OT security best practices that operational teams can start implementing this quarter. Each practice is vendor-neutral, applicable across manufacturing, utilities, energy, and critical infrastructure, and aligned to authoritative standards including NIST SP 800-82, IEC 62443, and CISA operational guidance.
Why OT Security Has Never Been More Urgent
The industrial sector is now the primary target for ransomware operators. According to Dragos’s OT Cybersecurity Year in Review 2023, manufacturing represented the most targeted OT sector for the third consecutive year, with ransomware groups increasingly deploying industrial-aware variants designed to identify and persist within ICS environments (as of December 2023).
Supply chain compromises targeting OT vendors, firmware repositories, engineering workstation software, and remote support tools, have expanded the attack surface beyond the plant perimeter. The FBI and CISA issued a joint advisory in 2024 highlighting persistent targeting of water utilities and energy infrastructure by nation-state actors exploiting unpatched internet-facing OT systems (as of March 2024) (source: CISA Advisory AA24-038A). These are not edge cases. They are the new operating environment.
1. Establish Complete Asset Discovery and Authoritative Inventory
What it is: A continuously maintained, validated record of every OT asset, PLCs, RTUs, DCS nodes, HMIs, engineering workstations, network switches, and IIoT devices, including firmware version, communication protocols, and network location.
Why it reduces breach risk: You cannot detect anomalies in assets you do not know exist. Unmanaged assets are consistently the entry points in OT breach investigations, either as direct targets or as unmonitored pivot points. Asset visibility is the prerequisite for every other practice on this list.
How to implement:
- Deploy passive discovery tools (Claroty, Nozomi Networks, Dragos, or Tenable.OT) to enumerate assets from network traffic without sending packets to live controllers, active scanning of PLCs remains high-risk.
- Supplement with vendor documentation review, maintenance records, and physical walk-downs for airgapped segments.
- Tag every asset with criticality tier, owner, and maintenance window in a CMDB integrated with your change management process.
- Reconcile inventory quarterly and after any topology change.
Quick checklist:
- Passive discovery deployed across all OT segments
- Every asset assigned criticality (safety-critical / production-critical / monitoring)
- Firmware versions documented for top 20 critical assets
- Inventory integrated with vulnerability management workflow
- Unmanaged/shadow assets flagged for review
Estimated impact: Organizations completing a baseline passive inventory typically discover 15–40% more assets than their CMDB reflects (source: Dragos, 2023). Full inventory coverage reduces mean time to detect (MTTD) anomalies by eliminating blind spots.
Pitfall: Relying solely on IT discovery tools, many will either miss OT protocols or crash legacy devices.
2. Implement Network Segmentation and ICS Zone Architecture
What it is: Physically and logically separating OT networks from corporate IT and external networks using defense-in-depth zone architecture aligned to the Purdue Reference Model or IEC 62443 zone and conduit model.
Why it reduces breach risk: Flat OT networks allow an attacker with a foothold in the IT domain to reach safety instrumented systems without traversing a single security control. Segmentation limits lateral movement and contains the blast radius of any single compromise.
How to implement:
- Establish an OT DMZ between IT and OT networks, no direct routed connections across the boundary without explicit firewall policy.
- Apply micro-segmentation within OT: separate Level 0/1 (field devices), Level 2 (control systems), Level 3 (operations management), and safety systems (SIS) into distinct VLANs with allow-list firewall rules.
- Enforce unidirectional data diodes for one-way historian feeds to IT where bidirectional communication is not operationally required.
- Document all legitimate data flows before writing firewall rules, unknown or legacy flows are discovered during this process, not after.
Sample firewall policy logic: Deny all by default; permit specific source IP / destination IP / port combinations documented in the flow register; log all denied traffic to SIEM.
Diagram suggestion: Sample OT network segmentation diagram showing IT network → Firewall → OT DMZ (historian, jump server, patch server) → Firewall → Level 3 (operations) → Level 2 (control) → Level 1/0 (field). Alt text: “OT network segmentation diagram showing zoned architecture with DMZ between IT and control network.”
Quick checklist:
- OT DMZ implemented between enterprise and control network
- Safety instrumented systems on isolated, dedicated network
- All IT/OT data flows documented and enforced via firewall
- No direct internet connectivity to Level 0/1/2 assets
- Firewall logs reviewed weekly
Estimated impact: Network segmentation is the single control most consistently cited in post-breach analyses as what would have contained the incident (source: CISA ICS-CERT incident analyses, 2023).
3. Implement Strict Remote Access Controls
What it is: A governed, auditable framework for all remote connections to OT assets, including vendor remote maintenance, IT administrator access, and engineering workstation sessions, using jump hosts, MFA, and just-in-time provisioning.
Why it reduces breach risk: Remote access is the most consistently exploited initial access vector in OT incidents. Persistent vendor credentials, unaudited VPN tunnels, and direct RDP connections to PLCs bypass every perimeter control.
How to implement:
- All remote access must traverse a jump server (privileged access workstation) in the OT DMZ, no direct tunnels to Level 2 assets.
- Enforce MFA for all human remote sessions; FIDO2 hardware keys preferred over SMS OTP.
- Implement just-in-time (JIT) vendor access, session credentials are provisioned for a defined window, recorded, and revoked automatically.
- Conduct quarterly audits of all active remote access accounts and VPN configurations. Disable any account with no recorded session in the preceding 90 days.
Quick checklist:
- All remote access routed through audited jump host
- MFA enforced on all remote authentication pathways
- Vendor access time-limited and session-recorded
- Remote access accounts reviewed quarterly
- No persistent vendor VPN credentials
Estimated impact: Eliminating standing vendor credentials reduces persistent access risk by removing the most common attacker persistence mechanism in OT environments.
Pitfall: Jump hosts without outbound internet access controls can themselves become lateral movement vectors.
4. Patch and Vulnerability Management Tailored to OT
What it is: A risk-based patching process that accounts for OT-specific constraints: limited maintenance windows, vendor qualification requirements, and the inability to patch many field devices without production interruption.
Why it reduces breach risk: Unpatched vulnerabilities are the most common exploit path. CISA’s Known Exploited Vulnerabilities (KEV) catalog includes a growing number of ICS-specific CVEs, prioritizing KEV entries on network-exposed assets is the minimum defensible standard.
How to implement:
- Cross-reference every identified vulnerability against the CISA KEV catalog. KEV-listed vulnerabilities on internet-exposed or IT/OT boundary assets are P1.
- Where patching is not feasible within the maintenance window, implement compensating controls: micro-segmentation, access list restrictions, and application whitelisting to reduce exploitability.
- Coordinate patch testing in a non-production environment or vendor staging configuration before production deployment.
- Maintain a firmware lifecycle register, current version, latest available, scheduled update date, for all critical assets.
Quick checklist:
- All assets cross-referenced against CISA KEV catalog monthly
- Compensating controls documented for every unpatched critical vulnerability
- Patch testing environment available or vendor staging process confirmed
- Firmware lifecycle register maintained and reviewed quarterly
- Patch windows coordinated with operations and approved via change management
Pitfall: Never apply firmware updates from unverified sources, validate checksums and obtain files directly from the vendor’s authenticated distribution channel.
5. Application Whitelisting on Critical Controllers and Hosts
What it is: Configuring engineering workstations, HMI servers, and where supported, controller endpoints to execute only explicitly approved applications, scripts, and executables.
Why it reduces breach risk: Most OT endpoints run a narrow, predictable set of applications. Whitelisting prevents unauthorized executables, malware, dual-use tools, ransomware droppers, from running even if they reach the endpoint through a phishing email or compromised USB device.
How to implement:
- Inventory all legitimate applications on each target endpoint before enabling whitelisting, unlisted applications will be blocked.
- Deploy a whitelisting tool compatible with the OT OS environment (many legacy HMIs run Windows Server 2008/2012, verify tool compatibility).
- Begin in audit mode for 30 days to identify legitimate processes before switching to enforcement mode.
- Establish a formal exception process: new application approvals require change management sign-off.
Quick checklist:
- Application inventory completed per endpoint before enforcement
- Whitelisting deployed in audit mode on highest-risk hosts
- Exception process documented and enforced
- USB media controls aligned with whitelisting policy
- Tested and validated in non-production before production rollout
Estimated impact: Application whitelisting prevents execution of the majority of commodity malware, estimated 70%+ of common threat actor initial access techniques rely on executing unsigned or unlisted binaries (source: MITRE ATT&CK for ICS, technique T0863).
6. Secure Configuration and Hardening of PLCs, RTUs, and HMI Systems
What it is: Applying security-focused configuration baselines to every OT asset, disabling unused services and communication ports, removing default credentials, enforcing authentication, and documenting the approved secure state.
Why it reduces breach risk: Default credentials, open management ports, and unnecessary services are the fastest exploitable weaknesses in any OT audit. CISA advisories consistently find these conditions in assessed environments.
How to implement:
- Reference vendor hardening guides and CIS Benchmarks where available for engineering workstation OS hardening.
- For PLCs and RTUs: disable unused communication protocols (Telnet, FTP, SNMP v1/v2), change all default credentials, and disable unused I/O expansion slots.
- Document the approved baseline configuration for each asset class and detect deviations via integrity monitoring.
- Validate configurations annually and after any maintenance event.
Quick checklist:
- Default credentials changed on all network-connected OT devices
- Unused ports and protocols disabled per asset type
- Configuration baseline documented for each asset class
- Configuration drift detection enabled
- Hardening validated by independent security review annually
7. OT Monitoring, Detection, and Protocol-Aware Logging
What it is: Deploying continuous monitoring tools capable of parsing OT-native protocols (Modbus, DNP3, EtherNet/IP, PROFINET, IEC 61850) to detect anomalous commands, unauthorized connections, and behavioral deviations without disrupting process control.
Why it reduces breach risk: IT SIEM platforms cannot interpret OT protocol context. An attacker issuing a malicious function code to a PLC looks like normal traffic to a generic network monitor, only a protocol-aware IDS flags it as anomalous.
How to implement:
- Deploy passive OT-aware monitoring (Claroty, Dragos, Nozomi Networks) with SPAN port access to key OT switch segments.
- Forward normalized OT alerts to your SOC SIEM alongside IT telemetry for unified detection.
- Establish baseline behavioral profiles for every monitored asset during a 30–60 day learning period before tuning alerts.
- Integrate monitoring alerts with incident response runbooks for specific ICS scenarios.
Quick checklist:
- OT-aware monitoring deployed on all critical segments
- Baseline behavioral profiles established
- OT alerts integrated into SOC detection workflow
- Protocol anomaly detection tuned to minimize false positives
- Alert-to-runbook mapping documented
Estimated impact: Organizations with OT-aware monitoring detect incidents an average of 45 days faster than those relying on IT monitoring tools alone (estimate based on Dragos 2023 Year in Review findings).
8. Incident Response and OT-Specific Tabletop Exercises
What it is: A documented, tested incident response plan that accounts for OT-specific constraints: safety system isolation, vendor notification requirements, forensic collection from live controllers, and process restart sequencing.
Why it reduces breach risk: Organizations that have tested their OT incident response plan contain incidents faster and with less collateral operational impact. The 2021 Colonial Pipeline incident demonstrated that IR plan gaps, not just technical failures, drove the scope of the operational impact.
How to implement:
- Develop OT-specific runbooks for the three highest-probability scenarios: ransomware affecting historian/SCADA servers, unauthorized PLC program modification, and vendor remote access compromise.
- Conduct tabletop exercises quarterly involving OT engineers, IT security, plant management, and legal/communications.
- Define explicit OT-safe isolation steps for each scenario, network isolation of a safety controller can be more dangerous than the attack itself.
Sample IR Playbook, Suspected Ransomware in ICS (Initial Containment):
- Do not power off PLCs or RTUs without operations engineering sign-off , abrupt shutdown may damage process or equipment.
- Isolate affected HMI/SCADA servers at the OT DMZ firewall, disable routing rules, not physical disconnection.
- Activate OT incident commander and notify plant operations lead immediately.
- Preserve memory images and event logs from affected engineering workstations before any remediation.
- Verify safety instrumented systems (SIS) are operating normally and isolated from compromised network segments.
- Notify CISA (US) or national ICS-CERT equivalent per sector-specific regulatory obligations.
- Engage OT vendor emergency support contacts per pre-established vendor response SLAs.
- Begin forensic collection from network taps and OT monitoring platform, do not touch live controller memory without vendor guidance.
9. Supply Chain and Third-Party Risk Management
What it is: Structured security requirements applied to OT vendors, integrators, firmware suppliers, and managed service providers throughout the procurement, deployment, and maintenance lifecycle.
Why it reduces breach risk: Supply chain attacks targeting OT vendors, compromised software updates, malicious firmware, rogue maintenance tools, bypass most perimeter controls by arriving through trusted channels. The SolarWinds and 3CX supply chain incidents demonstrated the mechanism at scale.
How to implement:
- Require vendors to provide a Software Bill of Materials (SBOM) for firmware and engineering software as a contract condition.
- Validate firmware integrity via cryptographic checksum before deployment, obtain files from vendor-authenticated channels only.
- Conduct annual vendor security assessments for all third parties with remote or physical access to OT systems.
- Implement a formal contractor onboarding process: background check, security training acknowledgment, and access scoped to minimum required assets.
Quick checklist:
- SBOM requirements included in all OT vendor contracts
- Firmware checksum validation process documented and enforced
- Annual security assessments for all high-access vendors
- Contractor access scoped and time-limited
- Vendor incident notification SLAs defined contractually
10. OT Governance, Training, and Least Privilege
What it is: The organizational and procedural framework supporting all technical controls: role-based access control (RBAC), operational change management, security awareness training specific to OT threats, and executive governance structures.
Why it reduces breach risk: Technical controls fail when organizational controls are absent. Improperly managed user accounts, change management bypasses, and untrained operators who click phishing links targeting engineering workstations undermine every technical investment.
How to implement:
- Apply least privilege to all OT accounts: operators have read access; engineers have written access to their authorized assets only; no shared accounts.
- Conduct OT-specific security awareness training annually, include social engineering scenarios relevant to plant floor personnel (USB drops, phishing targeting vendor invoice approvals).
- Integrate OT security reviews into the management-of-change (MOC) process, every network or configuration change requires security impact assessment before approval.
- Establish a cross-functional OT Security Steering Committee with representation from OT engineering, IT security, procurement, and executive leadership.
Quick checklist:
- All shared OT accounts eliminated or documented with compensating controls
- Role-based access control implemented on all engineering workstations and SCADA systems
- OT-specific security training completed by all plant staff annually
- Security review integrated into MOC process
- Executive OT security governance cadence established (quarterly minimum)
Mini Case Study: Regional Water Authority Hardens OT in 90 Days
Hypothetical illustration based on representative industry practices.
A regional water utility serving 400,000 customers identified critical gaps during a CISA-style assessment: no asset inventory, flat network between SCADA and corporate IT, and 14 active vendor VPN credentials with no session logging.
Over 90 days, the IT/OT security team executed a focused program:
- Weeks 1–4: Deployed passive OT monitoring on four critical network segments, generating a baseline asset inventory of 312 devices, 47 of which were previously undocumented.
- Weeks 5–8: Implemented OT DMZ with firewall segmentation between corporate and SCADA networks. Reduced active vendor credentials from 14 to 3 via JIT provisioning.
- Weeks 9–12: Completed application whitelisting in audit mode on all HMI servers; deployed jump host for all remote access; conducted first OT tabletop exercise with plant operations and IT teams.
Outcomes: MTTD for network anomalies reduced from unmeasured to under 6 hours. All vendor access now logged and auditable. Zero critical production interruptions during the implementation. Two previously unknown legacy PLCs identified and scheduled for firmware update during next planned maintenance shutdown.
Key lesson: Starting with passive discovery before any active security change prevented the disruptions that had stalled previous security initiatives at the site.
Quick Reference Table
| Best Practice | Primary Owner | Effort | Primary KPI |
| Asset Discovery & Inventory | OT/IT joint | Medium | % assets inventoried and classified |
| Network Segmentation | IT/OT Architecture | High | Zero direct IT-to-Level 2 paths |
| Remote Access Controls | IT Security + OT Ops | Medium | % sessions with MFA + recording |
| Patch & Vulnerability Mgmt | OT Engineering + IT Sec | Medium | % critical KEV CVEs with active plan |
| Application Whitelisting | OT Engineering | Medium | % critical hosts in enforcement mode |
| Secure Configuration/Hardening | OT Engineering | Low–Medium | % assets with documented baseline |
| OT Monitoring & Detection | IT Security/SOC | High | MTTD for OT anomalies (target: <24h) |
| Incident Response & Tabletops | CISO + OT + Operations | Medium | Tabletop exercises/year (target: 2+) |
| Supply Chain Risk Management | Procurement + CISO | Medium | % key vendors with annual assessment |
| Governance, Training, Least Privilege | CISO + HR + OT Mgmt | Low | % OT staff with annual training complete |
Metrics and KPIs to Track
- % OT assets inventoried with firmware version and criticality documented
- Mean time to detect (MTTD) OT network anomalies
- % critical KEV vulnerabilities with documented mitigation plan within 30 days
- % remote access sessions with MFA enforced and recorded
- Number of vendor security assessments completed annually
- Tabletop exercises conducted per year (target: minimum two per site)
- % OT staff completing annual security awareness training
Conclusion
Implementing these ten OT security best practices is not a one-time project, it is a program that compounds in value over time. Each practice reinforces the others: a complete asset inventory makes vulnerability management accurate; network segmentation makes monitoring efficient; incident response training makes detection investments actionable.
The organizations that consistently outperform on OT security share a common characteristic: executive-level governance that treats OT security as an operational resilience investment, not an IT project. Safety, uptime, and security are not competing priorities in a well-governed OT security program, they are aligned objectives that a structured, cross-functional approach delivers simultaneously.
Start with passive discovery and remote access hardening this quarter. Build from there.