Who is accountable when vendor sessions on OT systems are not fully logged?

Why This Matters for Security Teams

When vendor sessions on OT systems are not fully logged, the technical gap quickly becomes an accountability gap. The operating organisation still owns the access decision, the approval path, and the evidence needed to reconstruct events. Under NIST Cybersecurity Framework 2.0, this sits squarely in governance, access control, and auditability. In NHI terms, vendor access is just another privileged non-human or third-party identity problem, and the same discipline applies to secrets, session attribution, and offboarding.

This matters because OT environments often combine legacy protocols, shared jump hosts, and vendor-managed tooling, which makes session attribution harder than in standard IT. NHI Management Group’s Ultimate Guide to NHIs — The NHI Market notes that 92% of organisations expose NHIs to third parties, which is exactly where logging and oversight weak points tend to appear. If the session record cannot show who initiated access, what command path was used, and which authority approved it, the organisation may be unable to prove due diligence after an incident. In practice, many security teams discover the missing evidence only after a fault investigation or safety event has already forced a retrospective review.

How It Works in Practice

Good practice is to treat vendor access to OT like a controlled, time-bound privilege grant rather than a helpdesk convenience. That means using PAM where possible, enforcing JIT access, and binding every session to a named vendor operator, a ticket, a window, and an approved scope. The operator should see a live connection record, but the security team needs tamper-resistant evidence that links identity, time, asset, and action. The session trail should be reconstructable even if the vendor is using remote tooling, a bastion host, or a protocol gateway.

At minimum, the record should show:

• who requested the access and who approved it;
• which vendor account or certificate was used;
• when the session started and ended;
• which OT asset was reached;
• what commands, file transfers, or configuration changes occurred;
• how the session was terminated or revoked.

This is where attribution often fails. If a vendor connects through shared credentials, records only network flow data, or logs at the jump box but not the downstream OT session, then the evidence chain breaks. The result is a control gap, not just a monitoring gap. The same logic appears in the Schneider Electric credentials breach, where weak identity hygiene around access paths made trust and tracing much harder than it should have been. Current guidance from NIST Cybersecurity Framework 2.0 is clear on asset protection and auditability, but there is no universal standard for every OT protocol stack yet. These controls tend to break down when vendors use unmanaged maintenance channels because the organisation cannot enforce consistent identity binding end to end.

Common Variations and Edge Cases

Tighter logging often increases operational friction, so organisations must balance forensic certainty against maintenance speed and plant availability. That tradeoff becomes sharper in OT, where downtime windows are narrow and some equipment cannot tolerate full inspection proxies.

One common edge case is a legacy environment that cannot support modern session recording. In those cases, best practice is evolving rather than settled: compensating controls may include dedicated vendor jump hosts, strict RBAC, MFA for the entry point, immutable access logs, and short-lived credentials that expire after the maintenance window. Another edge case is shared vendor support accounts. Those should be treated as a high-risk exception, because shared credentials destroy attribution even if the network path is logged. NHI Management Group’s research shows that only 5.7% of organisations have full visibility into their service accounts, which is a useful warning sign for OT teams that rely on named accountability but do not have the telemetry to prove it.

For governance, the accountable party is usually the asset owner or OT operator, even when the vendor performs the work. Contractual clauses can assign duties, but they do not remove operational accountability. That is why the control model should be documented in advance, aligned to NIST Cybersecurity Framework 2.0, and supported by vendor-facing access terms. Where logs are incomplete, the practical response is not to assume the vendor is at fault, but to tighten session capture, revise approvals, and restore an evidence trail that survives audits and incident response.

Related resources from NHI Mgmt Group

• Who is accountable when a vendor breach exposes downstream client data?
• Who is accountable when a vendor identity failure exposes institutional data?
• Who is accountable when a failed rotation takes down production systems?
• Who is accountable when a vendor OAuth grant is abused?