Most access in a plant is granted once and then left in place forever. A vendor is given an account for a commissioning job, and that account still works two years later. An engineer keeps standing administrative rights they use a few times a year. Every one of those permanent grants is an attack surface sitting idle, waiting to be misused. Just-in-time access flips the model: privileges are handed out only for the specific window they are needed and taken away automatically afterward. This guide explains what just-in-time access means, how it shrinks the attack surface compared with standing accounts, and why the vendor maintenance visit is its clearest use case.
Just-in-Time Access in one line: Just-in-time access grants a user elevated privileges only for a bounded, time-limited window when they actually need them, then automatically revokes those privileges when the window closes. Instead of a standing account that is always active, access exists on demand - typically after an approval - and expires on its own. The goal is to eliminate permanent privileges so that, most of the time, the powerful access an attacker would want simply does not exist.
Standing access is any privilege that stays granted whether or not it is in use. It is the default almost everywhere, because it is convenient: give someone the rights once and never think about it again. The trouble is that a permanent privilege is exploitable at every moment of its existence, not only during the rare occasions it is legitimately used. A dormant vendor account, an engineer's always-on administrative rights, a service login left active after a project ended - each is a live path an attacker can take, and its risk is proportional to how long it exists, which for standing access is essentially forever.
Just-in-time access attacks this by making privilege ephemeral. Access is not a property an account permanently holds; it is a state that is switched on for a defined window and switched off automatically when the window ends. Between uses, the elevated capability does not exist, so there is nothing for an attacker to steal, phish, or abuse. This is distinct from controlling the credential itself, which is what privileged access management does, and from limiting the scope of what an account may touch, which is least privilege. Just-in-time is specifically about the time dimension: not what you can reach or which secret you hold, but when the ability to act is even present.
The clearest case for just-in-time access is the outside party who needs deep access occasionally and never routinely. A controls vendor is called in to update firmware on a compressor package or diagnose a fault. Under the standing model, the vendor is issued an account with the access the job requires, and once the work is done that account almost always remains - active, privileged, and forgotten - because revoking it takes deliberate effort that no one gets around to. Months later it is still a valid way into the plant, held by an organization you no longer have a live relationship with for that task.
With just-in-time access, the same visit works differently. The vendor requests access for the maintenance window; an approver - typically an operations owner - grants it; the privileges become active only for the agreed period; and when the window closes, the access is withdrawn automatically without anyone having to remember. The approval workflow adds a human checkpoint so that access is tied to a specific, sanctioned reason rather than a blanket permanent grant, and the automatic expiry ensures the account cannot outlive its purpose. The result is that the plant is exposed to that vendor's access only during the hours the work is actually happening, instead of indefinitely.
The security payoff of just-in-time access is a smaller attack surface measured over time. If privileged access exists only during sanctioned work windows, then for the vast majority of the calendar there is no active high-power path for an attacker to hijack. A stolen credential is far less useful when the access it once unlocked has already expired, and a compromised account cannot be quietly reactivated for lateral movement if its privileges only exist within approved, time-boxed sessions. Access that is absent by default is access that cannot be abused by default.
This matters most across distributed, lightly staffed operations, where standing vendor and contractor accounts accumulate unnoticed at dozens of remote sites. A cloud SCADA platform such as Merobix supports the model by making remote operational access flow through central, per-person accounts rather than through devices exposed directly to the internet, so access can be granted, scoped, and withdrawn from one place instead of being wired permanently into each site. Combined with approval workflows and automatic expiry, that central control turns just-in-time from an aspiration into an operational habit: the field is reachable when someone has an approved reason and a live window, and closed the rest of the time.
Least privilege limits the scope of what an account may touch - giving it only the permissions its role requires. Just-in-time access limits the time dimension - granting even those permitted privileges only during a bounded window and revoking them automatically afterward. The two are complementary: least privilege narrows what you can do, while just-in-time narrows when you can do it, ideally to only the moments the work is actually happening.
No - they solve different problems and work best together. Privileged access management controls the powerful credential itself, vaulting and brokering it so no human holds the password. Just-in-time access controls the timing, ensuring that even a vaulted privilege is only active during an approved window. A strong program typically uses both: the credential is vaulted, and the access to use it is granted just in time and then expires.
Standing access is a privilege that stays granted whether or not it is being used, which means it is exploitable at every moment it exists rather than only when legitimately needed. Dormant vendor accounts, always-on administrative rights, and forgotten service logins all remain valid paths for an attacker indefinitely. Because the risk of such an account is proportional to how long it exists, permanent grants carry the maximum possible exposure, which just-in-time access removes by making privilege temporary.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.