What breaks when CPS remote access is granted through broad VPN-style connectivity?

Why broad VPN-style remote access breaks CPS trust boundaries

In CPS, the problem is not just that a user can connect, it is that a broad VPN makes the whole remote-access path behave like one coarse trust event. That collapses device access, operator access, and task scope into the same entry decision, which is a poor fit for environments where commands can change physical processes, safety states, or recovery options.

When remote connectivity is treated as equivalent to operational trust, the network becomes the control boundary instead of the action itself. That means the system assumes anyone who is “on the VPN” can be trusted to reach the right devices, at the right time, with the right level of authority, even though CPS operations usually need narrower, task-specific control.

This is why the issue is architectural, not just procedural. A broad tunnel can make legacy remote-admin habits look convenient, but it also hides which device is being touched, which operator is acting, and whether the access should expire after a single maintenance window or remain available indefinitely.

What overbroad connectivity does to accountability and privilege

Broad connectivity tends to flatten privilege. Instead of separating read-only monitoring, limited maintenance, vendor support, and high-risk command execution, the VPN model often exposes a larger slice of the environment than the task requires. That creates a mismatch between operational intent and effective authority.

It also weakens accountability because the trust decision happens at the network edge, not at the command or session level. In practice, that can make it harder to answer basic questions such as who accessed which controller, what they were allowed to change, and whether the access path was still valid after the work was done.

For remote-access governance, the key failure is that access can outlive the need for access. If a session or account remains broadly valid after a maintenance event, the environment keeps carrying standing reachability that should have been time-bound, scoped, and attributable to a specific operational purpose.

What changes when CPS access is controlled more tightly

The practical alternative is to treat remote access as a narrowly governed operational function, not a blanket connectivity grant. That means separating the ability to reach the network from the authority to issue meaningful commands, and making the access path depend on task, device, time, and operator context rather than on simple authenticated presence.

This is where zero-trust style thinking is helpful: NIST SP 800-207 Zero Trust Architecture formalises the idea that trust should be continuously evaluated instead of implied by location. For CPS, that is especially important because the same remote channel may be acceptable for inspection but not for command execution.

In operational settings, that tighter model usually means stronger segmentation, explicit approval for higher-risk actions, and a control layer that can distinguish monitoring from control. It also supports more reliable audit trails because access decisions are tied to a specific session, asset, and purpose rather than to an always-open VPN corridor.

Risk and Threat Considerations

Broad VPN-style connectivity creates a direct exposure path for lateral movement, privilege abuse, and unsafe command execution. In CPS, the risk is amplified because a compromised remote session can move from ordinary network reachability into control functions that affect availability, integrity, or safety.

Failure mechanism: A single remote-access trust decision grants too much reach, so stolen credentials, over-privileged accounts, or forgotten dormant access can be reused against live operational assets without a second, task-specific authorisation check.

Impact: Attackers or careless operators can change commands, reach devices they should not see, or keep access long after the work is complete, increasing the chance of service disruption, unsafe state changes, or weak post-incident accountability.

Practitioner Guidance

What to prioritise: Separate remote reachability from operational authority. If a VPN grant currently doubles as permission to issue control actions, treat that as a design defect rather than a convenience feature.

What to verify: Confirm that remote access is scoped to specific assets, specific sessions, and specific tasks, with expiration and revocation tied to maintenance windows. For CPS, a valid login should not automatically imply broad device control.

Common mistake: Treating vendor support, engineering access, and operator access as one remote-access class. That shortcut usually produces excessive privilege and makes it difficult to prove who had authority to do what.

Practitioner takeaway: The right control objective is not “can they reach the plant network?”, it is “can they perform only the exact operational action they were approved to perform, for only as long as that action is needed?”

Related resources from NHI Mgmt Group

• What breaks when AWS access is granted through broad admin roles?
• What happens when healthcare organisations allow third parties to connect through VPN-style remote access instead of Zero Trust network access?
• What breaks when Kubernetes API access is granted through broad client certificates?
• What breaks when remote access still depends on persistent VPN credentials?