How should manufacturers secure remote access when VPNs are not enough for OT environments?

Why VPNs Alone Fall Short in OT Remote Access

Manufacturers need remote access that limits what a user can reach, proves who is connecting, and keeps every action attributable. A VPN can authenticate a tunnel, but it does not automatically constrain lateral movement inside an OT network, distinguish between routine support and high-risk operations, or give the granularity needed for segmented industrial environments. That is why remote access must be designed around trust, privilege, and session control rather than connectivity alone.

For OT, the practical problem is not simply “can someone connect?” but “what can they do once connected, and can the organisation prove it?” Remote sessions should be scoped to specific assets, time windows, and approved tasks, with identity checks and logging that reflect the operational impact of the access path. Where access is broad, shared, or poorly monitored, VPN convenience becomes a weakness instead of a control. In practice, many OT incidents begin with remote access that was intended to be temporary but was never reduced back to least privilege.

One useful signal is that only 5.7% of organisations have full visibility into their service accounts, which shows how often remote access governance fails once the session leaves the perimeter.

Ultimate Guide to NHIs shows the broader governance gap that makes remote access hard to audit when privileges, credentials, and session ownership are not tightly managed.

How to Build a Safer OT Remote Access Model

The stronger pattern is to separate network reachability from operational authority. A user may need to connect remotely, but that should not mean they can browse the environment freely, reuse standing access, or touch any PLC, historian, engineering workstation, or HMI by default. The remote access layer should enforce least privilege, step-up verification, and session recording so each connection is purpose-built and reviewable.

• Use privileged access management for approved support paths, rather than exposing OT assets directly through a broad tunnel.
• Apply continuous identity verification at session start and during longer sessions, especially where vendors or third parties are involved.
• Restrict access to named assets and approved commands or protocols where possible, instead of allowing full network adjacency.
• Record sessions and administrative actions so operations, engineering, and security teams can reconstruct what happened quickly.
• Separate emergency access from routine access, with different approval, logging, and revocation rules.

This is where VPNs typically underperform in OT, because they are network transport tools, not policy engines. They move traffic, but they do not by themselves answer whether the session is appropriate for the asset, the operator, or the task. Manufacturers usually get better results when remote access is brokered through a central control point that can enforce approval, scope, and monitoring in one place.

At scale, the strongest designs also reduce dependence on long-lived credentials and manual exception handling. That matters because remote maintenance, vendor support, and after-hours remediation often create the exact conditions where broad access quietly becomes permanent.

These controls tend to break down when legacy OT protocols, unmanaged vendor accounts, or flat network segments force organisations to treat every remote session as a trusted session.

OWASP Non-Human Identity Top 10 is useful when remote access depends on machine credentials, shared service accounts, or automated support flows that need their own governance.

Common OT Edge Cases and Where the Model Needs Adjustment

Tighter remote access often increases friction for maintenance teams and vendors, so organisations have to balance operational continuity against control depth. That trade-off is real in plants that run 24/7, where an over-restrictive model can slow fault recovery, but a permissive model can expose production systems to unnecessary reach.

One common edge case is emergency support. Manufacturers often need a break-glass path, but it should be time-bound, heavily logged, and reviewed after use rather than treated as a permanent exception. Another is third-party support, where access requirements may vary by vendor, asset family, and shift pattern. In those cases, the right control is usually not “more VPN,” but a more precise access broker with narrow entitlements and stronger auditability.

Another important variation is the difference between observing and controlling. Continuous monitoring is valuable, but monitoring alone is not enough if the access path still permits high-risk actions. The access model should make it difficult to reach unsafe states in the first place, then use logging and alerts to confirm that the controls are actually working. Organisations that rely on visibility after the fact often discover that remote access was broader than expected only after an incident review.

NIST SP 800-53 Rev 5 Security and Privacy Controls provides a solid control baseline for access enforcement, auditability, and monitoring expectations in environments that need disciplined remote access governance.

Risk and Threat Considerations

Remote access is attractive to attackers because it combines reach, legitimacy, and operational urgency. If a VPN credential, vendor account, or support channel is abused, the attacker may inherit a trusted path into systems that are difficult to monitor at protocol level or slow to patch. In OT, that can turn a single access failure into production disruption, unsafe state changes, or loss of visibility.

Failure mechanism: Broad remote access weakens segmentation, and weak segmentation gives an attacker room to pivot from the initial entry point to more sensitive engineering or supervisory systems. Shared accounts, long-lived credentials, and insufficient session logging make it harder to distinguish approved maintenance from malicious use.

Impact: The organisation can lose control over who touched what, when they touched it, and whether the access was still appropriate for the asset. That creates exposure not just to data theft, but to operational interruption, unsafe commands, and delayed incident containment.

Practitioner Guidance

What to prioritise: Treat remote access as an exception-driven privilege path, not a default network service. The first design question should be which OT assets truly need remote reachability, because reducing the exposed surface is usually more effective than trying to monitor a broad tunnel perfectly.

Decision rule: If access can affect production, safety, or plant availability, require brokered, time-bound, identity-verified sessions with session recording and explicit approval. If the use case is low-risk observation only, keep the permissions and protocol scope narrower than maintenance access.

What to verify: Confirm that every remote path has an owner, a revocation process, and an audit trail that survives vendor turnover and shift changes. If you cannot answer who approved access, what was reachable, and when the session ended, the control is too weak to trust.

Practitioner takeaway: In OT, the safest remote access model is the one that makes privilege temporary, narrow, and attributable, because connectivity without control is just another way to extend the blast radius.

Related resources from NHI Mgmt Group

• Why does secure remote access matter more in OT than in standard IT environments?
• How should energy organisations secure remote access across IT and OT environments?
• How should security teams govern remote privileged access in OT environments?
• Which frameworks should teams use to assess OT secure remote access governance?