How Do You Safely Control and End OT Vendor Remote Access?

Authorize OT vendor remote access for a named task, target and operating condition, with a local operational owner and a tested termination procedure. Restrict the path and privileges to that work. At completion or during an incident, verify separately that new connections are denied, existing authority is removed, ongoing maintenance activity is understood, and the physical process is in an acceptable state. A closed VPN or remote desktop window proves none of those outcomes by itself.

The important distinction is between ending access and ending its consequences. A vendor may already have started an operation, changed a configuration or created another access path. Disconnecting the interactive channel does not logically establish that the operation stopped or the change disappeared. Equally, abruptly interrupting a legitimate maintenance activity may create a different operational problem. The organization needs a predetermined way to decide which action is appropriate.

I would treat remote maintenance as a bounded engineering transaction rather than a permanent relationship between two networks. The analysis below develops an authorization record, an access-path review and a termination acceptance method. The worked scenario is invented. No plant connection, equipment test or field validation is claimed, and none of the proposed exercises should be interpreted as permission to experiment on a live process.

Define the work before granting the connection

A request to let a supplier troubleshoot the plant is too broad to authorize. Identify the equipment and function, the reason for access, the permitted operations and the process condition under which the work may occur. Reading a diagnostic record, altering an alarm configuration and uploading control logic require different decisions, even when the same engineering tool can perform all three.

NIST's OT security guidance says remote access should be justified, limited to business need and prevented from circumventing safety or security controls. It also calls for operational awareness, monitoring and removal when access is no longer required (Stouffer et al., 2023, Section 6.2.10). Those principles become actionable when the approval describes a specific unit of work.

I propose recording each grant as person, purpose, target, operation, operating condition, time boundary and termination authority. This is an organizational design proposal, not a standard-defined data structure. The grant should also identify the route and the evidence required to close it. An approval can then be checked against what the access system actually permits.

The operating condition matters as much as the clock. A maintenance window does not establish that the equipment is ready for a change. The process may be carrying a different load, a redundant unit may be unavailable, or an operator may be responding to another fault. A valid time window should not silently override a condition that made the work acceptable in the first place.

Give the local sponsor authority over scope, not merely responsibility for scheduling. If diagnosis reveals a need for a different action, the sponsor must be able to pause the task and obtain the appropriate change decision. The vendor's expertise is valuable input, but it does not transfer the asset owner's responsibility for operational consequences.

Establish which asset and dependency the vendor will reach

An IP address is a routing destination, not a complete description of an operational asset. Record the device or service identity, its physical function, the engineering environment used to maintain it and the consequences of losing access or control. If the target is an engineering workstation, include the downstream assets that workstation can administer.

The joint OT inventory guidance combines an asset inventory with a taxonomy based on function and criticality and describes maintaining the inventory through the asset lifecycle (Cybersecurity and Infrastructure Security Agency [CISA], Environmental Protection Agency, et al., 2025). For remote maintenance, I would use that information to distinguish the approved target from the larger set of reachable systems. An accurate device list is a starting point; an access decision also needs relationships.

For example, a supplier may request access to one controller but use a project repository shared by several production units. The controller restriction does not necessarily constrain what can be changed in that repository. Conversely, a tightly scoped diagnostic interface may provide the required information without giving the supplier interactive use of the whole engineering workstation. Compare the required function with the available interfaces before accepting the broadest one.

Keep the record current when addresses, equipment or support arrangements change. A firewall object that still carries an old machine's name can create misplaced confidence after the underlying address is reused. Resolve the target through the approved inventory and actual configuration at activation time, then preserve the mapping with the maintenance record.

This is narrower than a complete OT security risk assessment. The immediate decision is whether this access grant reaches this operational function under known conditions. A wider assessment supplies the consequence model; it should not replace verification of the actual path.

Model the entire path, including its administration

Draw the connection from the vendor's device through identity services, access gateway or broker, boundary controls, maintenance host and target. Add management interfaces and the identities capable of changing each boundary. An encrypted connection can protect traffic while still delivering excessive authority to a compromised or insufficiently controlled endpoint.

NIST's enterprise remote-access guide includes organization-controlled, third-party-controlled and personally owned client devices in its security considerations (Souppaya & Scarfone, 2016). Its general IT setting does not establish an acceptable OT endpoint policy. It does establish why the connecting device belongs in the threat model rather than disappearing behind the phrase authenticated vendor.

A controlled access broker can reduce direct reachability and centralize decisions, but its administrative plane becomes important. If the same broadly privileged corporate account can change the OT boundary and approve supplier sessions, compromise of that account may defeat the apparent separation. Review administration of the gateway, identity policy and maintenance hosts alongside the vendor-facing workflow.

