Who is accountable when an attacker moves from IT into OT systems?

Accountability usually sits across cyber operations, engineering, and infrastructure leadership because the failure spans both access governance and operational design. Frameworks such as NERC CIP and Zero Trust Architecture make the boundary explicit, but the practical question is whether ownership exists for each privileged path into OT. If nobody owns the route, nobody controls the risk.

Why This Matters for Security Teams

When an attacker pivots from IT into OT, the problem is no longer just a cyber incident. It becomes a safety, availability, and recovery issue that can affect production, plant reliability, and regulatory exposure. The accountability gap usually appears where enterprise identity controls, network segmentation, and engineering ownership overlap but are not formally assigned. NHI Management Group has found that 97% of NHIs carry excessive privileges, and that over-privileged access is exactly what turns a single foothold into cross-environment reach. See the Ultimate Guide to NHIs — Key Challenges and Risks.

Security teams often assume OT ownership sits with operations alone, while engineers assume cyber owns access governance. That split leaves privileged paths, service accounts, vendor access, and remote administration routes unreviewed. Current guidance suggests treating those routes as shared risk domains with named control owners and escalation paths, not informal handoffs. The practical question is whether anyone can approve, revoke, monitor, and test every credentialed path into OT. In practice, many incidents escalate only after a trusted IT-to-OT route is already being used for lateral movement.

How It Works in Practice

Accountability has to follow the control plane, not just the network boundary. In a mature model, cyber operations owns monitoring, detection, and incident coordination; engineering or plant operations owns process safety and asset behavior; and infrastructure or IAM teams own identity governance, privileged access, and secret handling. That division should be documented in the asset register, access model, and incident response plan, with clear approval authority for remote access, vendor sessions, jump hosts, and emergency credentials.

Practitioners should map the attack path from initial IT compromise to OT impact and identify every control handoff. Frameworks such as MITRE ATT&CK Enterprise Matrix help teams think in terms of the tactics attackers use once they have a foothold, while NIST SP 800-53 Rev 5 Security and Privacy Controls gives a control vocabulary for access enforcement, auditing, and incident response. For NHI-heavy environments, the issue is rarely a missing firewall alone. It is usually a service account, API key, shared admin credential, or third-party tunnel that was never assigned a responsible owner, as described in The 52 NHI Breaches Report.

• Name a control owner for each privileged path into OT, including vendor and break-glass routes.
• Require MFA, just-in-time elevation, and session logging for all remote administrative access where technically feasible.
• Separate who can approve access from who can monitor it and who can revoke it during an incident.
• Review service accounts, machine credentials, and API keys as part of OT exposure, not just IT hygiene.
• Test containment steps with engineering so incident actions do not create unsafe process states.

These controls tend to break down in highly integrated plants where legacy protocols, shared jump infrastructure, and long-lived vendor accounts make it difficult to enforce unique identity and session-level accountability.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance safety and uptime against speed of maintenance and vendor support. That tradeoff is especially sharp in brownfield OT environments, where legacy systems may not support modern identity controls or granular authorization. Best practice is evolving, but current guidance suggests compensating controls when direct technical enforcement is impossible.

One common edge case is emergency access. If a plant can only be restored through shared credentials or temporary bypasses, accountability must still be explicit: who authorizes the bypass, who observes the session, who records it, and who confirms revocation afterward. Another edge case is third-party support. Because OT vendors often touch both IT and OT layers, their access should be governed as a privileged identity problem, not just a procurement issue. The concentration of privileged paths is why identity governance matters across both domains, and why NHIs are not an afterthought in OT compromise scenarios. The operational lesson is reinforced by Ultimate Guide to NHIs — Why NHI Security Matters Now and by adversary behavior described in CISA cyber threat advisories.

Where there is no universal standard for this yet, the safest approach is to publish a RACI that assigns ownership for authentication, authorization, logging, response, and recovery separately. In practice, the most dangerous environments are the ones that look “managed” on paper but still rely on informal tribal knowledge for privileged access into OT.

Related resources from NHI Mgmt Group

• Who is accountable when vendor sessions on OT systems are not fully logged?
• Who is accountable when vendor access reaches OT systems through convergence?
• Who is accountable when an attacker reuses valid access to move through systems?
• Who is accountable when AI-driven compromise spreads through OT systems?