VaultrisPrivileged Access & Traffic Intelligence
Vaultris

Products

Bastion HostGateway, vault, session recording Intelligent TrafficCorridor monitoring, LPR & BOLO

Industries

Military & Defense Police & Law Enforcement Fire & Emergency Services All industries

Resources

Bastion host guide Compliance & evidence Field notes

Company

About Vaultris Partner programme Request a Demo

Access Control

Just-in-Time Privileged Access: Standing Access Is the Vulnerability

Most privileged access incidents do not begin with a credential that was stolen. They begin with one that was legitimately granted, correctly used, and then never taken away.

Diagram of a just-in-time access request moving from request to approval to a time-boxed grant that expires automatically

The account nobody removed

Read enough incident reports and a pattern shows up that has nothing to do with clever attacks. An engineer was given administrative access for a migration. The migration finished. Two years later the account is still there, still privileged, still carrying a password that was set once and never rotated.

Nobody did anything wrong. Granting the access was correct. Using it was correct. The failure is that removal was somebody's follow-up task, and follow-up tasks lose to whatever is on fire that week.

This is why standing access is the thing worth attacking. An attacker who lands on a workstation is not looking for a way to escalate; they are looking for an account that already has the reach they want. On most networks, several are waiting.

The useful question in an access review is not “should this person have this access?” It is “when was this access last used, and what was it for?” The first question produces a defensible-sounding yes. The second produces the list of things to remove.

What just-in-time actually means

Just-in-time access inverts the default. Instead of holding entitlements continuously and reviewing them periodically, an operator holds nothing, and asks for a specific reach for a specific window when there is work to do.

Four things have to be true for that to be more than a slogan:

  • The grant is bounded in time, and the expiry is enforced by the gateway rather than written in a ticket. If a human has to remember to revoke it, it is not just-in-time access.
  • The grant is bounded in scope — these hosts, this protocol, this account — not membership of a group that happens to reach a great deal more.
  • The request carries a reason, recorded against the case, change or incident it belongs to. A reason field that accepts “maintenance” is a field nobody will ever be able to use.
  • Approval is a person, in the moment, for anything above a defined sensitivity. Pre-approved standing entitlement with an expiry timer is still better than nothing, but it is not the same control.

The objection that matters

The reasonable objection is speed. If an operator has to request access during an outage, the request process is now on the critical path of the fix, and every minute of it is a minute of downtime.

That objection is right, and it is why just-in-time access without a rehearsed emergency path fails in practice — teams quietly build a standing account to route around it, and the whole exercise has made things worse. The answer is not to weaken the default. It is to build the exception properly:

  • A break-glass path that is fast, dual-authorised, time-boxed and loud — it raises an alarm when used rather than waiting for someone to read a log.
  • Pre-staged roles for known scenarios, so the request is a selection rather than a description. An activation role that grants exactly the right reach the moment it is invoked removes most of the latency.
  • Rehearsal on a schedule. A documented emergency path is not a tested one. The first time it is used should not be during the incident.

We have written separately about what that emergency path should look like in break-glass access, designed and about the wider problem in the 3am test.

What changes in the evidence

The security argument for just-in-time access is the obvious one: a smaller number of privileged accounts exist at any moment, so there is less to find and less to abuse.

The argument that tends to land harder with an inspector or an auditor is a different one. Under standing access, the record says a person held administrative rights for two years. Under just-in-time access, the record says they held them for forty minutes on a named date, at the request of a named approver, against a named change, and here is the session recording of what they did with them.

Those are not the same answer to the same question. The second one is defensible without further explanation, which is the property that matters when the question is being asked adversarially.

Where to start

Converting an entire estate at once is how these programmes stall. The order that works:

  • Inventory what is standing today, sorted by reach rather than by count. The domain and hypervisor administrators matter more than a hundred application accounts.
  • Remove the dormant ones first. Access unused for ninety days is rarely defended when someone is asked to justify it in writing.
  • Convert the highest-reach roles next, with the emergency path built before the standing access is withdrawn, not after.
  • Leave the long tail until last. It is the largest number of accounts and the smallest share of the risk.

Vaultris enforces expiry at the gateway rather than relying on directory cleanup, so an entitlement that has run out stops working whether or not anyone remembered it existed. The platform overview covers how the grant, the injection and the recording fit together.

Related field notes

All field notes

Next Step

Want this discipline over your own network?

We will walk your current access paths and show exactly where the gateway sits.