Who is accountable when third-party access to OT systems is over-permissioned?

Accountability sits with the organisation that owns the industrial environment and the access lifecycle, even when a vendor performs the work. Access reviews, offboarding, and policy enforcement must be documented and owned internally, because the operational consequences of over-permissioned access remain inside the plant.

Why This Matters for Security Teams

Third-party access to OT systems becomes a governance problem the moment a vendor account can reach controllers, historians, engineering workstations, or remote maintenance tools with more privilege than the task requires. The key risk is not just unauthorized access, but inability to prove who approved it, who reviewed it, and who removed it when work ended. NHIMG’s Ultimate Guide to NHIs notes that 92% of organisations expose NHIs to third parties, which is a strong signal that over-permissioning is not an edge case.

This matters because OT environments are built for continuity, not fast remediation. A vendor account that remains active after a maintenance window can still pivot into safety-relevant or availability-relevant assets. Security teams often assume the vendor owns the misuse risk, but the plant owner owns the access lifecycle and the operational blast radius. The OWASP Non-Human Identity Top 10 frames excessive privilege and poor lifecycle control as recurring identity weaknesses, and that model maps directly to third-party OT access. In practice, many security teams discover the accountability gap only after a contractor account is still live long after the work order is closed.

How It Works in Practice

Accountability in OT should follow control of the environment, not control of the vendor. The plant owner should define the access request, approve the scope, enforce time limits, and retain evidence for review. Vendors can execute work, but they should not be the source of truth for entitlement decisions. That is where formal identity governance, PAM, and documented offboarding intersect with OT change control.

A practical model usually includes:

• Named internal owners for every vendor identity, shared account, and remote access path.
• Just-in-time access with narrow task scope, short TTLs, and automatic revocation after the window closes.
• Separate approval for production access, safety-relevant systems, and engineering functions.
• Periodic access reviews that verify both necessity and actual use, not just contract status.
• Logs that link approvals, session activity, and revocation actions to a specific internal control owner.

NIST guidance on access control in NIST SP 800-53 Rev. 5 Security and Privacy Controls supports this kind of accountability chain, even though OT environments often require compensating controls where direct enforcement is limited. NHIMG’s research on 52 NHI Breaches Analysis shows the practical consequence of weak lifecycle control: privileges persist, visibility drops, and incidents become harder to contain. These controls tend to break down when a vendor needs emergency access across segmented OT zones because the exception process is faster than the revocation process.

Common Variations and Edge Cases

Tighter third-party access often increases operational friction, requiring organisations to balance uptime against assurance. In OT, that tradeoff is real, especially during outages, patch windows, and remote troubleshooting where supervisors want broad access available immediately.

Current guidance suggests treating emergency access as a separate, explicitly approved exception rather than a standing entitlement. That means break-glass accounts, if used, should be time-bound, logged, and reviewed after the event. Shared vendor credentials are still common in industrial sites, but best practice is evolving toward individual accountability, session recording, and task-scoped approvals. Where vendors manage their own technicians, the plant owner still needs evidence that internal reviews, offboarding, and recertification actually happened.

The edge case is inherited access from legacy OT integrations. If a vendor account is tied to old remote support tooling or a system that cannot support per-user identity, the organisation should document the compensating control, assign an internal approver, and schedule remediation. When auditors ask who is accountable, the answer must be a named internal control owner, not the vendor contract itself.

Related resources from NHI Mgmt Group

• Who is accountable for third-party access in healthcare zero trust?
• Who is accountable when a third-party vendor tool introduces risk into CUI systems?
• Who is accountable when third-party access is overextended in a hospital?
• Who is accountable when third-party or machine access is over-privileged?