Secure Remote Access for OT Vendors: Best Practices

97

Secure remote access for OT vendors is best implemented by terminating all vendor connectivity in an OT DMZ and brokering access through a jump host or remote access gateway with MFA, named accounts, least privilege, and time-bound (just-in-time) approvals. Restrict access to allowlisted destinations and protocols (zones/conduits), record and log sessions, tightly control file transfers, and continuously monitor for high-risk actions (e.g., controller downloads). Finally, operationalize a vendor lifecycle: onboarding checks, access reviews, and rapid offboarding of accounts, firewall rules, tokens, and tools.

Why OT vendor remote access is uniquely risky

Remote access is not inherently “bad.” In OT, it’s often necessary for:

• OEM support and warranty requirements
• integrator troubleshooting during commissioning
• patching and updates to HMIs, historians, and OT servers
• remote monitoring and performance tuning
• emergency recovery during downtime events

The problem is that remote access can become a direct, privileged pathway into the systems that run a physical process—often with fewer layers of control than in IT.

OT-specific risk drivers

1) Privilege is higher by default
OT vendors frequently need admin-level access to do their job. Admin access in OT can mean:

• changing HMI/SCADA configurations
• modifying control logic or recipes
• installing drivers and vendor runtimes
• changing network settings and trust relationships
• accessing backups and project files

2) Availability and safety constraints reduce change tolerance
OT environments often cannot accept frequent credential resets, agent deployments, or disruptive security changes. That reality leads to “temporary exceptions” that linger.

3) Tool sprawl is common
Teams may accumulate vendor VPNs, remote desktop tools, and ad-hoc firewall rules because each supplier “has their own way.” Over time, you get:

• inconsistent authentication
• uncontrolled destinations
• poor visibility
• difficult offboarding

4) “Trusted relationships” are exploitable
Attackers don’t need to break your perimeter if they can compromise a vendor account, a vendor laptop, or a vendor’s remote support channel.

---

What “secure” means in OT remote access (security + operations)

A good OT vendor remote access design does two things simultaneously:

1. Reduces the probability of unauthorized access and lateral movement
2. Reduces the operational risk of supporting production systems

In practical terms, “secure remote access” means:

• access is explicitly approved, not implicitly available
• access is identity-bound (named users), not shared
• access is time-bound (just-in-time), not persistent
• access is scope-bound (allowlisted destinations/ports), not wide
• access is observable (logs + recordings), not opaque
• access is reversible (fast disable/offboarding), not sticky

If your design can’t be operated during a real outage, it will be bypassed. The best practice is to engineer for emergencies while keeping strong controls.

---

Common anti-patterns (and how they get exploited)

These are the patterns that make OT vendor access the “easy door.”

Anti-pattern 1: Vendor VPN terminates directly in the control network

Why it’s dangerous: bypasses OT DMZ controls and central monitoring; expands attack surface.

Fix: terminate vendor connections in the OT DMZ and broker further access.

Anti-pattern 2: Shared “vendor” accounts and static passwords

Why it’s dangerous: no attribution; offboarding is messy; credential reuse is common.

Fix: named accounts + MFA + periodic access reviews + removal of shared credentials.

Anti-pattern 3: Always-on tunnels “for convenience”

Why it’s dangerous: converts a support channel into a persistent backdoor.

Fix: just-in-time access windows; disable by default; emergency access via break-glass.

Anti-pattern 4: Unrestricted RDP/SMB/AnyDesk into OT

Why it’s dangerous: increases exploitability and lateral movement, often with weak logging.

Fix: brokered sessions on controlled jump hosts; destination allowlisting; session recording.

Anti-pattern 5: Firewall rules that never expire

Why it’s dangerous: old rules outlive projects, technicians, and even suppliers.

Fix: every exception gets an owner and an expiry date; review quarterly.

---

The reference architecture: OT DMZ + brokered access

If you want one “north star” design, it’s this:

Vendor remote access terminates in the OT DMZ and is brokered to specific OT assets through controlled jump infrastructure with MFA, JIT approvals, allowlists, and session recording.

High-level flow

1. Vendor authenticates to a controlled entry (VPN/portal/ZTNA)
2. Connection lands in the OT DMZ
3. Vendor starts a remote session on a jump host (or remote access gateway)
4. Jump host can reach only allowlisted targets in OT zones (SCADA, engineering, cell/area)
5. Session is logged/recorded; file transfers are controlled
6. Access expires automatically when the window ends

