What breaks when legacy OT protocols are managed with VPNs and firewalls alone?

Why This Matters for Security Teams

VPNs and firewalls were designed to control network paths, not to express task-level trust. In OT, that gap matters because many legacy protocols were built for flat, implicit trust and lack native user context, session binding, or strong object-level authorization. Once a VPN grants broad reach, the firewall often becomes a coarse gate rather than a real policy layer, which makes auditability, least privilege, and change control much harder to sustain.

The result is not just inconvenience. Operators end up preserving connectivity by widening rules, reusing exceptions, and documenting intent outside the control plane. That creates brittle access patterns that can survive long after the original maintenance need has passed. For teams that have to support uptime, safety, and vendor access at the same time, the security model becomes difficult to explain, difficult to prove, and difficult to keep consistent across plants and remote sites. In practice, many OT environments only discover those weaknesses after an outage, a failed change window, or a third-party access review exposes how much trust the VPN was quietly carrying.

How It Works in Practice

The core problem is that legacy OT protocols usually speak in terms of devices, registers, and commands, while VPNs and firewalls speak in terms of endpoints, ports, and subnets. That mismatch means a technically successful connection can still be operationally unsafe. A maintenance engineer may need access to one controller for one short task, but the network controls often permit an entire route into a much larger trust zone.

That is why coarse controls tend to fail in three ways:

• They over-grant reach, so one authenticated session can touch far more assets than the task requires.
• They under-describe intent, so it is hard to tell who accessed what, for how long, and for which maintenance action.
• They do not age well, so temporary exceptions become standing pathways that nobody wants to remove.

For OT, this is especially visible when engineering work depends on proprietary tools, multi-hop jump paths, or vendor support sessions that have to stay open longer than planned. NIST SP 800-82 Rev 3, the OT security guide, treats segmentation and zone design as foundational because protocol-aware boundaries are often the only practical way to preserve operational safety without giving broad network trust. That is also why teams often pair network segmentation with stricter remote-access workflows rather than treating VPN access as the control itself.

A useful mental model is that the VPN answers "can this device reach the environment?" while OT security needs to answer "should this person or tool reach this exact controller right now, under these conditions?" Those controls tend to break down when remote access must support many sites through a single shared tunnel because the resulting exceptions become impossible to govern cleanly.

Common Variations and Edge Cases

Tighter remote access often increases operational friction, so organisations have to balance uptime and maintainability against the loss of coarse but convenient connectivity. In practice, that tradeoff changes depending on whether the environment is a small brownfield site, a multi-vendor plant, or a regulated critical-infrastructure network with strict change windows.

Some teams try to solve the problem by adding more firewall rules, but that usually scales poorly when the protocol is proprietary or the asset inventory is incomplete. Others rely on jump hosts or remote support boxes, which can help if they are tightly governed, but still leave a large gap if the session is not scoped to the specific task and target. A stronger pattern is to treat remote access as temporary, observable, and separately approved, rather than as a permanent network entitlement.

Current guidance suggests the control choice should follow the protocol and the risk, not the convenience of the existing perimeter. For highly sensitive OT segments, coarse VPN access may still be acceptable for limited administrative functions, but only when it is paired with segmentation, explicit approval, and strong session monitoring. For many environments, the real edge case is not the protocol itself, but the accumulation of exceptions across vendors, plants, and emergency changes.

One practical reference point is NIST SP 800-207 Zero Trust Architecture, which pushes teams toward continuous evaluation and explicit authorization instead of assuming trust from network location alone. That model fits OT only when it is adapted carefully to safety and availability constraints, but it highlights the main breakage: a network tunnel is not the same thing as a controlled operational decision.

Risk and Threat Considerations

The main risk is that broad VPN connectivity and coarse firewall policy create an access path that is easy to abuse, hard to scope, and difficult to prove safe. In OT, that can turn a legitimate remote session into a pathway for lateral movement, unintended command execution, or over-broad vendor access.

Failure mechanism: A single authenticated tunnel can expose multiple assets and protocols at once, while firewall rules often permit ranges rather than task-specific targets. If credentials are stolen, shared, or overused, an attacker or careless operator can move through the environment with far more reach than the original maintenance need required.

Impact: Access becomes harder to contain and harder to investigate, which increases the chance of unauthorized changes, unsafe operations, extended outage duration, and weak accountability for who touched which OT target.

Practitioner Guidance

What to prioritise: Start by mapping which OT sessions truly need remote connectivity and which ones can be removed, time-boxed, or forced through a more constrained path. The goal is to reduce standing trust before adding more monitoring.

What to verify: Confirm that every remote-access path is scoped to an exact asset, an exact time window, and an exact operator or vendor purpose. If the control cannot show that level of specificity, it is still acting like a broad network entitlement.

What good looks like: The best state is not "VPN enabled," but "remote access is temporary, reviewable, and narrow enough that a compromised session cannot roam across the plant." That is the standard that separates connectivity from control.

Practitioner takeaway: In OT, the question is not whether VPNs and firewalls work, but whether they are precise enough to express the real operational trust boundary; if they are not, they become enablers of brittle access rather than controls.

Related resources from NHI Mgmt Group

• What breaks when OT access control relies on VPNs, firewalls, and shared passwords alone?
• What breaks when hybrid IAM is managed as separate cloud and legacy projects?
• What breaks when SharePoint attackers can reuse stolen credentials across legacy protocols?
• What breaks when OT access is managed like standard enterprise access?