Remote access is how most industrial intrusions start. Exposed remote desktop services, port-forwarded HMIs, and unpatched VPN appliances are the front doors attackers actually walk through - not exotic zero-days. Yet operators cannot simply give up remote access: unstaffed well pads, lift stations, and compressor sites make it operationally essential. This guide compares the four remote access patterns used in SCADA today - port forwarding, VPNs, jump hosts, and outbound-only architecture - explains why the VPN appliance has become one of the most attacked devices on the internet, and lays out how to govern employee and vendor access with MFA, least privilege, session controls, and audit trails that hold up in an investigation.
Explore the full security & certification article series - 60+ practitioner guides.
The short answer first: the most secure remote access for SCADA is an outbound-only architecture - a gateway inside the OT network initiates every connection outward over TLS, so no inbound firewall rule, VPN concentrator, or listening service exists for attackers to find. The rest of this guide shows why the alternatives keep failing.
The uncomfortable pattern across publicly reported industrial incidents is how ordinary the entry point usually is. The 2021 Oldsmar water treatment event reportedly involved remote desktop software reachable from outside - the joint federal advisory AA21-042A singled out desktop-sharing software as the underlying risk. Colonial Pipeline's 2021 shutdown, the incident behind CISA's DarkSide ransomware advisory (AA21-131A), reportedly began with a compromised VPN credential on an account without MFA. Search engines for internet-connected devices index exposed HMIs, VNC servers, and PLC protocols continuously - an accidentally port-forwarded service is typically discovered by scanners within hours, not months.
Remote access sits at the worst possible intersection: it is operationally indispensable (nobody staffs a remote well pad around the clock) and architecturally dangerous (every access path is, by definition, a path into the control network). The question is not whether to allow remote access but which pattern gives you the operational capability with the smallest attack surface. There are four patterns in real-world use, and they are not equally safe.
Almost every SCADA remote access deployment is one of these four, sometimes layered:
| Attribute | Port Forwarding / Exposed Services | VPN | Jump Host / Bastion | Outbound-Only Platform |
|---|---|---|---|---|
| Internet-visible attack surface | The service itself - HMI, RDP, VNC | VPN concentrator (frequent CVE target) | Bastion endpoint (still inbound) | Nothing listening |
| Access granted on login | Direct device access | Network-level - often far too broad | One host, then onward hops | Application-level, governed by roles |
| Stolen credential impact | Immediate device control | Inside the network perimeter | Inside the bastion; segmentation decides the rest | One account's scoped permissions, behind MFA |
| Patching burden on you | Every exposed service | Continuous - appliance CVEs are exploited fast | Bastion OS + tooling | Gateway updates only; platform patched by vendor |
| Audit quality | Usually none | Connection logs only, not actions | Needs session recording bolted on | Per-action audit trail, named users |
| Fit for IEC 62443 zones/conduits | Violates the model | Acceptable with compensating controls | Acceptable with discipline | Aligns naturally |
| Appropriate use in 2026 | Never | Legacy engineering access, tightly governed | Interactive engineering on OT-resident systems | Monitoring and control operations |
Port forwarding deserves no further analysis: exposing an HMI, RDP, VNC, or a raw industrial protocol to the internet is indefensible in 2026 - eliminating such exposure tops the NSA/CISA joint alert on reducing exposure across operational technologies (AA20-205A) - and it remains alarmingly common - our post on exposed HMIs and internet-facing SCADA covers how these exposures happen and how to find yours before someone else does.
VPNs were the responsible answer for two decades, and they are still better than exposed services. But the threat landscape has turned against them in three ways.
If you must run a VPN for legacy access, run it well: MFA mandatory on every account, aggressive patching SLAs on the appliance, per-user network segmentation behind the tunnel, quarterly account reviews, and logging shipped somewhere an analyst will actually look.
A jump host (bastion) narrows the funnel: remote users land on one hardened, monitored machine, and only that machine may reach into the control network. This is a genuine improvement - one auditable choke point, one system to harden, a natural place for session recording - and it remains the right pattern for interactive engineering work on OT-resident systems, such as PLC programming through vendor tools.
But a bastion still requires an inbound path from outside to the bastion, so you still have an internet-facing endpoint to defend. Everything depends on the discipline around it: if the bastion is behind the same aging VPN, or if "temporary" direct paths bypass it, the choke point is theater. And bastions serve engineering, not operations - an operations manager who needs to check tank levels at 10 PM should not be RDP-hopping through a bastion to reach an HMI. That mismatch is what pushes organizations toward pattern four.
The outbound-only pattern inverts the problem. Instead of letting users connect into the OT network, a gateway inside the network connects out: it polls PLCs, RTUs, and flow computers locally, then initiates TLS-encrypted connections outward to the platform. The OT firewall denies all inbound traffic, permanently. There is no listening service, no port to forward, no VPN concentrator to patch, no static IP requirement.
Remote users never touch the plant network at all. They authenticate to the cloud platform - which is where the security controls live - and the platform relays only what each user's role permits. This is the model zero-trust architecture - formalized in NIST SP 800-207 - prescribes: identity-first access to specific functions, never network-level access. The Merobix gateway is built this way, and the identity layer on top is what makes it operationally safe:
The same architecture is why remote sites on cellular connections work without heroics - no static IPs or inbound reachability needed, with store-and-forward buffering riding out outages. We cover that scenario in detail in our guide to cellular SCADA gateway security.
Vendor access deserves its own paragraph in your security policy - CISA and its partners published a dedicated Guide to Securing Remote Access Software because this is where remote access governance most often fails. The integrator who commissioned the system still has a tunnel. The pump OEM's support team shares one login among twelve technicians. Nobody is sure whether the SCADA vendor itself can reach production. The rules that fix this:
Ask your SCADA vendor the mirror-image questions about their own staff: who at the vendor can access your production environment, under what controls, and where is that access logged? A good vendor answers precisely; the Merobix security page documents how platform access, tenant isolation, and audit controls are enforced.
Whatever pattern you run, assume an investigator will one day ask: who was connected that night, and exactly what did they do? Connection logs alone cannot answer the second half. For jump-host access, the standard compensating control is full session recording - video capture of the remote desktop - because the tools underneath do not log actions natively. It works, but it produces an archive you can only scrub through, not search.
Platform-mediated access changes the economics of evidence. When every action flows through an API, the audit trail is the session recording: logins and failures, screens viewed, every setpoint write with old and new values, command dispatch and acknowledgment, all attributed to a named user with timestamps. Merobix keeps immutable, chained audit records for sensitive events - records that even an administrator cannot silently rewrite - and its runtime monitoring watches for the patterns that precede misuse: repeated authentication failures, privilege probes, and suspicious control activity, with alerts delivered durably to email, SMS, webhook, or SIEM. That is a searchable, verifiable account of every remote session, produced as a side effect of the architecture.
Key takeaway: Rank the patterns and be honest about where you stand. Exposed services: never. VPN: legacy tool, acceptable only with MFA, fast patching, and real segmentation. Jump host: right for interactive engineering, still an inbound door. Outbound-only: the only pattern with no inbound attack surface at all - remote users get identity-checked, role-scoped, fully audited access to functions, never to your network. Ask every SCADA vendor which pattern they require; the answer tells you how much of their security burden becomes yours. Merobix requires zero inbound rules - see it live in a demo.
The most secure remote access pattern for SCADA is an outbound-only architecture: a gateway inside the OT network initiates all connections outward over TLS, so the firewall denies every inbound connection and nothing is listening for internet scanners to find. Users then authenticate to a hardened cloud platform - with MFA, role-based access, and full audit logging - rather than to anything inside the plant. This removes the exposed VPN concentrators, port forwards, and remote desktop services that account for most real-world ICS intrusions. Merobix is built on this model: its gateway makes only outbound TLS connections, and no inbound firewall rules or VPN are required.
VPNs create three structural risks for SCADA. First, the VPN concentrator itself is an internet-facing appliance, and VPN products have suffered a steady stream of critical, actively exploited vulnerabilities in recent years - patching them is now an operational treadmill. Second, a VPN typically grants network-level access: once connected, a user or attacker can reach far more of the OT network than their job requires, unless painstaking internal segmentation exists. Third, VPN credential and account sprawl is hard to govern - contractor and vendor VPN accounts routinely outlive their engagements. VPNs can be operated securely, but they demand continuous patching, strict segmentation, MFA, and disciplined account lifecycle management.
Outbound-only SCADA architecture means the equipment inside the OT network never accepts inbound connections. A gateway device sits inside the plant network, polls PLCs, RTUs, and flow computers locally, and pushes data outward over TLS-encrypted connections that the gateway itself initiates. The OT firewall can therefore deny all inbound traffic permanently - there is no listening port, no static IP requirement, and no VPN concentrator to patch. Remote users interact with the cloud platform, never directly with plant devices, and every action passes through the platform's authentication, role checks, and audit trail. The Merobix gateway works exactly this way.
Vendor access should be individually named, least-privilege, time-bounded, and fully audited. Every vendor technician gets their own account - never a shared vendor login - scoped to only the sites and functions their work requires, with MFA enforced. Access is granted for the engagement and revoked when it ends, which access reviews should verify quarterly. All vendor activity should land in the same audit trail as employee activity, attributed to the named individual. Avoid standing vendor VPN tunnels into the OT network; platform-mediated access through an outbound-only architecture lets vendors see and do exactly what their role allows without ever holding a network path into the plant.
Every remote session should at minimum produce a complete, attributed audit record: who logged in, from where, what they viewed, and every change or command they issued with old and new values. For screen-sharing and jump-host style access - where a remote user drives a desktop inside the OT network - full video session recording is a common compensating control, because the underlying tools do not log actions natively. Platform-mediated access reduces the need for video: when every action flows through an API with per-action audit logging, command states, and acknowledgment records, the audit trail itself is the session recording, and it is searchable rather than a video archive.
Outbound-only gateway, MFA on every login, role-scoped access, and a tamper-evident audit trail of every remote action - see the architecture working against your own scenarios.