Organisations should prioritise just-in-time access whenever elevation is tied to a specific task or maintenance window. Standing privilege should be the exception, not the default, because dormant access remains available long after operational need ends. The key decision is whether the access can expire automatically without slowing safe work.
Why JIT should be the default for OT privileged work
In OT, the right default is time-bound elevation for a specific task, not persistent admin presence. JIT aligns access with a maintenance window, change ticket, or break-fix event, so privilege exists only when the operator actually needs it. That reduces the amount of time a compromised account, stolen session, or misused role can affect controllers, historians, engineering workstations, or safety-adjacent systems.
Standing privilege should be reserved for narrow cases where the task truly cannot be bounded safely, such as certain emergency response workflows. Even then, the decision should be explicit, approved, and reviewed, because the risk is not just excess permission, but excess permission that remains usable long after the original operational need has passed.
Where OT teams already run privileged access through a formal program, JIT is the control pattern that best matches the principle of least privilege. NHIMG’s Privileged Access Management Guide and Just-in-Time Access and Zero Standing Privilege Guide both reinforce the same operational point: privilege should be activated for the shortest safe interval, then removed automatically.
What makes OT different from ordinary IT privilege decisions
OT access decisions have to respect process uptime, change control, vendor support constraints, and the fact that a bad privilege decision can affect physical operations, not just data. That means JIT is not simply an efficiency improvement. It is a way to reduce exposure while keeping a clear operational path for maintenance, diagnostics, and controlled intervention.
In practice, the most defensible design is task-specific elevation tied to a named identity, a bounded session, and a tightly defined expiration condition. If a plant engineer or vendor needs elevated access only to apply a firmware update, reconfigure a PLC, or validate telemetry, the access model should reflect that exact task rather than giving an always-on role “just in case.”
OT environments also need strong change traceability, because a privilege grant without a corresponding maintenance context becomes difficult to justify during incident review or safety analysis. The access model should make it easy to answer who had access, for what purpose, for how long, and whether the elevation matched approved work.
How to decide when standing access is still justified
The best decision rule is simple: if the work can be scheduled, approved, and completed within a predictable window, it should usually be JIT. If an account truly needs persistent elevation, the organisation should be able to explain why the task cannot be safely time-boxed, what additional compensating controls exist, and how the standing access will be reviewed.
That review should be especially strict for remote vendor access, shared engineering accounts, and broad admin roles that can reach multiple plants or environments. NHIMG’s PAM Buyer’s Guide and Cloud PAM and CIEM Guide are useful here because they frame the same core tradeoff: keep permanent privilege only where the business case is strong enough to justify the residual exposure.
For OT specifically, the exception list should be small and documented. If standing privilege is being defended as “operational necessity,” practitioners should challenge whether the real issue is automation maturity, inadequate maintenance scheduling, or a missing break-glass pattern rather than a genuine need for persistent access.
Risk and Threat Considerations
standing privileged access creates a large attack window in OT. If an attacker compromises a dormant admin account, steals a shared credential, or abuses a vendor path, they do not need to wait for a maintenance event, the access is already present. That can turn a routine administrative pathway into an immediate route to process disruption, safety impact, or wider lateral movement.
Failure mechanism: Persistent elevation survives beyond the work that justified it, so compromise, misuse, or role abuse can occur at any time and may not be constrained by change windows or operator intent.
Impact: The result can be unauthorized configuration changes, loss of visibility, uncontrolled remote actions, or escalation from a single compromised account into plant-wide operational disruption.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | JIT access depends on issuing and expiring privileged credentials safely. |
| AC-6 — Least Privilege | The question is about reducing unnecessary standing privilege in OT. | |
| IA-9 — Service Identification and Authentication | OT often includes service, tool, or remote support access that must be bounded. | |
| Recommendation — Expire privileged authenticators automatically when the task window ends. Restrict OT accounts to the minimum privilege needed for the approved task. Authenticate non-human OT access paths individually and time-bound them. | ||
| CIS Controls v8 | CIS-5 — Account Management | JIT and standing access are account lifecycle and privilege management decisions. |
| Recommendation — Eliminate persistent admin accounts where a time-limited elevation workflow will work. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | OT JIT decisions are access-control choices about when privilege exists. |
| Recommendation — Apply access control rules that make elevated OT access temporary by default. | ||
Practitioner Guidance
What to verify: Before approving any standing OT privilege, verify that the task cannot be time-bounded, that the access path is individually attributable, and that revocation will not break a legitimate operational dependency. If those conditions are not clear, treat the request as a JIT candidate rather than an exception.
Decision rule: If the access exists to complete one discrete maintenance or support task, issue it JIT and expire it automatically. If the business argues for permanent access, require a named owner, a documented rationale, and periodic recertification as part of the exception process.
What practitioners underestimate: OT teams often focus on uptime and miss the fact that permanent privilege also increases recovery burden. The longer privileged access persists, the more likely it is that compromised credentials, vendor misuse, or an old support pathway will remain available when the organisation least expects it.
Practitioner takeaway: In OT, JIT is the safer default because it ties authority to actual work; standing privilege should be justified as a controlled exception, not accepted as normal operations.
Related resources from NHI Mgmt Group
- When should organisations prioritise privileged access management over network controls in supply chains?
- Should organisations prioritise JIT access over vault expansion?
- When should organisations prioritise just-in-time access for AI agents over standing credentials?
- When should organisations prioritise zero standing privilege over broader access convenience in secrets management?