What happens when third-party vendors get unrestricted access to OT systems?

Unrestricted vendor access often creates the shortest path into industrial systems. Vendors may need temporary connectivity for maintenance, but without strict session control, time limits, and monitoring, their accounts can become persistent footholds. That opens the door to credential abuse, malicious payloads, and lateral movement between IT and OT networks, especially when remote portals and maintenance accounts are poorly governed.

Why This Matters for Security Teams

Third-party vendor access is not just a remote support convenience. In OT environments, it can become a direct control-plane problem when access is broader than the task, longer than needed, or invisible to operators. That creates a pathway from a contractor portal into engineering workstations, historians, jump hosts, and sometimes directly into plant-adjacent systems. The risk is magnified because OT environments tolerate less change, fewer patches, and weaker segmentation than modern IT networks.

NHI Management Group’s research shows that 92% of organisations expose NHIs to third parties, which is a sharp reminder that vendor access is often extended before it is properly governed. That matters because unrestricted access turns a support relationship into a standing identity risk, especially when accounts are shared, passwords are reused, or remote tooling is left enabled after maintenance windows close. Current guidance suggests viewing vendor access as a privileged non-human identity problem, not a procurement issue.

Practitioners should also recognise that OT incident response is slower by design. Once a vendor account is abused, the blast radius can include safety, availability, and production continuity, not only data loss. In practice, many security teams discover the exposure only after a plant outage, a vendor dispute, or an audit finding, rather than through intentional access review.

How It Works in Practice

Unrestricted vendor access becomes dangerous when identity, session control, and network reach are treated as permanent rather than task-bound. A safer model starts with workload and session identity: the vendor must authenticate, the request must be tied to a specific ticket or maintenance reason, and access must be issued only for the duration of the task. For autonomous or tool-driven support workflows, static role-based access is usually too blunt. Real-time policy evaluation is better because the system can decide at request time whether the vendor should reach a PLC, an HMI, a historian, or only a bastion host.

In practice, strong vendor governance usually includes:

• Short-lived credentials with automatic expiry after the maintenance window.
• Session recording and command logging for remote admin activity.
• Segmentation so vendors can reach only the required asset class, not the whole OT enclave.
• Approval tied to change management, asset ownership, and business justification.
• Immediate revocation and offboarding when the task ends or the contract changes.

This is consistent with the control logic in the OWASP Non-Human Identity Top 10, where excessive privilege and weak lifecycle handling are treated as core failure modes. It also aligns with NIST control expectations around least privilege and account management in NIST SP 800-53 Rev 5 Security and Privacy Controls. The operational lesson is simple: a vendor account should behave more like a temporary access token than a permanent login.

The same pattern shows up in NHI security more broadly. NHIMG’s Ultimate Guide to NHIs notes that only 20% of organisations have formal offboarding and revocation processes for API keys, which helps explain why third-party access often lingers after the work is done. These controls tend to break down in plants that still rely on shared vendor laptops, unsegmented remote access portals, or emergency support accounts that bypass normal approval paths.

Common Variations and Edge Cases

Tighter vendor control often increases operational friction, requiring organisations to balance uptime and rapid support against exposure reduction. That tradeoff is real in OT, where production outages can be costly and some vendors only understand legacy tools or proprietary protocols. Best practice is evolving, and there is no universal standard for every plant topology, but the direction is clear: access should be scoped to the task, monitored continuously, and revoked immediately after use.

One common exception is emergency maintenance. Some organisations keep break-glass paths for safety-critical incidents, but those paths should be narrowly governed, heavily logged, and separately reviewed after activation. Another edge case is managed service providers that support multiple sites. Shared tooling can make it tempting to reuse credentials or widen access for convenience, but that increases lateral movement risk across customers and environments. For OT teams, the hardest problem is often not initial provisioning but revocation when a vendor leaves, a contract ends, or a tool is no longer used.

That is why current guidance treats vendor access as an identity lifecycle issue rather than a one-time firewall rule. If the organisation cannot answer who approved it, what it touched, and when it expires, the access is already too broad.

Related resources from NHI Mgmt Group

• How should teams govern third-party access when vendors connect to core systems?
• Who is accountable when third-party access to OT systems is over-permissioned?
• Who is accountable when temporary third-party access is granted without proper privilege controls?
• What breaks when firewall rules are too permissive or ordered incorrectly in third-party access environments?