Treat third-party access as a governed exception, not a permanent support channel. Use hardened jump hosts, session recording, MFA, and just-in-time approval so remote work is observable and revocable. That reduces the chance that a supplier account becomes a standing path into critical operations.
Why third-party access to industrial systems should be treated as an exception
Industrial environments are especially sensitive to supplier access because the remote path is often both operationally necessary and highly trusted. The right security model is exception-based: give a vendor only the access needed for a specific task, for a specific time, and through a controlled path that can be inspected and revoked. That keeps support from turning into an always-on back door.
For industrial systems, the control objective is not just to block strangers, it is to prevent legitimate third-party access from becoming indistinguishable from normal operations. OT and ICS Identity and Access Guide is useful here because it frames vendor access, shared accounts and segmentation as part of the same governance problem.
When teams allow suppliers to use standing credentials, shared accounts or ad hoc VPN access, they lose the ability to prove who connected, what they touched, and whether the access still makes sense. A controlled remote-access pattern should force every session through an approved broker, not directly into the control network.
What controls make third-party remote access defensible
The practical control set is straightforward: hardened jump hosts, multifactor authentication, session recording, strong approval workflow and tight time limits. Those controls work together. MFA reduces account theft risk, the jump host narrows the attack surface, and session recording gives you an audit trail when a supplier claims they only “checked one setting.”
Use Privileged Session Management Guide for the session-brokering and recording model, and Remote Access Identity Guide for the identity controls that should wrap the remote path, including MFA and dormant-access cleanup.
Industrial remote access is safer when it is designed so the supplier never needs broad network reach in the first place. The session should be scoped to the asset, the maintenance window and the approval record, with revocation available immediately if the work stops or the behaviour changes.
For teams that manage suppliers, contractors and integrators across multiple sites, Third-Party, B2B and Contractor Access Guide supports the broader governance model for sponsorship, time limits and reviews.
What to verify before and after access is granted
Before approving third-party remote access, verify the supplier’s account ownership, the business justification, the maintenance window and the exact target systems. After the session, verify that the access was actually used for the intended task, that the recording exists, and that the account cannot be reused indefinitely. If the vendor cannot support those checks, the access model is too loose for industrial operations.
Remote access into OT environments also needs segmentation and a clear boundary between corporate IT and control systems. NIST SP 800-82 Rev 3, OT Security Guide is the clearest external reference for that separation, while CISA Industrial Control Systems is the practical entry point for current ICS guidance and advisories.
Security teams should also verify the exception process itself. A ticket or email approval is not enough if the approved user can later reconnect without a new decision. The control is only meaningful when time-bound approval, session visibility and revocation are all working at once.
Risk and Threat Considerations
Third-party remote access becomes dangerous when a supplier credential, token or support account turns into a standing path into production systems. In industrial environments, that can create persistence, lateral movement and unsafe operational change even when the original purpose was routine support.
Failure mechanism: Attackers commonly abuse valid third-party access because it blends into normal support activity, bypasses perimeter assumptions and often reaches privileged or operationally sensitive systems. If MFA is weak, sessions are unrecorded, or access is not time-bound, a compromised supplier account can be reused repeatedly.
Impact: The result can be unauthorized changes, interruption of industrial processes, loss of visibility into who connected, and a longer dwell time before defenders notice that support access was abused rather than legitimately used.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Supplier remote access depends on strong user authentication and verified identity. |
| AU-2 — Event Logging | Session recording and auditability are core to governed remote access. | |
| Recommendation — Require strong authentication for every third-party remote session. Log and retain remote-access events and sessions for review. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The question is fundamentally about limiting and revoking third-party access paths. |
| Recommendation — Limit third-party access paths to the minimum approved scope and duration. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Third-party industrial access should be verified, least-privilege and continuously constrained. |
| Recommendation — Enforce verified, least-privilege access for every supplier session. | ||
Practitioner Guidance
What to prioritise: Treat the remote-access path as a privileged control plane, not a convenience channel. The first question is whether the supplier truly needs interactive access, or whether a narrower maintenance workflow, read-only visibility, or on-site support is safer.
Decision rule: If the access cannot be tied to a named individual, a defined task and a bounded time window, do not approve it as routine access. If you cannot record the session and revoke it immediately, the exception is too broad for industrial systems.
What to verify: Confirm that the jump host is the only entry point, that MFA is enforced on every session, and that recordings are retained long enough to support incident review and change validation. Also verify that access is removed after the work is complete, not just after an arbitrary calendar date.
Practitioner takeaway: The goal is not to make third-party access impossible, but to make every supplier session temporary, attributable and reviewable enough that compromise or misuse cannot silently become part of normal operations.
Related resources from NHI Mgmt Group
- How should security teams handle third-party access when a systems integrator is breached?
- How should security teams handle standing access for third-party vendors?
- How should security teams handle third-party access that looks legitimate after a supplier breach?
- How should security teams handle third-party NHI access offboarding?