The UK National Cyber Security Centre's OT workstation guidance recommends identities specific to OT and separated from IT for access to privileged workstations. It also explains why obsolete software can undermine confidence in apparent low-privilege application roles (National Cyber Security Centre [NCSC], 2025). A screen labeled read-only is not persuasive evidence if the surrounding workstation offers a more powerful route to the same system.

I would evaluate file transfer, clipboard redirection, command execution, local credential use and onward connections as separate capabilities. Disable or constrain what the task does not require, using supported controls and compatibility testing. If a product cannot enforce a needed distinction, record that limitation and select a different interface, a supervised procedure or an explicitly accepted broader grant. A policy statement cannot create a technical boundary the product lacks.

Compare architectures without treating a reference build as certification

The strongest pattern depends on the task. A narrowly exposed diagnostic service may be sufficient for observation. A brokered interactive session may be necessary for specialized engineering software. A remote connection into a broad network segment usually leaves more of the authorization burden to downstream controls. The relevant comparison is the authority available after authentication, not the product category on the procurement form.

NIST's June 2026 water and wastewater practice guide describes three representative remote-access implementations. Its safety discussion explicitly assumes that a utility has evaluated the risks and decided to proceed with two-way access; it also identifies alternatives such as on-site operation and one-way alarming (Tang et al., 2026, Sections 2–3). The examples are useful implementation evidence, not proof that a particular plant is safe to connect.

Compare candidate designs against the same maintenance task. Can the vendor reach only the designated target? Can the owner approve activation locally? What happens if the identity provider, broker or external connection becomes unavailable? Which functions can continue without remote support, and which require an on-site capability? A design can improve confidentiality while creating a new dependency that changes recovery time.

Do not use a reference architecture to skip the dependency analysis. A small utility may prefer fewer moving parts and a narrower support model. A larger operator may need central oversight but local termination capability. Neither arrangement is inherently sufficient. The choice should be supported by the critical functions, available staff, service commitments and evidence from representative testing.

CISA's primary mitigation guidance recommends removing public internet exposure of OT devices and, when remote access is essential, using protected connectivity, strong authentication and least privilege (CISA, Federal Bureau of Investigation, et al., 2025). That establishes a direction of travel. It does not mean that placing a VPN in front of an unrestricted engineering environment completes the access design.

Authorize the session separately from the change

The right to connect is not the right to perform every operation available after connection. I would distinguish observation, diagnosis, staging an artifact and applying a change. Each step may need different process conditions, evidence and approval. Moving from one step to another should create an explicit decision rather than an informal extension of the original ticket.

NIST SP 800-53's nonlocal maintenance control calls for approval, monitoring, records and termination of connections when maintenance is complete. Its enhancements address session approval, notification and disconnect verification (Joint Task Force, 2020, MA-4). These are selectable control requirements to tailor appropriately, not a claim that citing the catalog establishes compliance or operational safety.

For a configuration change, identify the intended resulting state and how it will be checked. Preserve the authorized artifact and relevant pre-change baseline through the organization's change process. A vendor's statement that the upload finished is evidence of one claimed activity; it is not the same as confirmation that the approved configuration is active and appropriate for the current process.

Security-focused configuration management distinguishes baseline configuration, change control and ongoing monitoring of configuration state (Johnson et al., 2011). Applied here, that means the session's closing record should connect the approved change to the observed result. The baseline should not be silently updated merely to make an unexpected change look compliant.

There are legitimate emergency changes. Define their authority, minimum information and follow-up obligations before an emergency occurs. The expedited path should accelerate a decision, not remove the distinction between a vendor's recommendation and the owner's authorization. If the available evidence cannot support the proposed remote change, an on-site intervention or a different operating arrangement may be necessary.

Design the termination procedure in layers

The phrase turn off remote access conceals several different actions. Preventing a new login, closing a transport connection, logging off a maintenance host and canceling a running job are not interchangeable. Some can be controlled at the access boundary; others require application-specific or operational action.

Layer	What an effective control can establish	What it does not establish alone
New admission	The designated identity or route cannot start another authorized connection	An existing session has lost access
Network or broker path	The tested channel no longer carries the selected remote interaction	Another route, local credential or background agent is unavailable
Host or application session	The selected session has ended or lost the required authority	Every task started through it has stopped
Maintenance operation	The specific job reached a known stopped or completed state	Its effects have been reversed
Durable configuration	The actual resulting settings or logic have been assessed against the approved state	The physical process is operating acceptably
Operational condition	The responsible operator has checked the defined process conditions	All cyber access paths have been removed

Microsoft's Remote Desktop Services policy documentation provides a concrete example: a timed-out session can be disconnected or ended, with ending logging the user off and deleting the session from the server (Microsoft, 2026). These are distinct configured behaviors. Neither label should be treated as evidence about the termination semantics of every engineering application or the persistence of changes it made.

