Secure Remote Access for SCADA: VPN vs Outbound-Only
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.
Why Remote Access Is the Front Door Attackers Use
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.
The Four Remote Access Patterns, Compared
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.
The VPN Problem: Your Perimeter Device Is the Target
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.
- The concentrator is internet-facing by design, and enterprise VPN and remote-access appliances have suffered a steady drumbeat of critical, actively exploited vulnerabilities in recent years - several exploited as zero-days before patches existed. Security agencies now routinely list VPN and edge-appliance CVEs among the top routinely exploited vulnerabilities. When your remote access depends on one, your security posture is hostage to your patching speed on the exact device attackers probe first.
- VPNs grant networks, not functions. A connected user is "inside" - and unless you have built painstaking internal segmentation, inside means reachable PLCs, historians, and engineering workstations far beyond what any single job requires. A stolen VPN credential converts to broad network access in one step; that is precisely the Colonial Pipeline lesson, compounded there by a missing second factor.
- Account lifecycle is hard to govern. VPN access accumulates: employees, integrators, the pump vendor, the guy who left in 2023. Every standing tunnel is a liability someone must remember to revoke - a problem we examine in depth in our guide to insider threat in industrial control systems.
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.
Jump Hosts: Better, Not Sufficient
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.
Outbound-Only: Remote Access Without an Open Door
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:
- TOTP MFA and FIDO2 passkeys on user accounts, with brute-force detection and persistent account lockout behind them.
- Roles and site-level authorization - viewer through superadmin, scoped per site, so a stolen credential yields one account's permissions, not a network.
- Session discipline - expiry, concurrent-session limits, revocation, and logout-everywhere for the day someone leaves.
- Step-up authentication for high-risk workflows, and a guarded control path: only explicitly writable tags accept writes, setpoints are bounds-checked before dispatch, and commands carry idempotency protection with tracked states from pending to verified.
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.
Governing Vendor and Third-Party Access
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:
- Named individual accounts for every external person. A shared "vendor" login makes attribution impossible and revocation all-or-nothing.
- Least privilege and site scoping - the pump vendor sees pumps at the sites they support, nothing else. Read-only unless their work genuinely requires writes.
- Time-bounded grants tied to the engagement, verified in quarterly access reviews rather than trusted to memory.
- Same audit trail as employees - every vendor action logged, attributed, and reviewable.
- No standing network tunnels. Platform-mediated access means a vendor holds an account you control, not a network path you have to remember exists.
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.
Session Recording and the Audit Trail
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.
Buyer's Checklist: Remote Access Questions for Any SCADA Vendor
- What inbound firewall rules does your architecture require? The best answer is "none."
- Is MFA enforced on every remote login - including API access and vendor accounts - or is it optional?
- Does a logged-in user get network access or application access? Can a compromised account reach anything beyond its role's scope?
- How are sessions bounded? Expiry, concurrent-session limits, immediate revocation, logout-everywhere.
- Is every remote action audit-logged against a named user - including setpoint old/new values - and are those records tamper-evident?
- How is your own staff's access to my environment controlled and logged?
- What happens to remote sites when connectivity drops? Local polling and store-and-forward buffering should continue without data loss.
- Can access requirements coexist with our on-premise or air-gapped policy? See our cloud vs on-premise comparison for how the deployment models differ.
Frequently Asked Questions
What is the most secure way to remotely access SCADA?
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.
Why are VPNs risky for SCADA remote access?
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.
What is outbound-only SCADA architecture?
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.
How should third-party vendor access to OT systems be managed?
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.
Should SCADA remote sessions be recorded?
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.
Sources & Further Reading
- NSA and CISA Recommend Immediate Actions to Reduce Exposure Across Operational Technologies (AA20-205A) - NSA & CISA
- Guide to Securing Remote Access Software - CISA, FBI & partners
- 2023 Top Routinely Exploited Vulnerabilities (AA24-317A) - CISA & international partners
- Compromise of U.S. Water Treatment Facility (AA21-042A) - CISA, FBI, EPA & MS-ISAC
- DarkSide Ransomware: Best Practices for Preventing Business Disruption (AA21-131A) - CISA & FBI
- NIST SP 800-207, Zero Trust Architecture - NIST
- ISA/IEC 62443 Series of Standards - International Society of Automation
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.