Text diagram (reference model)

Internet / Vendor Network        |   (MFA + Policy)        |Remote Access Entry (VPN or ZTNA)        |   ===== OT DMZ =====        |  Remote Access Gateway / Jump Host   - Session recording   - JIT approvals   - Tooling controlled        |   Conduits (deny-by-default)        |   ---- OT Zones ----   SCADA/HMI Zone     Engineering Zone     Cell/Area Zones   (limited ports)    (very restricted)    (machine-specific)

Why the OT DMZ is non-negotiable (in mature programs)

The OT DMZ provides:

• a choke point for monitoring
• a place to run remote tooling without exposing the control network
• a clean separation between business/remote networks and control networks
• a containment layer (you can cut vendor access fast without touching OT assets)

---

Best practices, explained (the controls that matter most)

Below are the highest-impact best practices, written as implementable requirements.

1) Terminate all vendor access in the OT DMZ (no direct-to-OT)

Goal: reduce exposure and centralize control.

Implementation notes:

• Put remote access gateways, jump hosts, and file transfer services in the OT DMZ.
• Do not allow vendor VPN subnets directly into Level 2/Level 1 networks.
• Require outbound-only from OT zones to DMZ where possible (pull, not push).

2) Enforce named identities and MFA for every vendor user

Goal: stop credential stuffing, reduce shared-account risk, enable attribution.

Best practice requirements:

• One identity per technician (no “vendor1”)
• MFA enforced for interactive access
• Strong password policy and lockout controls
• Rapid revocation when personnel change

3) Make access just-in-time (JIT) with approvals and auto-expiry

Goal: eliminate persistent access as the default.

Typical patterns:

• Access request includes: purpose, target assets, time window, change ticket number
• Approval by OT owner (and sometimes cyber)
• Auto-disable after the window ends

A practical baseline is: no vendor access outside defined windows.

4) Restrict destinations and protocols with allowlisting (deny-by-default)

Goal: prevent “vendor can reach everything” sprawl.

Control it at multiple layers:

• remote access gateway policies
• firewall conduits (between DMZ and OT zones)
• host firewalls (where feasible)

Allowlisting should be specific:

• vendor A can reach jump host → HMI-12 on TCP 3389 during approved window
• vendor B can reach EWS-02 only, not PLC networks directly

5) Use jump hosts or brokered sessions (not free-form network access)

Goal: constrain tooling, improve visibility, reduce lateral movement.

What a good jump host setup includes:

• hardened OS build
• minimal software
• no email/browsing
• clipboard controls (as needed)
• file transfer controls
• session recording
• separate admin accounts
• frequent rebuild capability (golden image)

6) Record and log sessions for Tier 1 vendor access

Goal: accountability, faster investigation, safer operations.

Record:

• who connected
• when they connected
• what assets they accessed
• session video/commands (where feasible)
• file transfers

Session recording is also an operational benefit: it supports troubleshooting, training, and post-event review.

7) Separate support access from engineering/programming access

Goal: protect the most consequential actions.

A strong pattern is:

• Support vendors can access HMIs/servers under strict scopes
• Engineering actions (controller downloads, logic changes) require:
  • higher approvals
  • supervised sessions
  • separate privileged role
  • stronger monitoring

8) Control vendor endpoints (device posture) when possible

Goal: reduce risk from compromised vendor laptops.

Depending on your model, require:

• managed endpoints with EDR
• disk encryption
• patching standards
• no local admin for normal use
• documented malware response process

If you can’t enforce posture directly, compensate by:

• restricting what vendor endpoints can reach (DMZ-only)
• eliminating direct file transfers into OT
• supervising high-risk sessions

9) Treat file transfer as a security boundary, not a convenience

Goal: prevent malware ingress and untracked changes.

Implement an OT “software intake” approach:

• file transfer only via controlled DMZ service
• scanning and integrity verification
• logging and retention
• approved repositories (no random USB or email attachments)

10) Operationalize offboarding (accounts, rules, tokens, tools)

Goal: prevent ghost access.

Offboarding must include:

• disabling accounts
• revoking MFA tokens/certs
• removing firewall exceptions
• uninstalling remote tools
• rotating shared secrets (if any exist)

---

Access models: VPN vs ZTNA vs vendor tools (and what to choose)

Remote access technology is not the architecture. Your control points matter more than the brand.

Model A: Traditional VPN (with strong controls)

