Secure SCADA for OT Networks:
IEC 62443 Buyer's Guide (2026)

Back to Blog

What Are the Most Secure SCADA Options for OT Networks?

The most secure SCADA options for OT networks share five architectural characteristics: no open inbound firewall ports (outbound-only gateway connectivity), role-based access control enforced with multi-factor authentication, tamper-evident audit logging of every user action, security event export to a SIEM, and an air-gapped on-premise deployment option for the most restrictive environments. No vendor is secure by brand name - security is a property of architecture and operational discipline, which is why IEC 62443 assesses systems and processes, not logos. For the deeper US-government treatment of the same architecture principles, see NIST SP 800-82 Rev. 3, the Guide to Operational Technology Security.

That said, architecture choices made at design time matter enormously. Platforms designed in the 1990s and 2000s assumed a trusted plant LAN: flat networks, Windows domain authentication, and remote access bolted on later through port forwarding or VPNs. Cloud-era platforms like Merobix were designed after Stuxnet and the rise of internet scanning tools like Shodan, so they start from the assumption that any inbound path into the OT network will eventually be found and attacked - and eliminate those paths entirely.

Many established SCADA platforms run mature security programs, publish hardening guides, and can be deployed to a strong security posture. The difference is how much configuration and integrator discipline it takes to get there. A platform that is secure by default - MFA on, RBAC on, no inbound ports possible - removes the most common failure mode in OT security: the correctly designed system that was never correctly configured.

IEC 62443: The Standard That Defines "Industrial-Grade" Security

When buyers search for SCADA vendors with industrial-grade cybersecurity, IEC 62443 is the yardstick that phrase actually refers to. It is the international series of standards for industrial automation and control system (IACS) security, and it splits responsibility three ways: component and software vendors (62443-4), system integrators and system-level requirements (62443-3), and asset owners' policies and procedures (62443-2).

The most useful concept for a buyer is the security level (SL) - a rating of the attacker the system is designed to resist:

Security Level	Protects Against	Typical Environment
SL1	Casual or coincidental violation - misconfiguration, curious employees	Minimum baseline for any industrial system
SL2	Intentional attack using simple means and low resources - commodity malware, opportunistic scanning	Most oil and gas, manufacturing, and utility operations
SL3	Sophisticated attack with moderate resources and IACS-specific knowledge - organized crime, ransomware crews	Pipelines, larger utilities, chemical facilities
SL4	Attack with extended resources and sophisticated means - state-level actors	Critical national infrastructure

