Treat vendor access as task-scoped access, not a standing support pathway. Limit it to the specific system, short duration and approved session needed for the job, then monitor activity and remove access when the task ends. This reduces the chance that remote support becomes an uncontrolled route into production.
How third-party access should work in a converged IT/OT plant
In converged environments, the right model is controlled exception, not always-on convenience. Third-party access should be tied to a named business task, a defined target, an approved time window and a monitored session path. That keeps support useful for operations while preserving the separation between enterprise IT access patterns and production OT exposure.
Manufacturers should treat the request as a temporary privilege decision, not a relationship status. The important question is whether the vendor needs access to a specific asset, for a specific reason, under a specific approval, with a defined end point. OT and ICS Identity and Access Guide is useful here because it frames vendor remote access, shared accounts and segmentation as operational control problems, not just helpdesk convenience.
In practice, that means the access path should be segmented from general corporate access, exposed only when required, and removed when the job closes. Where remote support is used, it should be session-based and observable, not a persistent route that can be reused for the next incident. A strong governance model also distinguishes between human vendor users and any vendor-operated technical access that might exist behind the scenes.
What manufacturers need to control before the vendor connects
Before access is granted, the plant should know who is requesting it, which system they need, what change or fault they are handling, and how long the work should take. That control set should include approval from the asset owner or operations function, because production impact is usually operational first and technical second. Third-Party, B2B and Contractor Access Guide is directly relevant because it emphasizes sponsorship, least privilege, time limits and third-party offboarding.
Access should be task-scoped down to the minimum feasible target, such as one line, one controller, one historian or one support portal, rather than a broad network segment. If the vendor needs elevation, that elevation should be just-in-time and narrow, not a standing privilege that survives between jobs. The access request should also capture the method of connection, because a vendor using a trusted remote support tool creates a very different exposure profile from a normal internal user session.
Manufacturers should also decide in advance what evidence is required to trust the access. At minimum, that means an approved ticket, an identifiable sponsor, a bounded duration, a named system, and a way to correlate activity back to the person or support case. IAM and IGA Basics is a useful foundation for that governance because it connects provisioning, entitlement review and least privilege to both people and machines.
Why temporary access beats standing support pathways
Standing third-party access creates unnecessary blast radius. In converged IT/OT environments, the same route that helps a vendor solve a maintenance issue can also become a durable foothold if credentials leak, a session is hijacked, or a support relationship is abused. Remote access should therefore expire automatically and be reapproved for each meaningful task rather than left alive because the vendor “may need it again soon.”
That model matters because production support often happens under time pressure, which is exactly when shortcuts become normalised. If a vendor account can reach multiple assets, can authenticate without a current job, or can be reused across plants, the organisation loses control over who can touch production and when. OT and ICS Identity and Access Guide and Ultimate Guide to NHIs, Key Challenges and Risks both reinforce the same operational reality: uncontrolled access paths, excess privilege and weak visibility are the conditions that turn support into exposure.
The consequence is not just misuse by the vendor. A standing channel can be abused after credential theft, token theft, or simple account sharing inside the supplier’s own environment. Manufacturers should assume that once a path exists, it may outlive the original job unless someone actively closes it.
Risk and Threat Considerations
Third-party access in IT/OT becomes high risk when a support relationship is treated as inherently trusted. The main exposure is that one vendor path can bridge business systems, production systems and remote administration in a way that bypasses normal segmentation and monitoring.
Failure mechanism: A persistent vendor credential, remote support token, or shared support account is reused beyond the approved task, giving an attacker or careless operator a route into production systems.
Impact: The result can be unauthorised changes, production disruption, data theft, or a wider compromise that moves from a supplier foothold into operational assets.
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 CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Third-party access needs provisioning, review and revocation controls. |
| AC-6 — Least Privilege | Task-scoped vendor access depends on limiting permissions to the minimum needed. | |
| IA-2 — Identification and Authentication (Organizational Users) | Vendor sessions must be tied to known users and authenticated before access is allowed. | |
| Recommendation — Restrict vendor accounts to approved tasks and revoke them immediately after use. Grant vendors only the specific privileges required for the job. Require strong authentication for each vendor operator before production access. | ||
| CIS Controls v8 | CIS-5 — Account Management | Third-party support access is an account-management problem that needs tight lifecycle control. |
| Recommendation — Inventory, approve and remove vendor accounts on a defined lifecycle. | ||
| NIST CSF 2.0 | PR.AA-05 — Identities are managed, proofed, bound to credentials, authenticated and authorized for access across the enterprise | Vendor access must be identity-bound and authorised before reaching OT assets. |
| Recommendation — Bind each vendor session to a verified identity and authorised scope. | ||
Practitioner Guidance
What to verify: Verify that every vendor session has a sponsor, a start and end time, a named target asset and an auditable reason for access. If any of those elements is missing, treat the request as incomplete rather than convenient.
Decision rule: If the vendor needs repeated access, redesign the access path so that repeated work still requires explicit reapproval and fresh session creation. Do not convert recurring support into a permanent exception unless the business has accepted the residual risk in writing.
What good looks like: Good governance leaves a clear trail from request to approval to session activity to closure, with no lingering access after the task ends and no shared support pathway that multiple vendors can use interchangeably.
Practitioner takeaway: In converged IT/OT, the safest vendor model is not “trusted partner access”, it is tightly bounded operational access with strong identity, short duration and fast revocation.
Related resources from NHI Mgmt Group
- How should organisations govern third-party access in regulated environments?
- How should security teams govern third-party access in complex B2B environments?
- How should teams govern third-party access in digital healthcare environments?
- How should manufacturers govern third-party privileged access?