OT Security Checklist: 15 Steps to Harden Your SCADA System
In 2025, the Venice flood control system was breached. The post-mortem revealed what OT security professionals already knew: exposed HMIs, default credentials, no network segmentation, zero monitoring. The breach was not sophisticated. It was negligent.
This checklist is what should have been in place. It is not theoretical — every item comes from real breach analysis, IEC 62443 best practices, and SCADA operators who have been through audits. Print it. Share it. Use it.
1. Access Control (Critical)
Eliminate Default Credentials
Every device, every HMI, every system must have unique credentials set before deployment. Default admin/admin on a PLC is an open door. This was the primary vector in the Venice breach.
Enforce Role-Based Access Control
Not everyone needs admin access. Define roles: operators see the dashboard, supervisors can acknowledge alarms, only administrators change configuration. Log every access level change.
Use Strong, Modern Authentication
Argon2 or bcrypt password hashing. No MD5, no SHA-1. For enterprise: SSO via Active Directory, Azure AD, or SAML 2.0. Centralize identity management so you can revoke access instantly when someone leaves.
2. Network Security (Critical)
Segment OT from IT Networks
Your SCADA system should not be reachable from the corporate network without a firewall or DMZ. The Purdue Model exists for a reason. Whether your system runs on-premise or in the cloud, IT updates break OT systems — keep them separated.
Close Unnecessary Ports and Services
Only expose what is needed. A Modbus TCP device needs port 502. It does not need SSH, HTTP, or Telnet open to the world. Audit every listening port on every device.
Use Unidirectional Gateways for High-Security Zones
For critical infrastructure, consider data diodes or unidirectional security gateways (like Waterfall). Data flows out for monitoring. Nothing flows in. No remote access possible.
3. Monitoring & Logging (High Priority)
Log All Security Events
Failed logins, configuration changes, device connect/disconnect, access attempts with source IP and user agent. Store these in an append-only log separate from operational data. This is IEC 62443 compliance.
Set Alert Thresholds for Suspicious Activity
5 failed logins in 10 minutes from the same IP. Config change at 3 AM. Device disconnect during peak hours. Define what "normal" looks like and get notified when it is not.
Prefer Passive Monitoring Over Active Scanning
Active network scanning has knocked OT devices offline before. Monitor passively: read register values, log state changes, watch traffic patterns. Do not scan.
Export Security Logs for External Audit
Your security logs should be exportable as CSV for external audit tools and compliance reporting. IEC 62443, NIS2, and FDA CFR Part 11 all require auditable security records.
4. System Hardening (High Priority)
Keep Firmware Updated (But Carefully)
Most control systems run several versions behind on firmware. Track firmware versions across all devices. Plan updates during maintenance windows. Test on a staging system first. Never update production blind.
Minimize Attack Surface
Single-binary systems have a smaller attack surface than multi-service stacks. No Java runtime means no JVM CVEs. No external database means no SQL injection vectors. No Docker daemon means no container escape. Simpler is safer — and easier to deploy in high-availability configurations.
Use Memory-Safe Languages
Rust eliminates entire classes of vulnerabilities: buffer overflows, use-after-free, null pointer dereference. If your SCADA vendor runs on C/C++ or Java, ask about their memory safety strategy. This is not theoretical — CVE databases are full of memory-safety exploits.
5. Operational Practices (Medium Priority)
Run Read-Only by Default
Monitoring systems should be passive by default. Polling registers, reading values, displaying dashboards. Write commands to PLCs should be an explicit opt-in per device, with audit logging for every write operation.
Document Everything for Compliance
IEC 62443, NIS2, FDA CFR Part 11 — they all require documentation. Asset inventory, firmware versions, network diagrams, access logs, incident response procedures. If it is not documented, it does not exist for auditors.
What Voltrus Does for You
Several items on this checklist are built into Voltrus because they should not be optional:
- No default credentials — Voltrus requires password setup on first run
- RBAC with audit trail — Admin, Operator, Viewer roles with full action logging (Professional and Enterprise)
- Argon2 password hashing — modern, resistant to GPU-based attacks
- SSO via AD, Azure AD, Okta, SAML 2.0 — centralize identity management (Enterprise)
- IEC 62443 security audit mode — failed logins, config changes, device events, configurable alert thresholds, append-only logs, CSV export (Enterprise)
- Passive by default — monitoring is read-only. Write commands require explicit device-level opt-in
- Single binary, Rust-built — minimal attack surface, memory-safe, no JVM, no external database
- Air-gap friendly — runs completely offline with no phone-home, no cloud dependency
The Quick Reference
Print this and put it on the wall of your control room:
- No default credentials. Ever.
- Role-based access with logging.
- Segment OT from IT.
- Close unnecessary ports.
- Log all security events.
- Set alert thresholds.
- Monitor passively, do not scan.
- Keep firmware updated (test first).
- Minimize attack surface.
- Prefer memory-safe systems.
- Read-only by default.
- Document for compliance.
Frequently Asked Questions
What is the most important OT security measure for SCADA?
Eliminating default credentials is the single most critical step. Default admin/admin logins on PLCs and HMIs are the primary attack vector in real OT breaches, including the 2025 Venice flood control incident. Every device must have unique, strong credentials set before deployment. This is the foundation that all other security measures build on.
How do you segment OT and IT networks for SCADA security?
Use firewalls or DMZs to separate the SCADA/OT network from the corporate IT network, following the Purdue Model. Only expose necessary ports (e.g., port 502 for Modbus TCP). Close SSH, HTTP, and Telnet on OT devices. For critical infrastructure, consider unidirectional gateways (data diodes) that allow monitoring data to flow out but prevent any inbound access.
What is IEC 62443 compliance for SCADA systems?
IEC 62443 is the international standard for industrial automation security. It requires role-based access control, security event logging, append-only audit trails, configurable alert thresholds, and documented incident response procedures. Compliance also requires asset inventory, firmware version tracking, and the ability to export security logs for external audit.
Why should SCADA systems use passive monitoring?
Active network scanning can knock OT devices offline — a serious risk in production environments. Passive monitoring reads register values and logs state changes without sending discovery probes or scanning packets. SCADA systems should be read-only by default, with write commands to PLCs requiring explicit opt-in per device and full audit logging for every write operation.
Why does memory safety matter for SCADA software?
SCADA software written in C or C++ is vulnerable to buffer overflows, use-after-free, and null pointer dereference — entire classes of exploits that fill CVE databases. Rust eliminates these by design through its ownership model and compile-time checks. A single-binary Rust application also has a smaller attack surface than multi-service stacks with Java runtimes, external databases, or Docker daemons.
Security Built In, Not Bolted On
Voltrus ships with IEC 62443 security audit mode, RBAC, modern authentication, and passive monitoring. No add-ons. No extra modules. Enterprise tier from $999 lifetime.
View Enterprise Tier