How do IAM and PAM teams govern third-party access in OT?

Why third-party access in OT should be governed as a privilege problem, not a ticketing problem

OT access is often time-sensitive, vendor-driven and operationally constrained, which makes third-party access easy to over-grant and hard to review after the fact. IAM and PAM need to govern the same path end to end, so vendors are onboarded, approved, monitored and removed under one policy model rather than through separate IT and OT exceptions.

The practical implication is that vendor access should be tied to a named task, a named sponsor and a defined expiry, with authentication strength, network path and session controls all set before the work starts. That is why a unified model matters: it keeps the access decision consistent even when the underlying OT system is old or fragile.

This is also where Third-Party, B2B and Contractor Access Guide becomes useful, because third-party access needs sponsorship, least privilege and time limits rather than informal vendor trust. For OT specifically, the control objective is not just entry, it is bounded entry with a clear owner and a clear exit.

How to combine MFA, encrypted tunnels, least privilege and session recording

MFA reduces the chance that a stolen password alone opens an OT pathway, but it is only one layer. Encrypted tunnels help protect remote administration links across untrusted networks, while least privilege narrows what the vendor can actually do once connected. Session recording adds accountability and creates a reviewable record when a change affects plant availability or safety.

In OT, these controls work best when they are applied together as a single access pattern, not as optional add-ons. A vendor session that is authenticated strongly, limited to a specific jump path and recorded from start to finish is much easier to govern than a broad remote desktop exception with no durable evidence.

For teams designing the operating model, Privileged Access Management Guide is the clearest internal reference for session management, JIT access and zero standing privilege. Privileged Session Management Guide is the better fit when the question is how to broker, record and control the vendor’s active session, including remote access oversight. If the team needs the access to expire by design, Just-in-Time Access and Zero Standing Privilege Guide maps the time-bound model most directly.

What good third-party OT governance looks like in practice

Good governance starts before the vendor touches the OT network. The access request should identify the asset, task, approver, expected duration and support window, then route through PAM so the credential path, session broker and logging are predetermined. The sponsor should remain accountable for whether access is still needed, not just whether it was approved once.

It also means treating vendor accounts as governed assets, not temporary conveniences. If external access is reused across plants, kept alive between jobs or granted to multiple vendors under one shared identity, the team loses attribution and makes both reviews and incident response weaker.

Third-Party, B2B and Contractor Access Guide is the most direct internal pattern for sponsorship, federation and offboarding, while IAM and IGA Basics helps anchor the governance side, especially where approvals, reviews and entitlement ownership need to be explicit. If the vendor is operating through a privileged path, Privileged Session Management Guide supports the expectation that every high-risk remote action is attributable and reviewable.

Risk and Threat Considerations

Third-party OT access becomes risky when a vendor credential, remote support channel or standing privilege outlives the task it was meant for. That creates a durable path into systems that may have weak segmentation, limited monitoring or delayed patching, and it makes stolen vendor access disproportionately valuable to an attacker.

Failure mechanism: Excessive vendor privilege, weak offboarding or reused remote access can let an attacker move from a support channel into OT-adjacent systems, where a single account can expose many assets or support destructive change.

Impact: The result can be loss of accountability, unauthorized configuration change, production disruption or wider lateral movement into business and industrial systems.

Practitioner Guidance

What to prioritise: Put expiry and session control ahead of convenience. If a vendor needs recurring access, convert the pattern into a governed JIT workflow rather than extending a standing account.

What to verify: Confirm that every third-party route has a named sponsor, a defined end time, MFA, a controlled network path and a recording or audit trail that can actually be reviewed after the work.

Common mistake: Treating OT as a special exception where the vendor gets broader access because the environment is sensitive. In practice, sensitivity is the reason to be stricter about privilege, not looser.

Practitioner takeaway: The right model is not “trusted vendor access”, it is controlled task access with strong identity proofing, narrow privilege and a guaranteed shutoff point.

Related resources from NHI Mgmt Group

• How should IAM teams govern third-party SaaS access after a breach?
• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?
• How should security teams govern third-party AI agents that use OAuth access?