Pros:

• common, well understood
• can be robust in constrained environments

Cons:

• easy to over-permission
• can create “network-level” trust if not tightly scoped

Best practice when using VPN:

• VPN terminates in OT DMZ only
• per-user MFA
• per-vendor subnet separation
• strict routing (no “full tunnel into OT”)
• access via jump host, not directly to endpoints

Model B: ZTNA / brokered access (application-level)

Pros:

• better default posture (least privilege)
• easier to restrict to specific apps/hosts
• often stronger identity integration

Cons:

• may require more design to fit OT constraints
• may not support every protocol without gateways

Best practice with ZTNA for OT:

• still use OT DMZ gateways
• broker to jump hosts and specific internal services
• keep conduit rules explicit and auditable

Model C: Vendor-managed remote tools (AnyDesk/TeamViewer-style)

Pros:

• fast deployment
• vendor familiarity

Cons:

• tool sprawl and inconsistent logging
• harder central governance
• increased risk if unmanaged

Best practice if you must allow them:

• run tools only on DMZ jump hosts (not on OT endpoints)
• require MFA and named accounts
• enforce session recording
• block direct inbound to OT zones
• disable when not in use

Recommendation: Standardize on one enterprise-managed approach (VPN or ZTNA) plus DMZ/jump host patterns, and prohibit ad-hoc vendor tools except by exception.

---

Identity and privilege: named accounts, MFA, PAM, and least privilege

Remote access failures are often identity failures.

Named accounts: the foundation

Require:

• unique usernames per vendor technician
• documented owner and sponsor
• access expiration date

MFA: minimum viable protection

MFA should be required for:

• remote access entry (VPN/ZTNA)
• privileged actions (where feasible)
• jump host login

If MFA is “not possible,” treat that as a Tier 1 supplier compliance gap and either redesign access or reduce scope.

PAM patterns that work in OT

Even without full PAM tooling, implement the behaviors:

• No standing privilege: vendor accounts are not permanent local admins everywhere.
• Role separation: support role vs engineering role.
• Just-in-time elevation: elevate only during approved windows.
• Credential vaulting for shared secrets: some OT devices still require shared credentials; vault and rotate them.

Least privilege: define it by task, not job title

Create task-based roles, for example:

• “HMI Support – View/Restart Services”
• “Historian Admin – Limited”
• “EWS Engineering – PLC Download Allowed” (high control tier)

Tie each role to:

• specific systems
• specific protocols
• specific time windows
• specific approvals

---

Network control: zones, conduits, and allowlisting

In OT, segmentation is your safety net when identity controls fail.

Zone-based design (practical)

You don’t need perfection on day one. Start with these zones:

• OT DMZ: remote access gateways, jump hosts, file transfer services
• SCADA/HMI zone: operator interfaces, SCADA servers
• Engineering zone: engineering workstations, project repositories
• Cell/Area zones: machine-level networks and controllers

Conduits: make them explicit

A conduit is the controlled path between zones.

Best practices:

• deny-by-default rules
• allow only required protocols and destinations
• document the business purpose for each conduit
• review conduits quarterly

Allowlisting: where to enforce it

Use multiple layers:

• remote access gateway policy (who can start what session)
• firewall rules (what the jump host can reach)
• host firewall (what the target will accept)

This multi-layer approach means that if one control is misconfigured, another catches it.

---

Session security: recording, command control, and supervised access

Vendor remote sessions are high-value for attackers and high-risk for operations.

Session recording: what “good” looks like

For Tier 1 vendor access, record:

• screen video (or equivalent)
• metadata: user, time, duration, source IP, target assets
• file transfers
• privileged actions

Keep recordings long enough to support investigations and audits (many orgs choose 90–180 days, but set what fits your governance).

Supervised access (a practical compromise)

If vendors resist controls, supervised access often works operationally:

• vendor connects to DMZ jump host
• OT staff observes the session
• OT staff approves high-risk steps live
• session is recorded

This can satisfy warranty/support needs while reducing uncontrolled changes.

Command control (where feasible)

For SSH and administrative shells, consider solutions that can:

• log commands
• restrict dangerous commands
• require re-authentication for privileged actions

---

File transfer and “software intake” (the overlooked risk)

Remote access is often used to move files: patches, drivers, project files, log bundles. That file movement is frequently where malware enters.

Best practice: separate “interactive remote access” from “file movement”