I would write a termination procedure that names the layer, responsible person, mechanism and expected observation. Where the tool cannot expose the state of a running operation, that uncertainty should constrain the permitted work or trigger an escalation. Do not hide it behind a green status at the outer gateway.

For scheduled completion, the procedure can coordinate orderly task closure, access removal and verification. For suspected compromise, containment may need to occur sooner and under different authority. The organization should predefine those branches with operations and safety specialists. An active threat is not a reason to improvise the physical consequences of isolation, and uncertainty is not a reason to leave every external route open indefinitely.

Decide what must continue after isolation

An isolation plan should identify which local control, monitoring and protective functions need to remain available. It should also identify external dependencies that cannot simply be removed, including any data flows necessary for coordinated operation. A broadly applied network cutoff may affect more than the vendor's maintenance session.

The 2026 joint secure-connectivity guidance calls for isolation planning linked to business continuity, testing, consideration of third-party contracts and attention to critical data flows whose loss could create unsafe conditions (NCSC et al., 2026, Principle 8). I would apply that principle at the level of the specific support route and then check the wider consequences of the mechanism used to disable it.

For example, disabling an interface that carries both maintenance traffic and required operational telemetry would have a different effect from revoking a brokered vendor session. Whether either action is acceptable depends on the actual architecture. Do not infer safety from the network diagram alone; validate the assumed process dependencies through the approved engineering review and representative test environment.

Separate failure behavior for the access service from failure behavior for the process. It may be appropriate for new vendor access to be denied when approval services are unavailable, while local control continues. That outcome must be designed and demonstrated. A rule described as fail-closed is incomplete unless it names the function that closes and the functions expected to remain available.

Likewise, fail-safe is not a universal instruction to stop equipment. The acceptable condition belongs to the process and its engineering constraints. This paper does not prescribe a shutdown sequence or replace a hazard analysis. It proposes that the cyber termination procedure explicitly reference the operational decision rather than assume it.

Close alternative paths and enduring authority

A controlled main gateway provides limited assurance if the vendor can also use an unmanaged support agent, an old local account or a separate modem. Include approved and discovered alternate paths in the access inventory. An outbound connection is still an access dependency when it establishes a channel through which remote authority can be exercised.

Historical incident evidence shows the consequence of ignoring exposure. The joint advisory on IRGC-affiliated actors describes compromised Unitronics PLCs that were publicly exposed and using default passwords (CISA et al., 2023). The relevant lesson is that reachable device interfaces and weak credentials can bypass an intended maintenance architecture. The advisory does not prove that every exposed PLC behaves identically or that a single access product would have prevented those incidents.

For each vendor relationship, record local maintenance accounts, service identities, remote software and any subcontractor access. Prefer individually attributable access where supported, and govern shared target credentials through a controlled mechanism rather than allowing uncontrolled copies. If the target cannot support the desired identity model, document the attribution and revocation limits and decide how the gateway and operational procedure will compensate.

Offboarding is therefore broader than disabling the supplier's federated identity. Check the target-side credentials, service integrations and configuration permissions actually used. Establish what happens when a named technician changes employers or a subcontractor changes. A support contract continuing with the same company does not establish that every person previously associated with it still needs access.

Do not confuse discovery with permission to probe fragile systems. Review configuration, inventories and available telemetry first, and plan any active verification through the appropriate authorization and safety process. The goal is a defensible account of access paths, not a scan result obtained at the expense of the operation.

Preserve evidence of both the work and its limits

A useful session record connects the request, approvals, identities, target mapping, start and end observations, significant actions and resulting configuration. Keep the original timestamps and the meaning of each clock. A gateway's end timestamp may describe transport closure rather than application logoff; those observations should remain distinguishable.

Video recording can help reconstruct an interactive session, but it is not automatically a complete audit of what the application or target did. Transfers, background operations and later effects may require other records. Decide which conclusions the evidence must support, then check that the chosen sources actually expose them. Avoid promising comprehensive monitoring when only the initial connection is logged.

The joint Secure by Demand guidance asks OT buyers to consider baseline logging, strong authentication and owner autonomy, among other product characteristics (CISA, National Security Agency, et al., 2025). I would turn those characteristics into procurement demonstrations: show the event generated by a change, the record available after a session ends and the owner's ability to remove vendor authority without waiting for the vendor to cooperate.

Logs and recordings can reveal proprietary process information, credentials displayed on screen or personnel details. Restrict access, choose retention based on the investigative purpose and govern exports to suppliers. The evidence trail should contain enough information to establish decisions without becoming a new source of unrestricted plant information or reusable secrets.

