Who is accountable when vendor access reaches OT systems through convergence?

Why This Matters for Security Teams

When vendor support crosses into OT, the question is not who pressed the button, but who approved the path, watched the session, and can stop it. Converged IT/OT access often mixes plant engineering, remote support, PAM, and emergency exception processes, which is exactly where accountability becomes blurred. Best practice is to treat the vendor as an operator with delegated access, while the manufacturer retains governance over the access path and its risk.

This is also where NHI risk becomes operational, not theoretical. NHIMG’s Ultimate Guide to NHIs notes that 92% of organisations expose NHIs to third parties, a pattern that maps directly to vendor-mediated plant access. The issue is amplified by weak visibility and over-permissioned credentials, which are recurring themes in the OWASP Non-Human Identity Top 10. In practice, many security teams discover this gap only after a vendor session has already been used to reach an OT asset without clear ownership.

How It Works in Practice

Accountability should be split between execution and governance. The vendor may execute the maintenance task, but the manufacturer must own the policy that allows, limits, records, and terminates that access. That means defining which roles can approve OT entry, what conditions justify it, how long access stays open, and who is responsible for closure and exception review. The control model should sit inside PAM and be bound to RBAC or, where maturity allows, time-bound JIT access with explicit expiry.

For converged environments, the most reliable pattern is a delegated workflow with strong identity proof and narrow scope. Use workload identity for the support path, enforce session recording, and require approvals that are traceable to named internal owners. This aligns with the governance emphasis in the Ultimate Guide to NHIs — Key Challenges and Risks and the operational risk patterns in 52 NHI Breaches Analysis. Practitioners should also require:

• explicit asset ownership for each OT access path
• JIT approval with time limits and automatic revocation
• session monitoring, keystroke or command logging where appropriate, and closure confirmation
• exception handling that routes unusual access back to security or operations leadership
• post-session review to confirm no standing access remains

Current guidance suggests that OT access should be treated as high-risk delegated identity, not as a vendor courtesy, because the plant owner remains accountable for compensating controls and auditability. These controls tend to break down in legacy OT networks with shared accounts and unmanaged jump hosts because identity attribution and session termination are technically weak.

Common Variations and Edge Cases

Tighter control over vendor access often increases downtime and coordination overhead, so organisations have to balance resilience against operational speed. That tradeoff is real in 24/7 plants, especially when safety, production continuity, and maintenance windows all compete for the same access path.

There is no universal standard for every OT topology, but the accountability principle stays the same even when implementation varies. In a fully air-gapped environment, access may be brokered through removable media or on-site engineering workstations; in a converged environment, it may flow through remote desktop, privileged session management, or third-party support portals. The control owner still needs to define who can grant exceptions, who monitors the session, and who verifies closure. The OWASP Non-Human Identity Top 10 is useful here because it frames delegated access, secret handling, and excessive privilege as identity problems, not just network problems.

For high-assurance environments, a dual-control model is often the safest option: operations authorises the work, security validates the path, and the vendor only receives the minimum access needed for the task. Where regulators or sector standards apply, organisations should align this model with their own evidence requirements, because the audit trail is usually what proves accountability after the fact.

Related resources from NHI Mgmt Group

• Who is accountable when OT remote access cannot be traced after the fact?
• Who is accountable when vendor sessions on OT systems are not fully logged?
• Who is accountable when a vendor or support partner accesses personal data improperly?
• Who is accountable when PHI is exposed through ChatGPT Enterprise use?