Implement a controlled file transfer service in the OT DMZ:

• vendor uploads files to DMZ repository
• automated scanning and integrity checks occur
• OT team promotes files into OT zones as needed
• everything is logged

Minimum controls for OT file intake

• allow transfers only through approved channels
• scan with multiple engines if possible
• verify signatures/hashes
• keep a manifest: filename, version, vendor, hash, date, purpose, ticket number
• require approvals for production installs

Project file integrity (engineering risk)

Engineering project files are high consequence. Protect them with:

• restricted access (only engineering role)
• backups and versioning
• integrity monitoring on repositories
• change records tied to tickets

---

Monitoring and detections that actually work in OT

Monitoring fails when it’s too noisy. Focus on high-signal vendor behaviors.

Log sources to prioritize

• VPN/ZTNA authentication logs
• jump host session logs and recordings
• firewall allow/deny logs for conduits
• Windows security logs (jump hosts, OT servers)
• remote access gateway audit trails

High-signal detections

• vendor login outside approved window
• vendor login from new country/ASN (if applicable)
• repeated failed logins
• attempts to reach non-allowlisted OT assets
• file transfers into OT outside intake process
• new remote admin tools installed on jump host
• controller programming/download events from non-engineering hosts

Operational response playbooks (keep them simple)

Define what happens when an alert triggers:

1. confirm whether a vendor session is scheduled
2. if unscheduled, disable vendor access (JIT makes this easy)
3. isolate jump host if necessary
4. notify OT owner and security
5. preserve session recordings and logs
6. review accessed assets and changes
7. rotate credentials if compromise suspected

---

Break-glass access for outages (securely)

OT teams will always need an emergency option. The goal is to make break-glass:

• controlled
• monitored
• time-limited
• reviewable

A workable break-glass model

• break-glass accounts exist but are disabled by default
• enabling requires two-person approval (operations + security)
• access is limited to a pre-defined scope
• session recording is mandatory
• access expires automatically (e.g., after 2 hours)
• a post-event review is required within 72 hours

Break-glass without logging is just an unmonitored backdoor.

---

Vendor onboarding and offboarding (make it a lifecycle)

Secure remote access lives or dies by operational discipline.

Vendor onboarding checklist (what must be true before access is granted)

• vendor is inventoried and tiered (Tier 1–4)
• technical owner assigned (OT sponsor)
• access method approved (standard tool only)
• named accounts created with MFA
• roles/scopes defined (targets + protocols)
• JIT workflow established (ticketing + approvals)
• session recording enabled (Tier 1 required)
• file transfer method defined (DMZ intake)
• emergency contact and incident notification path confirmed

Vendor offboarding checklist (what must be removed)

• disable and delete accounts (AD/local/app)
• revoke MFA devices/tokens/certs
• remove VPN/ZTNA group membership
• remove firewall rules and routes
• uninstall vendor remote tools
• rotate shared secrets (device creds, service accounts if impacted)
• archive logs/recordings as required
• update supplier inventory

The quiet killer: technician turnover

Require the supplier to notify you when personnel changes occur, and validate access lists quarterly for Tier 1.

---

Policy and contract language you can enforce

Your remote access design won’t survive procurement pressure unless your expectations are contractual.

Policy statements (short, enforceable)

• All OT vendor remote access must terminate in the OT DMZ and be brokered through approved jump hosts or gateways.
• Vendor access requires named accounts and MFA.
• Vendor access must be time-bound and approved (JIT).
• Vendor access is restricted to allowlisted targets and protocols.
• Tier 1 vendor sessions are logged and recorded.
• File transfers into OT must use the approved intake process.
• Non-compliant remote tools are prohibited unless explicitly approved as an exception.

Contract clause ideas (practical)

• No shared accounts and MFA required
• Incident notification SLA (e.g., within 24–72 hours if vendor compromise could impact you)
• Subcontractor disclosure and same-control requirements
• Right to request evidence: MFA enabled, training completion, access logs
• Offboarding obligations: vendor must notify customer of personnel departures within a defined window

---

KPIs and audit evidence: proving the controls are real

You’ll be asked “Is this working?” and “Can you prove it?”

KPIs that matter

