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

Implementing just-in-time access without breaking OT operations

Just-in-time remote access in operational technology environments is useful because it reduces standing privilege, but OT has a different tolerance for delay, interruption, and ambiguity than IT. The implementation has to preserve maintenance windows, vendor support, and emergency override paths while still making access temporary, attributable, and reviewable. The practical challenge is not whether access expires, but whether the process still works when a plant needs action now.

For that reason, teams should design the control around real operating conditions: named identities, pre-approved roles, narrow asset scope, short session duration, and clear break-glass handling for urgent events. The access path should be predictable for operators and auditable for security, with logging attached to the session rather than to a separate manual after-the-fact record. For a useful control baseline, NIST’s Security and Privacy Controls remains relevant because it separates access control, auditing, and contingency planning into distinct control concerns rather than treating them as one workflow.

In practice, many security teams discover their JIT process is too slow only after an emergency maintenance request has already become a production exception.

How JIT access fits maintenance windows, vendors, and emergency response

In OT, just-in-time access should be treated as an access orchestration pattern, not a single approval step. The core design question is how to grant the minimum usable access quickly enough that engineers and responders do not route around the process. That usually means pre-defining who can request access, which assets are in scope, what protocol or jump path is allowed, and which events can bypass normal timing without bypassing accountability.

A workable model usually combines three layers. First, the user or service account is already known and strongly authenticated. Second, access is activated only for the specific session, device, or maintenance ticket, with a short expiry and explicit scope. Third, the session is observed and recorded so the organisation can reconstruct what changed if the work affects safety, availability, or integrity. The value is not only revocation at the end, but also reduction of ambient access before and during the task. If the environment uses third-party maintenance support or remote engineering tools, the access path should be constrained to a brokered route rather than direct reachability into controllers or HMIs.

• Maintenance access should be pre-modelled by role and asset class, not approved ad hoc from a general admin pool.
• Emergency access should have a documented trigger, but the trigger should still leave a record and a post-event review trail.
• Session duration should reflect the actual task, because overly generous windows quietly recreate standing privilege.
• Protocol isolation matters because JIT is weaker when the account is temporary but the path still reaches too much of the control network.

For OT-specific access inventory and machine-identity discipline, the OWASP Non-Human Identity Top 10 is also useful where remote access depends on service accounts, vendor credentials, or other non-human trust relationships.

Where this guidance breaks down is when the organisation has not separated routine maintenance from true emergency response, because then every urgent request gets treated as a special case and the control becomes operationally brittle.

Where JIT access becomes fragile in OT

Tighter access control often increases coordination overhead, requiring organisations to balance reduced standing privilege against the need for immediate recovery and safe maintenance. The main edge case is not the control itself, but the exception model around it. If emergency access requires a long approval chain, responders may delay action or seek workarounds. If the emergency path is too broad, the organisation creates a permanent back door disguised as contingency planning.

Another common variation is vendor support. Some environments still depend on third-party technicians who expect broad after-hours access. In those cases, the control needs a more specific boundary: limited asset scope, session recording, and explicit expiry tied to the support task. Guidance-vs-consensus is worth noting here: there is broad agreement that remote access should be temporary and attributable, but there is less consensus on how much automation should be used in emergency approval. The safer choice depends on whether the organisation can verify the asset, the requester, and the path quickly enough without human delay becoming the greater risk.

Teams also underestimate shared operational accounts. Even if access is time-bound, a shared credential weakens attribution and makes post-incident review harder. The access model is strongest when identity is individual, scope is narrow, and the emergency path is reserved for rare use rather than routine convenience.

Practitioner Guidance

What to prioritise: Design the emergency path first, then fit routine maintenance into the same governance model. If a control works only during planned windows, it is not ready for OT.

What to verify: Verify that the request, approval, session start, session end, and revocation are all traceable to one named identity and one bounded asset set. If any of those steps are manual and unlogged, the process is only partially time-bound.

Decision rule: If a task cannot be completed within the approved access window, treat that as a scope or workflow problem rather than extending the window by default. Repeated extensions are a sign that standing privilege is reappearing through the back door.

Common mistake: Treating JIT as an approval portal instead of a session control. OT teams get better outcomes when they focus on what can be activated, for how long, and through which path, rather than on the approval event alone.

Practitioner takeaway: The best OT JIT design is the one operators barely notice during real work, but security can still reconstruct and revoke with confidence after the work is done.

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?