How should security teams implement just-in-time remote access in operational technology environments without disrupting maintenance or emergency response?

Why This Matters for Security Teams

Just-in-time remote access in OT is not a convenience feature. It is a control that decides whether maintenance, incident response, and safety operations can proceed without leaving standing access behind. In OT, the wrong design can delay restoration work, break vendor support flows, or force teams to keep permanent accounts alive “just in case.” That is exactly the risk profile highlighted by the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10.

The practical issue is not whether access should be temporary. The issue is how to make it temporary without turning emergency response into a ticketing bottleneck. OT teams often need access that is identity-based, narrowly scoped, and approved fast enough to support plant availability. NHI Management Group research also shows why this matters: in the State of Non-Human Identity Security, lack of credential rotation and poor logging were among the leading attack drivers, which maps directly to remote access design. In practice, many security teams discover their JIT process is too slow only after a maintenance window has already been missed.

How It Works in Practice

Effective OT JIT remote access starts by separating identity verification from network reachability. A technician, engineer, or vendor should authenticate with strong assurance, then receive a short-lived session that is tied to a specific asset, protocol, and time window. That session should be issued only when the task is approved and should expire automatically when the window closes or the task completes. For operational resilience, current guidance suggests using policy-as-code and real-time authorization instead of static role grants, especially for multi-step work that cannot be predeclared in rigid RBAC terms.

In practice, teams combine four controls. First, use a strong human identity plus device trust for the requester. Second, broker the session through a control plane that can proxy or isolate OT protocols instead of exposing the asset directly. Third, log the full session, including who requested it, who approved it, what asset was accessed, and what commands or actions were allowed. Fourth, enforce time-limited elevation with immediate revocation at completion. The Guide to NHI Rotation Challenges is useful here because OT access often depends on secrets and service accounts that must also be rotated without breaking dependencies.

NIST guidance supports this approach through least privilege, auditability, and controlled access pathways in NIST SP 800-53 Rev. 5 Security and Privacy Controls. For remote vendors, align approval workflows to named devices, named users, and named tasks rather than broad “maintenance” entitlements. These controls tend to break down when emergency access is routed through shared break-glass accounts because attribution, revocation, and session containment become unreliable.

Common Variations and Edge Cases

Tighter access controls often increase coordination overhead, so organisations must balance speed against safety, uptime, and auditability. That tradeoff is real in OT, where a delayed approval can matter as much as an overly permissive session.

One common edge case is the break-glass scenario. Best practice is evolving, but the current consensus is that emergency access should be pre-staged, heavily monitored, and automatically time-boxed rather than left as a standing exception. Another variation is vendor support for legacy equipment. If the device cannot support modern identity controls, teams often need an isolation layer, jump host, or protocol gateway so the risky device is never directly reachable from general networks. The Schneider Electric credentials breach and the Microsoft SAS Key Breach both illustrate how exposed credentials and overbroad access can turn routine operations into incident paths.

Another useful pattern is pre-approval for defined maintenance classes, with runtime validation for the exact asset and time slot. That reduces friction without restoring standing privilege. For organisations with mature programs, the target state is not “no human can ever touch OT,” but “every remote session is justifiable, attributable, short-lived, and revocable.”

Related resources from NHI Mgmt Group

• How should security teams implement just-in-time access for Elasticsearch and Elastic Cloud environments without slowing down engineers?
• How should security teams implement just-in-time privileged access for production systems without slowing incident response?
• How should security teams implement just-in-time access for incident response without slowing down on-call engineers?
• How should security teams implement just-in-time access without leaving standing privilege behind?