Who is accountable when OT living off the land abuse reaches production systems?

Why This Matters for Security Teams

When OT living off the land abuse reaches production systems, the issue is rarely just technical misuse of native tools. It is usually a governance failure across remote access, privileged access, segmentation, and monitoring. Security teams need clear accountability because the attacker is often operating with legitimate tools, valid sessions, or trusted pathways that were approved for business reasons. Guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls helps anchor that shared responsibility in control ownership rather than incident blame.

The practical risk is that OT environments often have multiple groups making partial decisions: engineering owns uptime, IAM owns authentication, PAM owns elevation, and network security owns segmentation. If those decisions are not tied to a single accountable control model, native tooling such as PowerShell, PsExec, WMI, SSH, or vendor administration utilities can be abused without immediately triggering a clearly owned response. In production OT, that gap can affect safety, availability, and recovery time at once.

In practice, many security teams encounter accountability only after a remote maintenance path or privileged credential has already been used outside its intended scope.

How It Works in Practice

Accountability should be assigned at the control level, not left as a generic shared duty. In OT, that means defining who approves access, who enforces it, who monitors it, and who can suspend it when behaviour changes. A useful starting point is to map remote access and privileged operations to the controls that govern authentication, session isolation, logging, and network boundaries. NIST control families for access control, audit, and system communications are useful here, and the same logic should extend to vendor access, jump hosts, and administrative workstations.

In a mature operating model, each layer has a named owner:

• OT operations owns the business justification for production access and the maintenance window.
• IAM owns identity proofing, authentication strength, and account lifecycle.
• PAM owns elevation, session brokering, and credential checkout or rotation.
• Network security owns segmentation, conduit enforcement, and monitoring of east-west movement.
• SOC or detection engineering owns alerting, triage, and escalation when native tools are used unusually.

That division matters because living off the land abuse often looks like normal administration until context is added. A single remote login, an unusual host jump, or a script executed from a trusted account may be legitimate in one plant and dangerous in another. Current guidance suggests that control owners should predefine what normal looks like, including source systems, time windows, commands, and escalation paths, so that response is not improvised during an outage. For OT environments with hybrid IT and industrial connectivity, it is also wise to align this accountability model with CISA Zero Trust Maturity Model principles for continuous verification.

These controls tend to break down when legacy controllers, shared service accounts, or flat vendor access paths prevent the organisation from tying actions back to a specific identity and approved purpose.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance production reliability against investigative clarity. That tradeoff is especially visible in OT, where some plants still rely on shared engineering accounts, undocumented vendor routines, or emergency override procedures. Best practice is evolving, but there is no universal standard for how much exception handling should be tolerated before accountability is considered ineffective.

One common edge case is the emergency maintenance account. It may be justified for uptime, but if it is not time-bound, independently approved, and monitored, it becomes a standing path that can be abused like any other privileged route. Another edge case is remote vendor support. The vendor may execute the action, but the plant owner still owns the risk of allowing that path into production. A third case is partial segmentation, where the network team believes a conduit exists but OT engineering can still reach the same asset through an alternate trust path.

The cleanest accountability model is one that can answer four questions quickly: who approved the access, who could have stopped it, who saw the misuse, and who is responsible for improving the control after the event. That is the standard that matters when production systems are involved, because ambiguity itself becomes part of the attack surface. For OT programs that handle regulated or safety-critical environments, alignment with CISA Industrial Control Systems cybersecurity guidance is often the most practical way to sharpen ownership without disrupting operations.

Related resources from NHI Mgmt Group

• Who is accountable when vendor access reaches OT systems through convergence?
• How can organizations manage unauthorized agents in their systems?
• Who is accountable when a failed rotation takes down production systems?
• Who is accountable when vendor sessions on OT systems are not fully logged?