• % of vendor access terminating in OT DMZ (target: near 100%)
• % of vendor accounts that are named + MFA-enabled (target: 100%)
• % of vendor access that is time-bound (JIT) vs persistent (target: high JIT)
• % of shared vendor accounts remaining (target: 0)
• % of Tier 1 sessions recorded (target: near 100%)
• median time to offboard access after contract end (target: days, not months)
• % of firewall exceptions for vendor access and average age
• % of blocked attempts to non-allowlisted OT assets (trend should decrease as scopes improve)

Audit evidence to retain

• architecture diagrams showing OT DMZ termination
• access request/approval records (tickets)
• session recordings and logs
• quarterly access review reports
• firewall rule reviews and expiry tracking
• incident response test results (tabletops)

---

30/60/90-day implementation roadmap

First 30 days: stop uncontrolled access

• inventory all vendor remote access methods and accounts
• disable stale VPNs, accounts, and “temporary” tunnels
• pick one standard access method (VPN or ZTNA) and freeze tool sprawl
• implement basic MFA for vendor access entry
• require tickets/approvals for Tier 1 vendors (even if manual)

Outcome: fewer unknown pathways, immediate risk reduction.

Days 31–60: build OT DMZ brokered access

• deploy/harden OT DMZ remote access gateway and jump host
• implement destination allowlisting from DMZ to OT zones
• enable session logging and recording for Tier 1
• define vendor roles/scopes for the top 5 highest-risk suppliers
• implement a file intake process in the DMZ

Outcome: vendor access becomes controlled, observable, and bounded.

Days 61–90: operationalize and scale

• implement JIT workflows with auto-expiry
• build detections and runbooks for vendor behaviors
• start quarterly Tier 1 access reviews
• implement break-glass workflow with monitoring
• update contract templates and supplier requirements for renewals

Outcome: remote access becomes a program, not a one-off configuration.

---

Copy/paste checklists and templates

Template: OT Vendor Remote Access Standard (one page)

• Entry: VPN/ZTNA with MFA
• Termination: OT DMZ only
• Broker: Jump host or remote access gateway with session recording
• Scope: Allowlisted targets and protocols, deny-by-default conduits
• Time: JIT approval windows, auto-expiry
• Identity: Named accounts only; no shared credentials
• Files: DMZ intake process only; scanning + hash/signature verification
• Monitoring: Logins, sessions, destination attempts, file transfers, admin actions
• Emergency: Break-glass with two-person approval + recording + post-review
• Offboarding: Disable accounts, remove rules, revoke tokens, uninstall tools

Checklist: Vendor access request (per session)

•  Vendor technician name (named account)
•  Company and support contract reference
•  Purpose and change ticket number
•  Target assets (hostnames/IPs)
•  Required protocols (RDP/SSH/vendor app)
•  Time window requested (start/end)
•  Approval from OT owner
•  Session recording enabled (Tier 1 required)
•  File transfer required? If yes, use DMZ intake
•  Post-work validation steps defined

Checklist: Quarterly Tier 1 vendor review

•  Accounts list validated (no departed technicians)
•  MFA enforced for all accounts
•  No shared accounts
•  Scopes still correct (targets/protocols)
•  Firewall exceptions reviewed and expiring rules removed
•  Session recordings spot-checked
•  Incidents/near misses reviewed with supplier
•  Offboarding events completed within SLA

Template: Firewall rule documentation (vendor conduit)

• Rule name:
• Source: DMZ jump host / gateway
• Destination: specific OT asset(s)
• Ports/protocols:
• Business purpose:
• Owner:
• Approval ticket:
• Created date:
• Expiry date:
• Review date:

---

FAQ

Do we need to ban OT vendor remote access to be secure?

Usually no. The best practice is to engineer it: terminate in an OT DMZ, broker through jump hosts, enforce MFA and named accounts, restrict scope with allowlisting, and log/record sessions.

What is the single most important control?

Architecturally: OT DMZ termination + brokered access. Operationally: named accounts with MFA and time-bound (JIT) access.

VPN or ZTNA—what’s better for OT?

Either can be secure if it supports OT DMZ termination, strong identity controls, and tight scoping. ZTNA often makes least privilege easier; VPN can be fine if routing is strictly constrained and access is brokered through jump hosts.

How do we handle vendors who insist on their own remote tool?

Prefer a standard enterprise method. If you must allow it, run it only on DMZ jump hosts with MFA and session recording, and prohibit installing it directly on OT endpoints.

What about emergency troubleshooting when production is down?

Use a break-glass workflow: two-person approval, time-limited enablement, mandatory session recording, and a post-event review. Design it upfront so it’s usable under stress.