Compliance with IEC 62443 is not legally mandatory for most private US operators, but it increasingly appears in customer contracts, cyber-insurance questionnaires, and sector regulation (TSA pipeline security directives, America's Water Infrastructure Act). The practical buyer question is not "are you certified?" - full certification is still rare across the industry - but "which security level is your architecture designed to support, and against which parts of 62443-3-3 have you assessed it?" A vendor who cannot answer that question has not done the work.

Network Segmentation: Zones, Conduits, and the Purdue Model

Segmentation is the foundation every other control sits on. The Purdue model divides an industrial network into levels - field devices and I/O at Levels 0–1, control systems and HMIs at Levels 2–3, a demilitarized zone (DMZ) at Level 3.5, and business IT at Levels 4–5. IEC 62443 generalizes this into zones (groups of assets with common security requirements) and conduits (the controlled communication paths between them).

The rules that matter in practice:

• No direct path from the internet or corporate IT to a PLC. Every crossing between zones goes through a firewall with explicit, minimal rules.
• OT traffic should originate outbound. Data leaves the OT zone through the DMZ; nothing on the outside initiates connections inward.
• Flat networks are the enemy. If a laptop in the office can ping a PLC, one phishing email away is a process upset.

This is where SCADA architecture either helps or hurts. A platform that requires inbound connections to an OT-resident server forces you to punch holes in the segmentation you just built. A platform whose gateway initiates all connections outbound fits the zone-and-conduit model without exceptions.

Best Security Gateways for SCADA and ICS Environments

The best security gateway for a SCADA or ICS environment is one that makes only outbound, TLS-encrypted connections - so the OT firewall can be set to deny all inbound traffic, permanently. Internet-exposed inbound ports (VNC, RDP, HMI web servers, Modbus TCP forwarded straight to a PLC) remain the single most common way industrial systems get compromised; scanning tools index them within hours of exposure.

Attribute	Open Inbound Port / Port Forwarding	VPN-Based Access	Outbound-Only Gateway
Inbound firewall rules required	Yes - permanently exposed	Yes - VPN concentrator exposed	None
Attack surface visible to internet scans	Full service exposed	VPN endpoint (frequent CVE target)	Nothing listening
Credential theft impact	Direct device access	Full network access once inside	Platform access only, governed by RBAC
Works over cellular / dynamic IP	Poorly (needs static IP)	Sometimes (keepalive issues)	Yes - designed for it
Ongoing IT maintenance	Low but dangerous	High - patching, certs, user churn	Minimal
IEC 62443 zone/conduit fit	Violates the model	Acceptable with compensating controls	Aligns naturally

The Merobix gateway works on the outbound-only model: a small device ($300–$800) sits inside the OT network, polls PLCs, RTUs, and flow computers locally over Modbus, EtherNet/IP, and the platform's other drivers - drivers for the major industrial protocols (Modbus, DNP3, OPC UA, EtherNet/IP, Siemens S7, and MQTT) - and pushes encrypted data outbound to the platform. Zero inbound firewall rules, no static IP, no VPN concentrator to patch, and it behaves the same on plant ethernet or a cellular modem in the Permian Basin.

At the top of the security range (SL3–SL4 environments such as nuclear or defense), hardware data diodes enforce one-way data flow physically rather than logically. They are the gold standard for unidirectional monitoring, but cost thousands of dollars per link and rule out any remote configuration - most operators reserve them for the small number of conduits that genuinely require them.

SCADA Systems with Role-Based Access Control (RBAC)

Role-based access control means every user gets a named account with a role that defines exactly what they can see and do - which sites, which screens, which setpoints, and whether they can write to the process at all. In OT, RBAC matters most on the control path: a contractor who needs to view compressor trends should not inherit the ability to change a shutdown setpoint. Shared "operator" logins, still common on legacy HMIs, make incident forensics impossible and violate the least-privilege requirement in every security framework.

What to look for, in ascending order of maturity:

• Named accounts with per-role, per-site permissions - the baseline. Read-only roles for managers and auditors; control permissions restricted to qualified operators.
• Multi-factor authentication on every remote login, not as a paid add-on. A password alone protecting process control is no longer defensible.
• Enterprise identity integration - LDAP/SAML single sign-on so accounts deactivate the moment an employee leaves, plus RADIUS and FIDO2 hardware keys for phishing-resistant authentication.
• Session controls - automatic timeout, concurrent-session limits, and re-authentication for critical commands.

Merobix ships RBAC and MFA as standard platform behavior, and the Enterprise plan adds LDAP/SAML SSO, RADIUS, FIDO2 hardware keys, and zero-trust access policies - the full matrix is on the plans page. Most SCADA platforms support role-based security, typically through gateway configuration or Windows Active Directory integration; the evaluation question is how much of it is enforced by default versus left to the integrator.

Audit Logging and SIEM Export: Proving What Happened

When a setpoint changes at 2 AM, you need to know who changed it, from where, and what the previous value was. A security-grade audit log records every login, failed login, configuration change, setpoint write, and alarm acknowledgment against a named user, with timestamps that cannot be edited after the fact. This is what turns a security incident from a mystery into a timeline - and it is what regulators and insurers ask for first.

The next step up is SIEM integration: streaming those security events into the same Splunk, Sentinel, or QRadar console your IT security team already watches, so OT stops being a blind spot in enterprise monitoring. Merobix logs every user action platform-wide, and the Enterprise plan adds SIEM export alongside its zero-trust integrations and hot standby redundancy. Alarm delivery itself is part of the security story too - Merobix pushes SMS and email alerts typically within a minute, so an intrusion-related process anomaly reaches a human before it becomes an incident.

Air-Gapped and On-Premise Deployment

Some facilities - by policy, regulation, or risk appetite - will not connect OT data to the cloud at all. For them, the deciding question is whether a modern platform can run entirely inside the fence. Merobix is sold both ways: the same platform that runs cloud-hosted can be installed on customer servers or virtual machines on-premise, fully air-gapped compatible, with complete data residency. You keep the modern web interface, historian, and alarm engine without any external dependency.

Be honest about the trade-offs before choosing the air gap. You give up remote access from outside the gap, vendor-managed patching becomes a controlled offline update process, and redundancy is your responsibility (Enterprise deployments support hot standby redundancy for exactly this reason). Many operators land on a hybrid: safety-critical control stays isolated, while a read-only data path mirrors process data outward for remote monitoring. Our cloud vs on-premise SCADA comparison works through the decision in detail.

The Patch Reality: The Biggest Risk Is the Update You Never Applied

Most OT compromises do not use zero-days - they use years-old vulnerabilities on systems nobody dared to patch because "the SCADA server is working, don't touch it." On-premise SCADA servers routinely run end-of-life operating systems because upgrading means downtime, revalidation, and risk. That is the quiet security argument for vendor-managed platforms: with cloud-hosted Merobix, the platform is patched continuously by the vendor, and every release is validated against a suite of 2,000+ automated tests before it ships - the full engineering practice is documented on our security page. If you run on-premise or air-gapped, the discipline transfers to you: schedule offline updates, and make "when was this last patched?" a standing agenda item. If you are replacing a legacy system that can no longer be patched at all, start with our SCADA migration guide.

What to Ask SCADA Vendors: The OT Security Checklist

Take these ten questions into every vendor evaluation. The answers separate marketing from architecture in about fifteen minutes:

1. What inbound firewall rules does your architecture require? The right answer is "none."
2. Which IEC 62443 security level is the system designed to support? Ask which 62443-3-3 requirements they have assessed against.
3. Is MFA available on every account, and is it on by default? Not an Enterprise-only checkbox for basic logins.
4. Does RBAC govern control actions - setpoint writes and commands - or only screen visibility?
5. Can I integrate with LDAP/SAML SSO so departing employees lose access immediately?
6. Is every user action audit-logged against a named account, and can I export those events to my SIEM?
7. How is data encrypted in transit and at rest? TLS versions and certificate management, not just "yes."
8. Who patches the platform, how often, and how are releases tested?
9. Can the platform run fully on-premise or air-gapped if our policy requires it? With what feature loss?
10. What happens during a connectivity or server failure? Store-and-forward at the gateway, redundancy options, and the uptime SLA in writing.

Frequently Asked Questions