Aevus Learn · OT Security · 11 min read

SCADA Cybersecurity Essentials. The controls that move the needle in 2026.

NIST SP 800-82 and IEC 62443 between them run hundreds of pages of guidance. Most of it matters — eventually. This article distills the controls that actually move the needle on OT cybersecurity posture today, in priority order, with an honest accounting of what's easy, what's hard, and what's mostly theater.

Aevus / Intrepid LogicIntermediateFor OT security professionals · engineersUpdated 2026-05-21

The shape of the threat in 2026

Three classes of OT cybersecurity threat dominate the actual incident reports:

  1. Ransomware crossing IT→OT. The attacker's goal isn't ICS — they want to encrypt enterprise files. But because OT and IT share Active Directory, share credentials, share file servers, and share engineering workstations, the ransomware propagates into OT and shuts the plant down even though that wasn't the intent. This is the most-frequent OT incident in 2025-26.
  2. Vendor remote-access abuse. Maintenance vendors have remote access for legitimate support. Their credentials get phished, harvested, or sold. Attacker enters via the legitimate path. Stuxnet's modern descendants live here.
  3. State-actor reconnaissance and pre-positioning. Volt Typhoon, Cyber Av3ngers, and named state-aligned campaigns explicitly target US critical infrastructure for future leverage, not immediate disruption. CISA has been increasingly explicit about this.

The high-leverage controls — in priority order

1. Asset inventory (you cannot secure what you cannot enumerate)

Every OT cybersecurity framework starts here. Most operators don't have a complete one. A modern asset inventory tool (Dragos, Claroty, Nozomi, Tenable OT, Microsoft Defender for IoT) passively discovers devices on the OT network and builds an inventory by listening to protocol traffic. This is the single highest-ROI control because every other control depends on it.

2. Network segmentation (IEC 62443 zones and conduits)

Logical separation between IT, DMZ, supervisory OT, and control OT. Implemented with firewalls (industrial-grade — TXOne, Fortinet, Palo Alto, Cisco ISA-series) and rigorous traffic policy. Reduces blast radius when (not if) something gets compromised.

3. Privileged remote-access broker

Replace flat VPNs into OT with a session-brokered, MFA-required, time-limited, recorded remote-access channel. Industrial-PAM products (BeyondTrust, Cyberark, Cisco Secure Equipment Access) sit between vendor engineers and the OT network. Closes the single largest unmanaged access vector.

4. Identity hygiene

No shared admin accounts on engineering workstations. No "OperatorAdmin" with the same password since 2014. MFA on every privileged action. AD or equivalent IdP integrated across IT and OT, with OT-specific groups and least-privilege roles.

5. Continuous monitoring with OT-native tooling

The asset-inventory tools above also do passive intrusion detection — they know what normal protocol traffic looks like on your network and alert on deviations. SIEM integration so anomalies trigger response, not just dashboards.

6. Backup and recovery — separately for OT

OT systems often share backup infrastructure with IT. When ransomware encrypts the backup server, both worlds lose. OT recovery posture should include immutable, offline backups of PLC programs, HMI configurations, alarm rationalization databases, and historian data — separate from IT backups.

7. Patch and firmware lifecycle

The unglamorous one. Industrial systems patch on quarterly maintenance schedules at best, never at worst. Building a defensible patch-management posture for OT requires coordination with the production schedule, vendor SLA negotiation, and explicit decision-making about which CVEs require emergency action.

What's mostly theater

Honest framing: not every "OT cybersecurity" control is high-value. A short list of common controls that look impressive but don't actually move the threat dial:

  • Antivirus on legacy HMI workstations. Often actively destabilizes HMI software. Better: application allowlisting (Carbon Black, Microsoft Defender Application Control) and aggressive patching of the underlying OS.
  • "OT firewall" appliances that aren't OT-protocol-aware. A firewall that doesn't understand Modbus or OPC UA can't enforce protocol-level policy. It's just a firewall, in an industrial form factor.
  • "AI-powered threat detection" that's a wrapper on standard SIEM rules.The "AI" claim is overused in this space. Ask vendors specifically what their model is trained on and what false-positive rate they've validated on real industrial traffic.
  • Annual penetration tests that don't change anything. A pen test that produces a 200-page report and nothing changes is a compliance artifact, not a security improvement. Pair pen tests with remediation budgets that can actually act on findings.

The framework cheat sheet

FrameworkMaintained byWhere it's required
NIST SP 800-82NISTFederal facilities; widely adopted commercially
NIST CSF 2.0NISTCross-sector framework; CISA-aligned
IEC 62443IEC + ISAInternational OT standard; most rigorous
NERC CIPNERCBulk electric system (US)
PHMSA cybersecurity rulesPHMSAPipelines
EPA water-sector cyber rulesEPAWater utilities (rulemaking still evolving)
CMMC 2.0DoDDoD contractors handling CUI
FERC Order 850FERCBulk electric supply chain

How Aevus fits

Aevus is not an OT cybersecurity product. It's an operational-intelligence layer that must operate safely inside an OT cybersecurity posture. The architectural property that makes this defensible is IL-9000 — the Aevus AI is architecturally incapable of writing to your field equipment, enforced at the cloud account boundary. This is the property federal evaluators ask about first. See also our Zero Trust for OT article for the deeper framing.

OT cybersecurity, the practical version.

If your team is shaping your OT cyber posture and wants an AI augmentation layer that respects the boundary, Aevus is built for that conversation.