OT remote access architecture: vendor access without regret

The pressure that creates the problem

Nobody plans to expose a control system to the internet. What happens instead: a compressor trips at 2 a.m., the only person who can diagnose the OEM controller is a vendor engineer three time zones away, production is losing money by the minute, and someone on site plugs a cellular modem into the panel “just for tonight.”

Six years later it is still there, holding up a maintenance contract.

I supported process-control networks at a petrochemical plant for four years, and this is the pattern I came to respect most: the remote access requests never stop, they are always urgent, and they are always individually reasonable. Refusing them one at a time is not a strategy — you will lose, at 2 a.m., to someone whose plant is down and whose reason is better than your policy. That is why access has to be an architecture rather than a series of favors. The system must make the safe path the fast path, or the unsafe paths will accumulate quietly until an incident inventories them for you.

Design principles

Three principles carry the whole design:

1. No standing connectivity. Access exists per session, approved and time-boxed. The default state of every remote path is down. A tunnel that is always up is not remote access; it is an extension cord to a network you do not control.
2. No foreign endpoint touches the control network. Vendor laptops terminate at a jump host you own, patch, and monitor. What crosses into OT is keyboard, video, and file transfer through a controlled gateway — never a routed tunnel.
3. A person is accountable for every session. Named accounts per individual, not per company; MFA at the broker; and a recording that operations can review. “The vendor was in the system” must never be where the audit trail ends.

Reference architecture

 Vendor / remote engineer
        │  TLS + MFA
        ▼
 ┌─────────────────────────┐   IT network (Level 4/5)
 │  Access broker / portal │   - identity, MFA, approvals
 └───────────┬─────────────┘
             │ brokered session (no routed path)
 ════════════╪══════════════  OT DMZ (Level 3.5)
 ┌───────────▼─────────────┐
 │  Jump host (hardened,   │  - session recording
 │  recorded, no Internet) │  - clipboard/file controls
 └───────────┬─────────────┘
             │ specific host:port, time-boxed firewall rule
 ════════════╪══════════════  Control network (Level 3 and below)
 ┌───────────▼─────────────┐
 │  Engineering workstation│
 │  / target device        │
 └─────────────────────────┘

The components, and the specific job each one does:

• Access broker (IT side or cloud): where identity lives. Per-person accounts tied to your IdP, MFA enforced, and — critically — the approval workflow. Operations approves the window; the broker enforces it. This is identity-first security applied to OT: the perimeter decision is who, before any packet matters.
• OT DMZ jump host: the only machine a remote session ever lands on. Hardened build, no internet egress, and the engineering tools installed and licensed there, so project files stay inside your boundary instead of scattering across vendor laptops.
• Time-boxed firewall rules: the jump host’s reach into the control network is not permanent either. The rule permitting jump-to-PLC traffic opens with the approved window and closes with it — automated, not a ticket someone has to remember on a Friday.

Design decisions and tradeoffs

Decision	Safer choice	Cost you accept
Session model	Brokered RDP/SSH, recorded	Vendors complain about their tools; some OEM software needs the jump host licensed
Vendor tunnels	None; per-session only	Renegotiating support contracts that assume standing VPN
File transfer	One-way staged transfer with scanning into OT	Slower patch/project file delivery
Cellular backdoors	Prohibited and periodically swept for	You must actually provide a working alternative
Access hours	Approved windows tied to work orders	Off-hours emergencies need the break-glass path below

Be honest about the middle column: every one of these choices costs somebody something, usually a vendor relationship or a support contract clause. The last row is the one that decides whether the architecture survives contact with operations. If the emergency path is slower than a cellular modem, the modems come back — and operations will be right to bring them back, because the plant outranks the diagram.

Break-glass: the path that keeps you honest

Design the exception before you need it:

• A standing emergency-access procedure that any shift supervisor can invoke — not just security staff, who are asleep when the compressor trips. The people who hold the plant at night must hold the key.
• Invocation opens the same brokered path with expedited, post-hoc approval, alerts the OT security owner, and flags the session recording for mandatory review.
• The rule set still applies: named account, MFA, jump host, recording. What compresses is the approval latency. Never the architecture.

A break-glass event is also telemetry. Every invocation gets a short review, and three break-glasses for the same OEM in a quarter means the normal path is too slow for that vendor — at which point the architecture gets adjusted, not the operators lectured. The system serves the plant, not the other way around.

Implementation notes

• Inventory first. Before building the good path, find the existing ones: firewall rules to vendor address space, modems and cellular gateways in panels — walk the plant, because asset databases do not know about hardware wire-tied inside a cabinet — and remote-desktop tools on HMIs and engineering workstations.
• Retire discovered paths with their owners, not against them. Each backdoor exists because someone once needed it, and that person was solving a real problem with the tools they had. The replacement conversation is “here is your faster, sanctioned path,” per the trust-building approach in OT/IT convergence.
• Start with the highest-consequence systems (safety, primary control) and the highest-frequency vendors. One well-run pilot vendor becomes the reference that sells the rest.
• Measure and report: sessions brokered, mean approval latency, break-glass count, backdoors retired. The program’s budget renewal lives in those four numbers.

Remote access is not something OT security tolerates. Done properly, it is something OT security provides — faster than the shadow alternatives, with an audit trail attached. That inversion generalizes well beyond OT: security programs endure when the sanctioned path wins on convenience, and they erode, one reasonable exception at a time, when it only wins on policy.