Official intent
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 ↗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.
Who this applies to: Every environment where a vendor, integrator, or off-site engineer can reach production equipment — which is nearly universal once you count the links added during commissioning.
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.
Risks this reduces
- Always-on vendor tunnels that nobody remembers and nobody monitors
- Shared vendor credentials reused across customers and sites
- Direct remote connections that terminate on a controller rather than in a controlled zone
- Remote sessions with no record of who connected or what they changed
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.
Who owns it
OT / network administrator
Plant / OT leader, IT / security lead, Vendors
Medium
Medium
Ownership is a named person, not a department. If nobody can be named, that is the first finding.
Dependencies and prerequisites
Leans on: OT-03 — OT network segmentation, OT-01 — OT identity and access control
- A complete map of every remote and vendor pathway into OT, including modems and cellular links
- A DMZ or controlled zone where a jump host can live
- An agreed emergency-access procedure so support is never silently severed
Action timeline
- Inventory every remote and vendor access path into OT
- Disable any unknown or always-on tunnel
- Disable any remote pathway you cannot identify an owner and a business reason for
- Route the highest-risk remaining pathway through a brokered jump host with strong authentication
- Route remote access through a controlled jump host / DMZ
- Require strong authentication (MFA) for all remote entry
- Make access time-bound — enabled per session or window
- Log all remote sessions and their actions
- Add supervision or recording for vendor sessions
- Provision and revoke vendor access per engagement
The 90-day target for this practice is the Measured level below: coverage and effectiveness are reported, and exceptions are handled rather than accumulated.
Step-by-step implementation
- Inventory all remote and vendor access into OT, including modems and forgotten tunnels.
- Force remote access through a brokered jump host in an IT/OT DMZ — never directly to a device.
- Require strong authentication and least privilege for every remote connection.
- Enable access only for the session or window it is needed, then disable it.
- Log — and where possible supervise or record — remote sessions, and revoke vendor access after each engagement.
What good looks like
Seven levels, used identically across every practice, scorecard, and download on this site. The distinction that matters most is between having a tool, deploying it to the correct scope, and operating it consistently.
- Absent
Standing tunnels and direct vendor connections; no inventory of who can reach what.
Is there anything at all — a tool, a document, a person who owns it? - Documented
Every remote and vendor pathway is inventoried and a policy defines brokered, time-bound access and emergency procedures.
Is the intent written down, with a named owner and a scope? - Configured
A jump host exists in a controlled zone and at least one pathway is brokered through it with strong authentication.
Is it switched on and set up somewhere — even if only in part of the estate? - Deployed
All remote access goes through the broker, always-on tunnels are removed, and sessions are logged.
Does it cover everything in scope, with the exceptions written down? - Measured
Session logs and provisioning records are reviewed, and standing access outside an engagement is counted and driven to zero.
Can you state a number for coverage or effectiveness, and show the trend? - Governed
Vendor access is provisioned and revoked per engagement under a named owner, with sessions supervised or recorded where warranted.
Is there an accountable owner, a review cadence, and retained evidence?
Validation procedures
Until these pass, the practice is configured — not deployed.
- 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
Remote/vendor access policy with time-bound and emergency procedures
Jump-host/DMZ design and remote-access account settings
Remote session logs and per-engagement provisioning records
Test showing direct remote access is blocked; access-revocation records
Retaining these supports your own assurance and gives a reviewer something concrete to examine. It does not constitute an assessment or satisfy a contractual requirement on its own.
Operating metrics
| Metric | How it is calculated | Directional target |
|---|---|---|
| Brokered access share | Remote sessions arriving through the jump host ÷ all remote sessions into OT. | 100%. |
| Standing access outside engagements | Vendor accounts or tunnels enabled with no active engagement. | Zero. |
| Session log review | Remote sessions reviewed against an expected engagement ÷ sessions logged. | 100% of vendor sessions; sampled for internal sessions. |
Targets are directional guidance for your own programme, not compliance thresholds.
Common failure modes
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.
Two sized paths
Two changes do most of the work: no always-on vendor tunnels, and every remote session goes through one jump host with MFA that you enable when the vendor calls and disable when they finish. Write down the emergency path so nobody quietly reopens a tunnel 'just in case'.
Provision vendor access just-in-time per engagement with least privilege, record or supervise sessions on critical systems, and reconcile session logs against work orders so an unexplained connection is an investigable event rather than a line in a log.
Tool categories
Categories, not recommendations. This site ranks no vendors and accepts no paid placement.
Tightening remote access can cut off a vendor during a breakdown — and a vendor who cannot reach a misbehaving system when the plant needs them is a safety problem, not only a support problem. Coordinate with operations and the vendor before changing a pathway, keep a tested emergency-access procedure that does not require the vendor's old tunnel, and stage changes so support is never severed without notice.
Framework mappings
Independent mappings are aids to your own analysis — not authoritative equivalence, not coverage, and not a compliance determination. Read the caveat on every row before using it.
Why: The publication addresses brokered, monitored, time-limited remote access to control environments as the expected pattern.
What this does not claim: 800-82 is guidance, not a compliance standard.
Why: The practice guide demonstrates implemented secure remote-access architectures for OT — the brokered, authenticated, time-bound pattern this practice builds.
What this does not claim: A practice-guide demonstration, advisory by nature. Its example architectures inform design choices; they impose no requirement and must be adapted to your plant.
Why: The requirements for access via untrusted networks and remote session termination describe this practice's mechanisms.
What this does not claim: IEC 62443 is a voluntary industrial standard; conformance is a separate, scoped exercise. The specific requirement identifiers are pending verification against the licensed normative text and should be treated as directional until that check completes.
Why: The outcome for managing access permissions incorporating least privilege covers brokered, time-bound vendor access.
What this does not claim: The CSF describes outcomes, not testable controls.
Method: Read against the primary source text, then classified by relationship type and confidence. No automated mapping tool was used. How mappings are made →
NIST SP 800-171 relationships have their own requirement-level section below, with links into the full mapping experience.
Related NIST SP 800-171 requirements
Requirement-level relationships from the site’s independent 800-171 mapping. Each one names what it does and does not claim — a practice supports implementation of a requirement; it never satisfies one by itself. Expand a row for the rationale and caveat.
NIST SP 800-171 Rev. 2
3.1.12Remote access monitoring and controlPartial implementation supportModerate
Why: Brokered, logged, time-bound remote access is this requirement's substance enacted for OT: every vendor and off-site pathway inventoried, sessions arriving through a monitored broker, and session records reviewed.
What this does not claim: This mapping applies only to OT components that process, store, or transmit CUI, or that provide security protection for those components — organizational scoping determines applicability. The practice also covers OT and vendor pathways only; workforce remote access into the corporate IT estate, which the requirement equally covers, is outside its scope.
Review status: Technical review complete.
Open the 3.1.12 page →3.1.14Managed access control pointsPartial implementation supportModerate
Why: A jump host in a controlled zone that all vendor and remote OT sessions must traverse is a managed access control point by definition — the practice's core architecture is the routing this requirement names.
What this does not claim: Covers the OT pathways only; the enterprise's own remote entry points need the same consolidation under separate work. The relationship also weakens wherever legacy links — modems, cellular gateways, vendor tunnels added at commissioning — still bypass the broker, which is precisely the population hardest to find and the reason the practice's pathway inventory must precede any coverage claim.
Review status: Technical review complete.
Open the 3.1.14 page →3.1.15Privileged remote access authorizationPartial implementation supportModerate
Why: Vendor sessions provisioned per engagement, time-bound, and supervised or recorded are how remote execution of privileged commands gets authorized in practice — remote OT work is almost always privileged work, so the practice's brokering discipline lands directly on this requirement's subject.
What this does not claim: Brokering and recording sessions is not the same as the written authorization the requirement centers on: which privileged operations may be performed remotely, by whom, must still be documented as a deliberate decision. The requirement also spans remote privileged work across the whole boundary — IT servers, identity infrastructure, security tooling — which this OT-focused practice does not reach.
Review status: Pending NIST SME review.
Open the 3.1.15 page →3.7.5Nonlocal maintenance authenticationPartial implementation supportHigh
Why: Nonlocal maintenance sessions into production equipment are the vendor remote-access pathways this practice exists to govern, and its operating pattern matches the requirement's two clauses directly: sessions open through a brokered jump host with multifactor authentication, are enabled per engagement, and are disabled when the work ends rather than left standing.
What this does not claim: The practice governs pathways into OT; nonlocal maintenance of enterprise systems — vendor support tunnels into servers, RMM platforms, appliance consoles — is outside its scope and needs the same brokered treatment separately. The emergency-access procedure the practice rightly keeps for breakdowns must itself authenticate and terminate to the same standard, or it becomes the standing tunnel the requirement prohibits.
Review status: Pending NIST SME review.
Open the 3.7.5 page →3.7.6Maintenance personnel supervisionContextual relationshipLow
Why: The practice's supervised or recorded vendor sessions give the organization a working mechanism for overseeing remote maintenance performed by personnel who hold no access authorization — the remote face of what this requirement asks for.
What this does not claim: Directional only. The requirement is an oversight discipline about people — determining who holds access authorization and supervising those who do not, on site as much as remotely — and the practice neither makes that determination nor establishes the on-site escort process. Session recording informs the remote slice; the rest is separate work.
Review status: Pending NIST SME review.
Open the 3.7.6 page →NIST SP 800-171 Rev. 3
03.01.12Remote AccessDirect implementation supportHigh
Why: Brokered, logged, time-bound vendor pathways are the consolidated remote-access requirement in operation: the broker is the managed access control point, the time-bound grant is authorization before connection, and vendor maintenance work is remote privileged execution authorized case by case.
What this does not claim: Supports implementation of the requirement for the OT vendor pathway; it does not carry the whole scope. Workforce remote access to business systems, admin portals, and the per-type usage-restriction documentation the requirement opens with all sit outside this practice, and the organization-defined parameters still have to be written. Session encryption depends on the broker's configuration, not on the pathway pattern alone.
Review status: Pending NIST SME review.
Open the 03.01.12 page →03.07.05Nonlocal MaintenanceDirect implementation supportModerate
Why: Brokered, logged, time-bound vendor remote access is nonlocal maintenance discipline by another name: the practice's gateway enforces authentication at session establishment, its approval-per-window model is the requirement's 'approve and monitor' in operation, and time-bound access makes termination structural rather than trusted.
What this does not claim: The requirement covers nonlocal maintenance across the whole environment — IT infrastructure, network gear, and business systems maintained remotely, not only OT pathways — and those channels need the same treatment separately. Replay-resistant multi-factor authentication at session establishment is a specific technical bar the chosen gateway must actually clear; a jump host with passwords and a timer does not.
Review status: Pending NIST SME review.
Open the 03.07.05 page →Review status
| Technical review | Reviewed — pending SME sign-off |
|---|---|
| Editorial review | Reviewed |
| Reviewed by | inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering |
| Last reviewed | |
| Official source verified | |
| Content version | 1.1 |
This guide has been reviewed by practitioners but is awaiting sign-off from a subject-matter expert in this specific domain. Treat the safety and change-control guidance as a floor, not a ceiling, and validate it against your own process and vendor requirements.