Secure Remote Access for OT: Safe Alternatives to VPNs

Remote access is essential for modern OT operations – vendor troubleshooting, remote operators, cloud telemetry, and emergency patches all depend on it. But the classic solution many teams reach for – an always-on site-to-site VPN or blanket VPN accounts for engineers – is often the weakest link in an industrial environment. VPNs that are misconfigured, broadly permissive, or used without strict controls create easy lateral-movement paths into safety-critical controllers. This post explains why VPNs frequently fail for OT, and then gives practical, prioritized alternatives that preserve safety, enforce accountability, and keep your plant running. The guidance below is aligned with OT-specific best practice (NIST SP 800-82), CISA recommendations on remote access, and Zero-Trust principles adapted for industrial environments.

Why VPNs are a poor default for OT (short background)

VPNs were designed to extend trusted networks securely across untrusted transport. In IT that model often works – but in OT it introduces four recurring problems:

1. Broad implicit trust: A VPN typically joins a remote host to the site network and implicitly trusts it, enabling lateral movement. In OT that can mean a single compromised laptop reaches PLCs and safety controllers.
2. Hard to segment effectively: VPN tunnels can bypass the industrial DMZ and local access controls unless every policy is meticulously enforced at both ends. Mistakes happen during rapid maintenance windows.
3. Difficult to monitor and record: Many VPN sessions are opaque; session recording for operator or vendor actions is often absent, which kills post-event forensics.
4. Over-privileged vendor access: Vendors used to “just connect and fix it” – but unmanaged VPN access results in long-lived credentials and forgotten accounts.

Because OT operations place safety and availability first, you need remote access patterns that are friction-aware, auditable and time-boxed – not always-on tunnels. NIST and CISA guidance both call for OT-aware remote access controls and layered defences that reduce blast radius.

The secure remote access stack for OT – core building blocks

Think of a layered stack rather than a single replacement. Combining these controls gives you defense in depth while retaining operator productivity:

• Industrial DMZ with hardened jump hosts (session brokering and logging) – put all remote sessions through an auditable broker in the DMZ.
• Privileged Access Management (PAM) + Just-In-Time (JIT) provisioning – avoid standing privileged credentials; require ephemeral, logged elevation for every fix.
• Zero Trust Network Access (ZTNA) for application mediation – grant per-request access to services (not networks) based on identity and device posture.
• Data diodes / one-way flows for telemetry – where OT only needs to send data out (monitoring, analytics), use one-way mechanisms to eliminate inbound attack surface.
• Protocol-aware proxies and micro-segmentation – control exactly which industrial protocols and function codes can be used across conduits.
• Continuous monitoring & session recording – capture what remote actors do (keystrokes, commands, file transfers) for fast triage and non-repudiation.

Below we unpack each element and show how to implement them in an OT-safe way.

Alternative 1 – Hardened jump hosts in an Industrial DMZ (the first stop)

What it is: A jump host (bastion server) is a hardened, tightly controlled machine in the IDMZ that brokers all remote operator and vendor sessions. Remote users connect to the jump host – not to PLCs or engineering workstations directly – and then are allowed to connect forward under policy and audit.

Why it works for OT: Jump hosts let you centralize MFA, session recording, and device posture checks outside of the control network. Because the jump host sits in the IDMZ, the forward connections can be limited to specific management ports and times, and mirrored for forensic capture. This is a primary recommendation in CISA’s OT remote-access guidance.

How to implement (practical):

1. Deploy a hardened, minimal-service jump host cluster in the IDMZ (use VMs or purpose-built appliances).
2. Require MFA and corporate identity (SSO) to access the jump host.
3. Broker vendor sessions using JIT credentials issued by a PAM solution (see below).
4. Record video and command logs of every session; store them offsite in a tamper-evident archive.
5. Limit forward connections by IP, protocol and time window; log ACL changes via change control.

Operational note: Test the jump host in passive mode first (session recording and shadowing) before turning off existing VPN paths.

Alternative 2 – Privileged Access Management (PAM) + Just-In-Time access

What it is: PAM systems discover privileged accounts, vault credentials, provide session brokering and create ephemeral credentials that expire after the task is done.

Why it works for OT: PAM eliminates hard-coded or long-lived vendor passwords and provides accountability for every privileged action. Pairing PAM with JIT access means vendors and engineers only get rights when required and only for the durations approved in the maintenance ticket – a core CISA best practice.

How to implement:

• Inventory privileged accounts and integrate with PAM (bastion, credential vault, session manager).
• Automate the issuance of short-lived credentials tied to a documented change ticket.
• Force recording of sessions and capture file transfers.
• Integrate PAM alerts into your SIEM and OT monitoring dashboards.

Quick win: Force all vendor RDP/SSH to be brokered by PAM for the next maintenance window; revoke any local accounts not in the vault.

Alternative 3 – Zero Trust Network Access (ZTNA) for applications (not networks)

What it is: ZTNA shifts from network-based trust (you’re on the VPN so you’re trusted) to request-level trust: each access request is authenticated, authorized, and evaluated for device posture before being allowed to a specific application or service. NIST’s Zero Trust Architecture and industry guidance recommend applying these principles to critical assets.

