What is the best way to control third-party remote access to OT devices?

Why third-party OT remote access needs brokered control

Third-party access to OT should be treated as an exception path, not a standing convenience. The core problem is not just who can connect, but whether every connection is authorised, time-limited and observable. Brokered access creates a control point where approval, authentication, account assignment and session oversight can be enforced before a vendor reaches a device.

A broker also reduces the chance that a vendor is holding reusable, high-value credentials that linger after the work is done. For OT environments, that matters because remote access paths often bypass the normal physical safeguards around controllers, engineering workstations and maintenance interfaces.

What a controlled third-party access design should enforce

The control objective is to let the right vendor do the right task without granting a durable pathway into the environment. That usually means a PAM or remote access gateway, just-in-time approval, MFA, separate vendor accounts and session recording. Where possible, the broker should inject credentials or mediate authentication so the vendor never sees shared static secrets.

The design should also distinguish between access to the gateway and access to the OT asset itself. A good setup narrows scope by vendor, site, device class and time window, then removes access automatically when the approved task ends. If the architecture allows direct device reachability from the internet or from a flat corporate network, the control has already failed at the trust-boundary level.

What to verify before you trust the control

Verification should focus on the actual remote-work path, not the policy text. Check whether every vendor session is tied to a named person, an approved ticket or change record, and a unique account with the minimum device scope needed for that task. Confirm that the broker records who connected, when they connected, what target they reached and whether the session can be reviewed later.

It is also worth testing what happens when approval expires, MFA fails, a vendor leaves the approved task early, or the session drops and reconnects. Those are the moments when weak implementations fall back to standing access, cached credentials or unmonitored reconnects. The right control should fail closed, not silently degrade into a permanent access path.

Risk and Threat Considerations

Third-party OT access is attractive to attackers because it concentrates trust in a path that is often operationally necessary but lightly supervised. If vendor credentials are shared, long-lived or reused across sites, compromise of one account can become a repeatable route into sensitive OT systems. The same weakness can also create audit gaps, making it harder to tell normal maintenance from malicious use.

Failure mechanism: Standing credentials, weak approval flow or unrecorded remote sessions let an external party retain access after the legitimate work window ends, or let an intruder impersonate that party.

Impact: The result can be unauthorised manipulation of OT devices, loss of visibility into who changed what, and a larger blast radius if the remote path is used for lateral movement or persistence.

Practitioner Guidance

What to prioritise: Put the broker, approval workflow and session recording in place before expanding vendor reach. In OT, it is better to support fewer remote use cases well than to allow broad access with weak oversight.

What to verify: Ensure each vendor has a distinct account, a narrow device scope and a hard expiry on approval. If the workflow still depends on a shared password or a manually copied secret, the control is not mature enough for sensitive OT maintenance.

Practitioner takeaway: The best control is the one that makes remote access temporary, attributable and easy to revoke while preserving the vendor's ability to complete the task.

Related resources from NHI Mgmt Group

• Guide: Remote Access Identity Guide
• Third-Party Remote Access
• Why do remote access and third-party support increase OT risk?
• How should healthcare teams control third-party remote access to protected health information without creating compliance gaps?
• What is the difference between access governance and access control in third-party remote access?