VPNs can remain part of a transition plan, but they should not be the governance model. If a VPN extends broad trust into the plant, it should be replaced or tightly constrained by identity-aware access, per-session authorization and segmentation that limits post-entry movement.
Why VPNs Should Be Transitional, Not the Operating Model
A VPN can still have a place in OT, but only as a controlled transport path. The problem starts when the tunnel becomes the governance layer: broad network reach, broad implicit trust, and too much room for lateral movement after entry. A better model makes each session explicit, narrow, and time-bound, so access is tied to the task rather than to the whole plant.
That distinction matters because OT environments tend to mix high-value access paths, legacy hosts, and fragile operational dependencies. A VPN may solve connectivity, but it does not by itself answer who is allowed to reach what, from where, and for how long. If that answer is still “anything on the inside once connected,” the architecture is still permissive even if the perimeter looks modern.
For teams planning a migration, the right question is not whether VPNs are “good” or “bad,” but whether they still serve a narrowly defined use case such as emergency maintenance, vendor fallback, or temporary bridge access. Once a better control path exists, the VPN should be demoted from default entry method to exception path, and its trust should be reduced accordingly.
What Segmentation Changes After Entry
Segmentation changes the blast radius. In OT, that usually means separating user access from control networks, constraining pathways between zones, and making east-west movement harder even after a user or contractor is authenticated. The goal is not only to stop outside attackers, but also to limit the damage from a valid credential, a compromised remote session, or an over-scoped maintenance account.
Good segmentation also forces clearer operational boundaries. If an engineer needs a historian, an engineering workstation, or a specific cell area, the access path should reflect that need directly instead of exposing a broad routable network. That is why segmentation and remote access design have to be planned together: segmentation without access control becomes hard to use, while VPN access without segmentation becomes too broad to be safe.
In practice, the strongest designs combine network zoning with per-session authorization and device-aware entry checks. That lets teams preserve operational continuity while shrinking what any successful login can actually touch. It also makes access reviews more meaningful, because the review can focus on specific routes and tasks rather than a blanket “VPN allowed” status.
How to Decide What Stays, What Shrinks, and What Goes
Keep the VPN only when it is doing something segmentation and identity-aware controls cannot yet replace, such as bridging legacy workflows during a transition. Remove it or heavily constrain it when it is being used as a standing doorway into multiple zones, especially if the same account can reach engineering assets, support systems, and production-adjacent segments without separate approval.
That decision should be driven by observable access paths, not by convenience. If a connection method creates a large trusted corridor, it needs compensating controls, shorter session lifetime, stronger authentication, and tighter routing. If the environment can already enforce task-specific access through a more granular remote access layer, the VPN should stop being the primary path and become an exception mechanism.
The practical test is simple: after login, can the user still move laterally in ways that the business did not intend? If the answer is yes, segmentation and authorization are not yet doing enough. If the answer is no, then the environment is finally treating remote access as a controlled transaction instead of a standing trust relationship.
Risk and Threat Considerations
VPNs that extend broad trust into OT create a classic post-entry attack problem. Once an attacker uses valid credentials, session theft, or a compromised endpoint, the tunnel may give them enough reach to probe adjacent assets, pivot toward control systems, or blend into normal administrator traffic. In that model, the issue is not only initial access, but the size of the internal path granted after access succeeds.
Failure mechanism: A remote access control that authenticates the user but does not sufficiently constrain the reachable zone, session scope, or downstream movement turns one compromise into a larger internal exposure.
Impact: The result can be unauthorized command access, wider operational disruption, or faster attacker progression from remote foothold to sensitive OT assets, especially where shared accounts or legacy routing rules still exist.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST Zero Trust (SP 800-207), CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | SP 800-207 — Zero Trust Architecture | Remote OT access needs explicit verify-and-limit controls instead of broad network trust. |
| Recommendation — Apply zero-trust principles to force per-session verification and least-privilege routing. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Replacing broad VPN trust requires tighter account and access path governance. |
| Recommendation — Restrict and review access paths so remote entry cannot become general internal reach. | ||
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Segmentation is fundamentally about enforcing where traffic may flow after entry. |
| IA-2 — Identification and Authentication (Organizational Users) | The answer depends on authenticating users before remote OT access is granted. | |
| Recommendation — Enforce zone-to-zone flow limits so remote access cannot reach all internal assets. Require strong user authentication before any remote OT connection is allowed. | ||
Practitioner Guidance
What to prioritise: Treat the remote access redesign as a blast-radius problem first, not a convenience problem. Start with the paths that can reach the most zones or the most sensitive engineering assets, then narrow or retire those paths before tackling lower-risk remote workflows.
What to verify: Confirm that every remote session is bound to a specific purpose, that post-authentication access is limited to the minimum required zone, and that vendors or operators cannot inherit broader plant trust simply because they are inside the tunnel.
Decision rule: If the VPN is still the mechanism that grants general internal reach, it is a transition control only. If access can already be expressed as per-session, per-task, and per-zone authorization, the VPN should be reduced to a fallback path or removed from the normal operating model.
Practitioner takeaway: The question is not whether VPNs have value, but whether they still deserve trust as a broad network boundary. In OT, the safer answer is usually “only temporarily, and only with strict limits.”