Remote access is no longer a luxury: vendor support, out-of-hours intervention, central monitoring and engineering work are all carried out remotely. The problem is not access itself but how it is provided. A single uncontrolled VPN tunnel from the corporate network to the field can instantly invalidate years of network segmentation.
The rule: a remote user does not enter the OT network directly. They are authenticated, pass through one controlled gateway, reach only the system they need for only as long as they need it, and everything they do is recorded.
Target architecture
A good remote-access design builds a controlled “door” between network zones. The remote user first connects to an access gateway in the DMZ; from there they reach only approved systems over approved protocols.
Design principles
- No direct connections. Instead of a VPN straight into the OT network from the internet or corporate network, use a jump host or remote-access gateway in the DMZ. Leave no ports open inbound.
- Strong authentication. Require multi-factor authentication (MFA); avoid shared accounts and give every user their own account.
- Least privilege. Define access per person and per system. Default to read-only; open write/intervention rights separately when needed.
- Time-boxed, approved access. Vendor accounts should not stay permanently open. Activate them for a defined window under a work-order approval and close them when the work is done.
- Session recording and audit. Who did what, when, on which system? Sessions should be recorded and logs kept outside the OT network too.
- Protocol restriction. Allow the protocols that are needed, such as remote desktop or engineering software, not everything. Firewall rules should be documented and justified.
- Patching and hardening. The access gateway is the component closest to the internet; keep it patched and disable unnecessary services.
- Emergency cut-off. You must be able to cut all remote access with one action, and that procedure must be rehearsed.
A process for vendor access
| Step | What happens | Evidence |
|---|---|---|
| 1. Request | The vendor opens a work order naming the system and the reason | Work-order number |
| 2. Approval | The plant owner approves the time window and scope | Approval record |
| 3. Activation | The account is enabled only within this window; login uses MFA | Authentication log |
| 4. Work | The session runs through the jump host; screen/command recording is on | Session recording |
| 5. Closure | The account is closed and changes made are written back to the work order | Closure note and change record |
Common mistakes
- Modems, VPNs or remote-desktop ports opened “temporarily” and forgotten.
- A single shared account and password given to the vendor.
- Site-to-site VPN tunnels that give flat access to the OT network.
- Firewall rules left as “any-any” with no written rationale.
- No recording, so what happened cannot be reconstructed after an incident.
Relation to standards
The IEC 62443 series defines the framework for this approach through zones and conduits: all communication between zones must pass through a defined, controlled conduit. Remote access is the most visible example of such a conduit. For planning segmentation, see map connections before segmenting an OT network.
Where to start
First inventory the existing remote-access paths: who connects to which system, with which tool, with which account? Most plants find a forgotten path on the list. Then move the riskiest paths to a DMZ gateway and write down the time-boxed vendor-access process. ASP Otomasyon can build this inventory and the target architecture with you through our consulting service, and can tie vendor-access processes into contracts under service.
Frequently asked questions
Isn’t a VPN enough?
A VPN provides an encrypted tunnel but does not restrict access. If the user gets flat access to the OT network at the end of the tunnel, the risk is the same. The VPN should terminate on a gateway in the DMZ, and the real access control should happen there.
Is read-only access safe?
It reduces risk noticeably because write rights are removed, but authentication, logging and scope limits are still needed. The data read can also be sensitive.
How do you give a vendor fast access in an emergency?
Define a fast but controlled “emergency” procedure: phone approval, a short-lived account, full session recording and a post-event review. Prepare the procedure beforehand, not during the incident.
