Just-in-Time Access vs. Standing Privileges: Why JIT Wins

Standing privileges — admin memberships that exist whether the human is using them or not — are the largest blast-radius multiplier in any privileged-access model. Just-in-time access collapses the window during which a credential is exploitable to the minutes the work actually requires. The math is unambiguous; the operational pattern is what makes it real.

The blast-radius math

Consider a domain admin who is on call but actively performs privileged work for, say, 30 minutes per week. With standing privileges, the credential is exploitable 168 hours a week. With JIT, it is exploitable 30 minutes per week. The exposure ratio is 336 to 1 in favor of JIT. That is not a tuning improvement; that is a structural difference.

The math holds even when JIT is "loose" — a 4-hour window per activation rather than a tight 15 minutes. Loose JIT (say, 8 activations of 4 hours each per week = 32 hours exploitable) is still a 5x reduction over standing membership. The marginal hardening from tightening the window is real but secondary; the big win is getting off the 24×7 floor.

The objections, addressed

"It is going to slow my admins down."

Slightly, yes — by exactly the time it takes to click "Activate" in the PAM portal. Implementations we have measured add about 20 seconds per activation. Anyone who claims the friction is higher is describing an approval-required activation, which is a separate (sometimes intentional) cost. For self-service JIT, the friction is negligible relative to the security benefit.

"What if the admin needs access during an incident at 3 a.m.?"

Two answers. First, self-service activation is available at 3 a.m. just like it is at 3 p.m. Second, for the genuine emergency where even self-service is too slow, that is exactly what break-glass accounts are for. They retain standing membership, they are vaulted, they alarm when used, and they are post-reviewed within 24 hours. Break-glass is the safety valve that lets the rest of the system be strict.

"My service accounts cannot click a button."

Correct, and they should not be on the same model as humans. Service accounts use credential injection (the application authenticates to the vault and receives a credential per request) or workload identity (the application proves what it is via a cryptographic identity and gets short-lived tokens). Neither of those flows requires a human in the loop.

The activation workflow that scales

Three knobs differentiate a JIT workflow that works in production from one that gets bypassed:

1. Activation latency. The button-to-membership delay must be sub-second for self-service tiers. If it is not, admins will hoard pre-activated sessions, which defeats the point.
2. Justification capture. Every activation logs a free-text reason. Reviewers later sample 10% and ask whether the reason fits the action that followed. This is how culture catches up to the control.
3. Auto-revocation reliability. The membership must come off at expiry even if the session crashed, the user closed their laptop, or the network split. Anything less, and a stale activation becomes the same problem as standing privilege.

How DataDike implements JIT

DataDike treats activation as a first-class object: an artifact with an owner, a target, a justification, an approval chain (optional), a duration, and a recorded session attached. The platform writes membership into the directory at activation, captures the resulting session in full, and removes membership at expiry — irrespective of whether the user remembered to log out. Every state transition is timestamped, hash-chained, and SIEM-forwarded.

Typical first targets are Linux SSH (eliminate root or sudo NOPASSWD), Windows RDP (eliminate cached Domain Admin), and database DBA sessions (eliminate shared passwords). After those three, the marginal target picks up dramatically less risk.