A closing statement should distinguish observed facts from vendor assertions and untested assumptions. For example: the broker refused reconnection by the test identity; the application owner confirmed the designated session ended; the operator checked the defined process indicators; the effect on an untested standby route remains unresolved. That is more useful than a single unqualified declaration that remote access was revoked.

Test the boundaries without experimenting on production

Begin with a representative test environment, spare equipment or other engineering-approved arrangement that has a known relationship to production. Document what differs: firmware, software, identity integration, network controls, licenses, process simulation and redundancy. A convenient lab can demonstrate a mechanism while leaving important operational behavior untested.

Use a harmless authorized task with an explicit expected result. Confirm that the vendor identity reaches the approved target and cannot perform a selected out-of-scope action. Then test expiry, manual termination and attempted reconnection as separate cases. Observe the downstream session and task state, not only the connection banner.

Failure tests should be selected through the engineering and safety process. Candidate cases include an unavailable approval service, loss of the access gateway, interruption of the remote channel and delayed receipt of a termination command. The question is whether the system follows the intended branch while required operational functions remain within their defined conditions. None of these tests is authorized on a live process merely because it appears in this article.

I would also test a scope change. Have the vendor request a harmless action outside the original grant and check whether a new decision is required. A negative result is useful only when the denial comes from the intended control, rather than from an unrelated outage or a mistyped target. Preserve the policy, identity and configuration versions used in the test.

Recovery and configuration restoration require their own acceptance work. The OT backup testing discussion addresses the separate question of proving restoration without using the live process as a test bed. A demonstrated ability to revoke a maintenance session does not establish that a changed controller can be restored correctly.

Work through one maintenance request to its actual end

Consider a hypothetical supplier asked to diagnose intermittent alarms at an unmanned pumping site. The approved task is observation through a designated maintenance host during a scheduled interval. The local operator remains responsible for process decisions. A broker mediates the supplier connection, and another independently managed function supports ordinary local control. These are invented assumptions, not a recommendation for a particular pumping installation.

The first acceptance question is whether the observation-only task can be enforced at the actual interface. If the maintenance host provides unrestricted engineering authority, the grant is broader than the request. The owner must narrow the interface, impose an appropriate supervised arrangement or explicitly reconsider the authorization. Calling the request diagnostic does not make the tool read-only.

During diagnosis, the supplier proposes changing an alarm parameter. That proposal creates a new change decision, including whether the current operating condition is suitable and how the result will be checked. If the change is not approved, the session can continue only within the original scope. If approved, its artifact and expected outcome become part of the record.

Suppose the test broker reports disconnection at minute 30 and denies a new connection at minute 31, but a separately observed application task remains active at minute 33. The evidence establishes two access-boundary observations and an unresolved downstream activity. It does not establish a three-minute universal revocation delay or prove that the active task is harmful. The task's identity, purpose and operational effect need assessment under the termination procedure.

The closing decision therefore has two parts: the access owner confirms the tested authorization is ended, and the operational owner confirms the relevant activity and process state are acceptable. If either cannot make that decision, the record remains open with a named follow-up and an appropriate containment or operating arrangement. A ticket deadline should not manufacture certainty that the system has not supplied.

Measure bounded access rather than the number of installed tools

Report critical maintenance paths with a current owner, approved scope and tested termination procedure. Identify standing exceptions, target-side credentials outside the broker's control and paths whose last acceptance test predates a material change. A percentage needs a defined denominator: documented critical paths, not every network address in an incomplete inventory.

Keep several outcomes separate: time to deny new admission, time to end the designated active session, time to establish downstream task state and time to confirm acceptable operation. They may have different owners and observation intervals. Combining them into one revocation-time metric conceals the exact boundary that needs improvement.

The strongest objection to this approach is operational complexity. Some sites have limited staff and depend on a vendor for urgent support. The answer is to reduce unnecessary access patterns and make the supported procedure workable out of hours. A simpler, narrower architecture with practiced local authority may be more defensible than a feature-rich system whose emergency route bypasses normal controls.

A second objection is that every session cannot justify a full engineering review. It should not need one if a defined class of work has an approved, tested procedure and its conditions still hold. Escalation belongs at changes in scope, operating state or evidence. Reusable procedures save effort by preserving justified decisions, not by treating every future task as identical.

This framework has not been validated in a controlled study. Its sources are official guidance, reference implementations and product documentation, plus historical incident evidence; they are not twelve independent empirical studies. It does not establish regulatory compliance, equipment compatibility or process safety. The local engineering, operational and security teams must determine those conditions and the authorized testing scope.

If your team cannot show what a vendor can reach or what happens after the session is cut, an OT remote-access assessment can examine selected maintenance paths, map the authority they create and define a safe acceptance exercise. The useful result is a clear decision about which work can proceed remotely, who can stop it, and what evidence is needed before access and operations are considered resolved.