Who is accountable when indirect OT access creates operational risk?

Why This Matters for Security Teams

Indirect OT access is rarely just a remote connectivity problem. It creates a shared accountability surface across network teams, plant operations, identity governance, service providers, and risk owners. When access is brokered through jump servers, VPNs, vendor tools, or privileged service accounts, the real question is not only who can connect, but who owns the business risk if the path is abused, misconfigured, or unavailable.

This matters because OT environments often mix safety, availability, and legacy constraints, which makes clean ownership harder than in typical enterprise IT. The governance challenge is to define who approves the path, who monitors it, who can revoke it, and who is accountable when a control fails. The NIST Cybersecurity Framework 2.0 is useful here because it anchors accountability to governance, risk management, and control ownership rather than to a single technology stack.

Practitioners also need to account for non-human actors, especially vendor credentials, service accounts, and automation that can reach OT assets indirectly. In practice, many security teams encounter accountability gaps only after an outage, unsafe change, or unauthorised access path has already been discovered, rather than through intentional control design.

How It Works in Practice

Accountability for indirect OT access works best when ownership is assigned by access path, not by tool. A VPN, bastion host, remote support platform, or orchestration workflow should each have a named business owner, a technical control owner, and an operational approver. That split matters because indirect access creates chained dependencies, and a failure anywhere in the chain can affect the OT environment.

In practice, organisations should define who owns:

• the access request and approval workflow;
• the privileged identity or service account used for access;
• logging, alerting, and session review;
• recertification and exception handling;
• incident response when the access path is suspected of misuse.

NIST control guidance helps translate that governance into implementation. NIST SP 800-53 Rev 5 Security and Privacy Controls is especially relevant for access enforcement, auditability, and continuous monitoring, while identity-centric governance should also consider whether the path relies on non-human identities, secrets, or delegated credentials. The OWASP Non-Human Identity Top 10 is useful for understanding why service accounts, tokens, and machine credentials need explicit ownership and lifecycle controls, not informal operational handoffs.

Good practice is to document the accountable owner in the same record used for access approvals, risk acceptance, and exception review. That makes it possible to trace who must act when the path changes, when a vendor relationship ends, or when a control gap is found. These controls tend to break down when multiple vendors share a single privileged access route because no single party is clearly responsible for session governance or revocation.

Common Variations and Edge Cases

Tighter accountability often increases operational overhead, requiring organisations to balance faster support access against stronger control ownership. That tradeoff becomes visible in high-availability plants, where urgent maintenance is expected, and in hybrid environments, where corporate IAM teams may not control the entire OT access path.

There is no universal standard for this yet, but current guidance suggests that the accountable party should be the one best positioned to approve risk, enforce controls, and initiate remediation. In some cases that is the OT operator; in others it is the infrastructure owner, the third-party risk function, or the identity team managing the privileged workflow. The important point is that accountability must be explicit, not implied by who configured the tool.

Edge cases often arise when access is indirect but temporary, such as emergency vendor support, shared break-glass access, or automation used for maintenance windows. In those situations, the risk owner should still require a named approver, a defined expiry condition, and a review record. When the path includes automated scripts or machine-to-machine credentials, the identity governance question shifts further toward Non-Human Identity ownership and monitoring. This is where operational accountability and identity accountability must be aligned, not treated as separate conversations.

Related resources from NHI Mgmt Group

• When does JIT access create more risk than it reduces?
• Who is accountable when a vendor compromise creates internal access risk?
• Who is accountable when shadow IT creates access risk?
• Who is accountable when a shadow SaaS app creates access and cost risk?