Keep control of OT when a vendor connects

Organizations that rely on outside specialists to maintain physical systems should retain the authority and practical ability to control their access. A support contract should make clear who can authorize a connection, which work it permits, how the organization can end it safely, and what happens if the supplier cannot help restore service. Without those arrangements, a routine maintenance relationship can become an operating dependency that management has never explicitly accepted.

NIST released an initial public draft of its revised Guide to Operational Technology Security on September 21, 2026. Operational technology, or OT, includes systems that monitor or control the physical environment, from industrial processes to building automation. The draft expands its treatment of OT sectors and cloud connections, and organizes its guidance around the NIST Cybersecurity Framework 2.0, including its Govern function. Comments are due November 30. This is draft guidance, subject to change, rather than a new compliance deadline. [1]

The executive opportunity is to examine a consequential supplier relationship before an incident forces the question. We recommend beginning with one critical physical service that depends on external support. Review the actual access path and recovery arrangements with the people who operate it. The objective is evidence that the organization can retain control under stress.

A connection carries operating authority

The revised guide treats remote access as a managed process. Its discussion covers external-access accounts and requirements, business justification for requests, assigned security responsibilities, revocation, and auditing. It also calls for maintenance and support agreements to define acceptable vendor access and incident-response expectations. [2] Those details deserve attention from the business owner because they determine who can influence a service the business relies on.

Consider a hypothetical organization whose specialist contractor supports the cooling controls at a critical facility. Remote diagnostics can shorten repair time and avoid waiting for an engineer to travel. A connection that also permits configuration changes, however, gives that contractor a different level of authority. Management needs to understand whether access is limited to the affected equipment, whether the on-site operator approves the work, and whether the organization can see what changed.

This example is illustrative, not a reported incident. Its practical point is that the supplier's importance does not establish the appropriate scope of access. A competent, trusted contractor can still have an account compromised, assign the work to another person, or depend on a service that becomes unavailable. The organization needs arrangements that remain usable in those circumstances.

A supplier inventory alone will not reveal this exposure. The operating team should trace the connection from the named person through the remote-access service to the equipment or management system they can reach. Include subcontractors and supplier-managed connections in that review. NIST's draft specifically discusses auditing and controlling supplier access mechanisms, including the risk of unauthorized communications devices. [2] The resulting record should describe how support actually works.

Make the access decision specific to the work

A workable access review starts with the service owner, the OT engineer, security, and the supplier agreeing on the permitted task. Read-only diagnosis, software maintenance, and changes to a physical process have different consequences. The access granted should reflect those differences wherever the technology allows them to be separated.

A routine maintenance relationship can become an operating dependency that management has never explicitly accepted.

For the cooling example, a diagnostic session might allow inspection of alarms and configuration without changing setpoints. A repair requiring changes would have a separately agreed scope, an on-site owner, and a plan for validating the result. This is a recommended operating approach; it is not a claim that every installed control system supports granular permissions. Where an older system cannot enforce the distinction, management should record the limitation and approve a compensating arrangement with the engineering team.

An access window also needs an owner. Requiring approval for every connection can slow urgent repair if the approver is unavailable overnight. Permanently available access can reduce that delay while leaving a longer opportunity for misuse. The right decision depends on the service's consequences, available staff, and technical controls. An emergency procedure should name who can approve exceptional access, how the event is recorded, and who reviews it afterward. Otherwise, an approval requirement can encourage an undocumented workaround precisely when pressure is highest.

Procurement can make these decisions enforceable by putting the agreed access method, subcontractor obligations, incident contacts, and evidence requirements into the support agreement. Security can verify the connection and account controls. The service owner should accept the remaining operational exposure. Assigning all three responsibilities to the supplier leaves the customer without an independent decision-maker when the supplier's environment is part of the problem.

Plan a safe way to end the connection

Revoking an account is useful only if the team understands what happens next. In OT, an abrupt interruption can affect availability or the physical process. NIST's draft discusses the ability to disconnect remote access while avoiding harm to operations, alongside compensating measures such as time-limited access. [2] That makes safe disconnection an engineering question as well as an identity-management task.

Ask the responsible engineers to distinguish a support session from any connection needed for normal operation. If the same service performs both functions, document that dependency before treating it as an emergency cutoff. The operating procedure should explain who may initiate disconnection, what conditions make it safe, and how the local team confirms the system's state afterward.

The test should use a suitable nonproduction environment or another engineering-approved method. Leaders should not request a live disruption merely to demonstrate control. A tabletop exercise can expose missing authority and contact information; a technical test can expose a dependency that the discussion missed. They provide different evidence, and the record should state which has been completed.

Recovery must work beyond the supplier's help desk

An organization can end suspicious access and still be unable to restore service. Recovery may depend on configuration files, licensed tools, specialist knowledge, or an ordered restart of connected equipment. Having a backup does not demonstrate that these dependencies are available or that the recovery sequence is understood.

The draft's recovery guidance addresses documented dependencies, coordination with control engineers, backup integrity, and the timing and sequence of restoration. It describes offline recovery testing where operational or safety concerns make other testing unsuitable. [2] For executives, the relevant evidence is a recovery exercise with a defined scope and an honest account of what remains untested.

Extend the hypothetical cooling review to a period when the usual supplier cannot respond. The team might discover that a second authorized specialist can diagnose the system, but cannot restore its configuration without a tool held by the primary contractor. That finding would support a specific decision: secure access to the tool, arrange an alternative service, or explicitly accept the dependency with an operating contingency. It would not justify declaring the whole facility resilient because a backup file exists.

Complete independence may be impractical. Some equipment requires proprietary expertise, and maintaining duplicate specialist capability can be expensive. Management can accept that dependency while negotiating usable recovery materials, alternate contacts, and realistic support terms. The value of the review is that the cost and consequence become visible before the next renewal.

Give management a decision it can close

For the selected service, ask for one concise record covering the authorized work, actual access path, safe revocation procedure, and recovery evidence. Attach the relevant support terms and identify the business owner who accepts any unresolved dependency. This is a focused access review, not a request for another enterprise-wide questionnaire.

The findings should lead to specific decisions. A contractor with broader access than its task requires needs a narrower route or a documented exception. A revocation procedure that has only been discussed needs an appropriate test. A recovery plan that depends on an unavailable tool needs a commercial or engineering remedy. Each action should have an owner and a date tied to the service's operational constraints.

Use the first review to determine which other services share the same access mechanism or supplier dependency. That gives the team a defensible order for further work. Management can then fund the changes that preserve operational control, with a clear understanding of the repair delays, support costs, and residual risks each choice entails.