Independent DIB implementation resource — not affiliated with or endorsed by the U.S. Department of WarView the official DoW campaign ↗
Brilliant at the BasicsDIB Resource Center
OT-06OPERATIONAL TECHNOLOGYOFFICIAL INTENTEXPERT REVIEWED

Remote Access Pathways

Remote access is how vendors keep equipment running — and how attackers get to the plant floor. The safe pattern is brokered access: connections pass through a controlled jump host in a DMZ, require strong authentication, are enabled only for the window they are needed, and are fully logged and ideally supervised. No always-on VPNs into OT, no direct vendor tunnels to a controller.

AUTHOR inDirectIT EditorialREVIEW STATUS SME review completeUPDATED 2026-07-21SOURCE CHECKED 2026-07-19
EXPLAINER · 5 SCENES · ≈40 SEC · CAPTIONS, NO AUDIO

OT-06 in 40 seconds

The problem, the plain-words meaning, three key moves, and what “done” looks like.

Official intent

What the campaign asks for

Make vendor and remote access to OT brokered, logged, and time-bound — never standing or direct. The official source remains authoritative.

Read the official campaign ↗

Why it matters

Standing remote access is a permanent, often forgotten door with the vendor's password on it. Compromise of a vendor or a shared credential then lands directly in production. Brokering, time-bounding, and logging access shrinks that exposure to a supervised window and gives you a record of who did what.

Coordinate before touching production

Tightening remote access can cut off a vendor mid-support or during an emergency. Coordinate with operations and vendors before changing pathways, keep a tested emergency-access procedure, and stage changes so support is never silently severed when the plant needs it.

Minimum / Strong / Advanced

1
Minimum

All remote and vendor access paths are inventoried; direct, always-on tunnels into OT are removed or brokered.

2
Strong

Access goes through a jump host in a DMZ with strong authentication, is enabled per session/window, and is logged.

3
Advanced

Sessions are supervised or recorded, access is least-privilege and just-in-time, and vendor accounts are provisioned and revoked per engagement.

Implementation timeline

First 24 hours
  • Inventory every remote and vendor access path into OT
  • Disable any unknown or always-on tunnel
Next 30 days
  • Route remote access through a controlled jump host / DMZ
  • Require strong authentication (MFA) for all remote entry
Next 60 days
  • Make access time-bound — enabled per session or window
  • Log all remote sessions and their actions
By day 90
  • Add supervision or recording for vendor sessions
  • Provision and revoke vendor access per engagement

Implementation steps

  1. Inventory all remote and vendor access into OT, including modems and forgotten tunnels.
  2. Force remote access through a brokered jump host in an IT/OT DMZ — never directly to a device.
  3. Require strong authentication and least privilege for every remote connection.
  4. Enable access only for the session or window it is needed, then disable it.
  5. Log — and where possible supervise or record — remote sessions, and revoke vendor access after each engagement.

Validation

  • Attempt to reach an OT device remotely without going through the jump host — it must fail.
  • Confirm no always-on vendor tunnel remains enabled between support visits.
  • Verify remote sessions are logged and vendor access was revoked after the last engagement.

Evidence to retain

Governance

Remote/vendor access policy with time-bound and emergency procedures

Configuration

Jump-host/DMZ design and remote-access account settings

Operations

Remote session logs and per-engagement provisioning records

Validation

Test showing direct remote access is blocked; access-revocation records

Common failure modes

What looks done but is not

An always-on vendor VPN nobody remembers, a shared vendor login used across sites, and remote access that is logged but never reviewed. Access that is convenient for the vendor at all times is convenient for an attacker at all times.

Framework mappings

Independent mappings are aids, not authoritative equivalence or compliance determinations.

FrameworkRequirementRelationshipConfidence
NIST SP 800-82 Rev. 3Remote access (ICS overlay)DirectHigh
NIST SP 800-1713.1.12SupportingModerate
NIST CSF 2.0PR.AA-05SupportingModerate