How should security teams govern just-in-time access in OT environments?

Security teams should govern just-in-time access as a session lifecycle control, not as a one-time authentication event. The key is to define who can request access, how approval is recorded, when access expires, and how teardown is verified across the exact OT protocols in use. Without that closure, JIT becomes a time-limited credential rather than a governed control.

Why This Matters for Security Teams

In OT, just-in-time access is not simply a faster approval path. It is a controlled exception that must preserve safety, uptime, and traceability across PLCs, historians, engineering workstations, jump hosts, and vendor remote support. That makes session governance the real control objective: access should be requested, approved, time-bounded, observed, and torn down with evidence. Without those steps, teams can lose the very audit trail they need to prove restraint.

This is especially important because OT environments often combine legacy protocols, fragile maintenance windows, and third-party support accounts that were never designed for short-lived access. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is a reminder that temporary access can still be dangerous if the scope is not tightly constrained. Current guidance from the NIST Cybersecurity Framework 2.0 aligns with treating access as a monitored control, not just an authentication event. In practice, many security teams discover that “temporary” access was effectively permanent only after a maintenance window has already closed.

How It Works in Practice

Governing JIT in OT starts with defining the full session lifecycle. Security teams should specify who can request access, what asset or protocol is in scope, which approver is required, how long the session may exist, and what telemetry proves the session ended. That lifecycle should be enforced through policy, not spreadsheet-based process. The most reliable pattern is to pair approval with an identity-bound session that expires automatically and is revoked when the task is complete.

For OT, the practical challenge is that access often spans multiple layers. A vendor may need a ticket to reach a jump host, an RDP or SSH session to reach the engineering workstation, and protocol-level access to Modbus, DNP3, or OPC UA devices. Each layer needs its own control point. The OWASP Non-Human Identity Top 10 is useful here because it frames the risk of over-privileged, long-lived credentials that outlive the approved task. NHI Management Group also highlights lifecycle weaknesses in the Lifecycle Processes for Managing NHIs, which maps directly to OT session teardown and revocation.

• Use per-request approval with clear asset, protocol, and time scope.
• Bind access to a named operator, vendor, or workload identity.
• Issue short-lived credentials or session tokens with automatic expiry.
• Record the approver, duration, commands, and affected systems.
• Verify teardown by confirming the session, token, and downstream authorization all ended.

Where possible, integrate PAM, bastion hosts, and policy-as-code so the access decision is evaluated at request time rather than granted by static role membership. These controls tend to break down when legacy OT devices cannot enforce session expiration or when a shared vendor account is reused across multiple plants because teardown cannot be proven per task.

Common Variations and Edge Cases

Tighter JIT governance often increases operational overhead, requiring organisations to balance response speed against safety and auditability. That tradeoff is real in OT, where emergency work, vendor support, and plant shutdowns do not always fit a clean approval workflow. Current guidance suggests building separate paths for planned maintenance, emergency break-glass access, and routine support, because a single policy rarely works across all three.

One common edge case is protocol access that cannot be meaningfully scoped at the device level. In those environments, best practice is evolving toward compensating controls such as jump-host isolation, command logging, and explicit post-session review. Another issue is shared engineering accounts, which make it difficult to attribute approval, activity, and teardown to a specific person or service. That is why NHI governance matters even in OT: the session may be human-initiated, but the credential or token often behaves like a non-human identity artifact once issued. The Top 10 NHI Issues and the Regulatory and Audit Perspectives sections both reinforce the same point: evidence of revocation matters as much as evidence of approval. In OT environments with offline assets, air gaps, or vendor-maintained embedded systems, teardown verification can remain partial rather than complete, so teams should document that limitation explicitly.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities that have persistent access?
• How should security teams govern non-human identities in cloud environments?
• How should security teams govern API keys used for generative AI access?
• How should security teams govern remote privileged access in OT environments?