What is the difference between just-in-time access and always-on remote access in OT?

Just-in-time access is granted only when a task requires it and is removed when the task ends. Always-on remote access stays available for long periods, which increases exposure and makes misuse harder to contain. In OT, just-in-time access better supports least privilege, reduces the attack surface, and fits a gradual Zero Trust approach.

Why the Difference Matters in OT

In operational technology, the access model is part of the control surface, not just an IT convenience. A connection that is open all the time expands the window for abuse, while task-bound access narrows it to the smallest practical period. That difference affects how well you can contain mistakes, malware, contractor activity, and lateral movement inside tightly coupled environments.

Just-in-time access is strongest when the work is predictable, approval can be automated or pre-approved, and the privilege can be revoked cleanly after the task. It is a better fit for privileged OT maintenance, temporary vendor support, and emergency change windows than standing remote access that remains enabled between jobs.

Always-on remote access is easier to use but harder to defend. It often becomes a standing exception that outlives its original purpose, which makes it more likely to be reused, shared, or forgotten. In OT, that matters because remote entry points can bridge into high-value systems with limited tolerance for error, downtime, or broad administrative exposure.

How JIT Changes the Security Model

JIT access changes the problem from “who can get in at any time” to “who can be elevated for a specific task, under a specific condition, for a specific duration.” That shift supports least privilege and gives operators a chance to require approval, time limits, stronger authentication, and session oversight before access is active. It also aligns with a gradual Zero Trust approach because trust is granted only when needed and can be withdrawn quickly.

In OT, the practical value is not only reduced privilege but reduced persistence. If a remote maintenance account or vendor path is always available, compromise of that path can remain useful for a long time. If access is short-lived, the attacker has less time to abuse it, and defenders have a clearer boundary for monitoring and revocation.

JIT works best when elevation is tied to a named task, a named approver, and an enforced expiry.
Always-on access is usually the wrong default for vendor support, admin actions, and break-fix work.
OT teams should treat session duration and revocation speed as control requirements, not convenience settings.

Where Always-On Remote Access Still Appears

Always-on remote access tends to persist because it solves immediate operational pain, especially when plants need fast support or when remote diagnostics are frequent. The problem is that availability often becomes the justification for permanent exposure. Once that happens, access review turns into an inventory problem, and the organisation may no longer know which accounts, certificates, or tunnels are still actively needed.

That is why OT programmes usually need a transition plan rather than a sudden cutover. The safer pattern is to identify the few access paths that genuinely must stay available, then make every other path time-bound, monitored, and removable. For remote support in particular, privileged session management helps convert broad remote access into controlled, recorded sessions with explicit oversight.

For OT teams comparing options, the question is not whether remote access is needed at all. The real question is whether that access should be pre-authorised and continuously enabled, or activated only when the work exists and then withdrawn before it becomes a standing dependency.

Risk and Threat Considerations

Always-on remote access creates a larger attack window, a larger misuse window, and a larger containment problem. In OT, that can turn a single exposed account or remote path into a durable foothold that is difficult to detect until a change, outage, or safety issue reveals it.

Failure mechanism: standing access remains usable after the original task, so compromise, credential sharing, or operator error can persist unnoticed and give an attacker repeated entry.

Impact: an adversary can abuse the same path for privilege escalation, remote manipulation, or lateral movement, while defenders lose the clean expiry point that makes investigation and containment easier.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST Zero Trust (SP 800-207)	GV.RM-01 — Risk Management Strategy	JIT vs always-on access directly changes OT trust boundaries and exposure windows.
Recommendation — Use a zero-trust approach to make remote access time-bound and explicitly authorized.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	JIT access is the practical enforcement of least privilege for OT remote administration.
	IA-5 — Authenticator Management	Time-bound access depends on controlling credentials, expiry, rotation and revocation.
Recommendation — Limit remote access to the minimum permissions and shortest duration needed. Set clear expiry and revocation rules for credentials that enable remote OT access.
ISO/IEC 27001:2022	A.5.15 — Access control	The question is fundamentally about controlling who gets access and when in OT.
	A.8.2 — Privileged access rights	OT JIT is a privileged-access design choice, not a generic connectivity setting.
Recommendation — Define and enforce access rules that make remote privilege temporary and reviewable. Grant privileged OT access only for approved tasks and remove it immediately afterward.

Practitioner Guidance

What to prioritise: For OT remote administration, prioritise task-bound elevation and session control before adding more remote convenience. If the access path cannot be expired automatically, treated as an exception, or monitored as a discrete session, it is too permissive for routine privileged use.

What to verify: Confirm that each remote access path has an owner, an expiry condition, and a review process that catches dormant standing access. The control is working only when temporary access actually disappears after the task and does not silently reappear as a permanent exemption.

Practitioner takeaway: In OT, the best access model is the one that reduces both exposure time and recovery time, because the main advantage of JIT is not just lower privilege, but a much smaller window for misuse.