Who is accountable when a privileged OT session is misused?

Why This Matters for Security Teams

When a privileged OT session is misused, the real failure is not the recording platform, but the chain of accountability behind it. The organisation that approves access, binds it to a named identity, and defines the operational workflow must be able to prove who authorised the session, for what purpose, and under what constraints. Without that chain, blame gets pushed between OT engineering, central IAM, and third-party support until no one can act decisively.

This is the same pattern seen in broader NHI risk: privilege sprawl, weak attribution, and poor offboarding. NHI Mgmt Group notes that 97% of NHIs carry excessive privileges in the Ultimate Guide to NHIs — Key Challenges and Risks, which helps explain why session misuse is rarely just a logging problem. The OWASP OWASP Non-Human Identity Top 10 also treats identity lifecycle and privilege control as core risk drivers, not afterthoughts. In practice, many security teams encounter accountability failures only after a misuse event has already disrupted operations.

How It Works in Practice

Accountability should be assigned at design time, not argued after the incident. For privileged OT access, that means the access policy owner, the system owner, and the approving operator all need explicit responsibilities. Session logs, recordings, and command transcripts are evidence, but they do not create accountability on their own. Current guidance suggests the control chain should connect ticketing, identity attribution, approval workflow, and session recording so that every privileged action maps back to a human owner or a formally delegated support function.

In stronger implementations, privileged access is brokered through PAM and then constrained by RBAC, JIT issuance, and Zero Standing Privilege. That gives investigators a clear question: who approved this access, what identity was used, and was the access supposed to exist only for a task window? For environments that include service accounts or machine operators, the same logic applies to NHI governance, because secrets, tokens, and certificates should be tied to workload identity and rotated quickly. OWASP guidance and NHI governance both point to this as the practical way to reduce ambiguity, especially where vendors or integrators perform remote maintenance.

• Bind every OT session to an attributable identity, not a shared account.
• Require a ticket or work order that explains the business purpose.
• Use JIT access so the privilege exists only for the approved task window.
• Record the session, but also define who reviews misuse and who can revoke access.
• Separate technical operators from policy owners so escalation paths are clear.

Where this breaks down most often is in legacy OT plants that still rely on shared vendor accounts, offline approvals, or unintegrated jump servers, because the access chain cannot be reconstructed cleanly after the fact.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance response speed against auditability. That tradeoff is real in OT, especially during outages, safety events, or vendor-led emergency support. Best practice is evolving, but there is no universal standard for whether the plant owner, the enterprise security team, or the vendor should own every step in a joint incident. What is consistent is that accountability must be contractually and technically explicit before access is granted.

One common edge case is third-party support. If a vendor initiates the session but the site approves the access, both sides may share responsibility, yet the owning organisation still needs clear policy authority. Another is autonomous tooling used for maintenance or diagnostics. In those scenarios, agentic behaviour and workload identity matter, because a tool may chain actions faster than a human can supervise. For that reason, current guidance aligns with OWASP Non-Human Identity Top 10, Schneider Electric credentials breach, Ultimate Guide to NHIs — Key Challenges and Risks, and the NIST AI Risk Management Framework on ownership and oversight. In high-risk OT, the accountable party is usually the access owner, but liability can become shared when contracts, approvals, and technical controls do not line up.

Related resources from NHI Mgmt Group

• Who is accountable when a non-human identity is over-privileged?
• Who is accountable when a privileged non-human identity causes a security incident?
• Who is accountable when vendor sessions on OT systems are not fully logged?
• Who is accountable when a vendor session touches a production system outside the approved scope?