Why ZTNA fits OT: For OT use cases where engineers need to reach a specific HMI or historian service, granting an app-level, ephemeral session is far safer than opening a network tunnel. ZTNA also enables tighter logging, conditional access policies, and device posture checks (e.g., is the laptop patched, are credentials vaulted).

How to implement:

1. Identify control-plane applications that need remote access (HMI, engineering tools, patch servers).
2. Deploy a ZTNA gateway in the IDMZ that brokers authenticated app sessions (mutual TLS, device posture, SSO).
3. Enforce least privilege at the application level (read vs write), and record every session.
4. Phase in ZTNA for non-critical systems first, then extend to control-plane apps after proving stability.

Caveat: ZTNA products vary – choose OT-aware vendors or validate rigorously in a testbed to ensure industrial protocols behave correctly.

Alternative 4 – One-way transfers: data diodes for telemetry & analytics

What it is: Hardware or high-assurance software mechanisms that allow data to flow only from OT → IT/cloud, never the reverse.

Why it works: When the only requirement is to stream telemetry to analytics (no remote control), a one-way diode eliminates any inbound attack vector entirely. This is a mature approach used in high-assurance installations and recommended for sending operational telemetry to enterprise systems.

How to use them:

• Use data diodes for historian replication, alarm transfer, and read-only tag exports.
• For richer two-way needs, prefer tightly controlled application proxies or ZTNA with strict write-deny policies.
• Include diode-provided telemetry in your SIEM/historian correlation so alarms still surface in the enterprise.

Trade-off: Diodes are not suitable where remote patching or control is required – they are a high-assurance niche for specific flows.

Alternative 5 – Protocol proxies and micro-segmentation for control writes

What it is: Application-level proxies that validate and filter specific industrial protocol operations (e.g., Modbus function codes, OPC UA method calls) and host-based micro-segmentation that limits which machines can communicate even within a zone.

Why it works: OT attacks often exploit specific dangerous operations (setpoint writes, safety bypass). Protocol proxies can allow only vetted, policy-approved operations, and micro-segmentation reduces attack paths between workstations and controllers.

How to implement:

• Deploy protocol gateways in the IDMZ that translate and validate cross-domain requests.
• Implement host firewalls and zero-trust micro-segmentation for engineering workstations and safety controllers.
• Create whitelists of allowed function codes and monitor for anomalies.

Operational note: Because proxies can alter latency or compatibility, test in a mirror lab first.

Operational playbook – step-by-step rollout (90 days)

A pragmatic phased plan focused on safety and momentum.

Weeks 0–2: discovery & policy

• Inventory remote access use cases (vendor tools, RDP, remote patching).
• Map business justification for each remote flow and classify as read-only / control-write.
• Publish an interim remote access policy (require jump host + PAM for all privileged flows).

Weeks 2–6: IDMZ + jump host POC

• Spin up an IDMZ POC and deploy a hardened jump host. Route one vendor through it for a maintenance event. Record sessions and collect feedback.

Weeks 6–12: PAM + JIT

• Integrate PAM for vaulted credentials and JIT issuance. Require all privileged sessions to be brokered. Revoke standing vendor accounts.

Weeks 12–20: ZTNA & protocol proxies

• Pilot ZTNA for one non-critical application (e.g., historian read). Deploy protocol proxy for one conduit and validate behavior.

Ongoing: telemetry & diode adoption

• For purely read/monitoring flows, deploy data diodes or push-only gateways.

Quick policy templates you can copy

Remote Access Policy (short):

• All remote access must be brokered via IDMZ jump hosts or ZTNA gateways.
• All privileged credentials must be vaulted in PAM; JIT credentials required for maintenance.
• Vendor access requires documented change ticket, JIT credentials, session recording and post-session review.
• Read-only telemetry flows must one-way transfer wherever feasible. (Refer to CISA remote access guidance.)

Vendor Access Checklist (for every session):

• Business justification and ticket ID | JIT credential issued (Y/N) | Session recording enabled (Y/N) | Files transferred (Y/N) | Post-session review done (Y/N).

Measuring success – KPIs that matter

• % of privileged vendor sessions brokered and recorded (target: 100%).
• of standing VPN accounts removed (trend: down to 0).
• % of control-plane write requests requiring JIT approval.
• Mean time to detect & review suspicious remote session (target: measurable reduction within 3 months).
• % telemetry flows via one-way mechanisms where applicable.

Common pitfalls and how to avoid them

• Cutting productivity without safety review: Always test access controls in a staging cell and coordinate with OT engineers; don’t break operator workflows.
• Under-recording sessions: If you can’t replay what happened, you can’t investigate. Record everything-even read-only sessions help with auditing.
• Trying to “rip and replace” overnight: Adopt incremental pilots (one vendor, one site) and learn.
• Assuming ZTNA solves all OT problems: ZTNA reduces network-level risk but must be paired with PAM, protocol validation and operational governance.

Final thoughts – design for safety, not secrecy

Secure remote access for OT is not an either/or between “VPN” and “no VPN.” It’s a layered, pragmatic architecture: move away from broad network tunnels and toward brokered, ephemeral, auditable access that maps to operational processes. Centralize access in an IDMZ, vault and short-lived privileged credentials with PAM, apply Zero-Trust application mediation for sensitive services, and use data diodes where only telemetry is needed. These patterns preserve availability and safety while delivering the remote access capabilities operations need – and they match current OT guidance from CISA and NIST.