Just-in-Time Elevation

Just-in-time access converts a permanent grant into a temporary one. Done well it is invisible to administrators; done badly it is the reason they route around the system.

The model

No standing administrative rights.

A request specifying what, why and for how long.

Approval, proportionate to the tier.

Rights granted, and automatically removed at expiry.

The grant record is the audit evidence, which is a by-product rather than an additional step.

What it achieves

The exposure window shrinks from permanent to the duration of actual use.

A compromised identity is useful only during an active grant.

A decision point exists, where standing access has none.

Review becomes possible. Grants are reviewable in a way permanent membership is not.

Attribution is automatic, because the grant names the person and the reason.

The duration question

Long enough for the task, which varies enormously.

Short enough to matter. Eight hours is a working day and is a reasonable default; twenty-four hours is not much better than permanent for many purposes.

Extendable on request, so that a task overrunning does not force a workaround.

Measure actual usage and set defaults from it rather than from a policy guess. Most grants are used for a fraction of their duration.

Approval design

The part that determines adoption.

Tier zero: approval by a second person, always, with a defined route when the approver is unavailable.

Tier one: approval, with automatic approval for defined routine tasks during working hours.

Lower tiers: self-service with recording, or lightweight approval.

An approval that is always granted within seconds is not a control, and an approval that takes an hour is a reason to keep a standing account. Choose deliberately which you are building.

Automatic approval with strong recording is frequently the better trade for routine work.

The break-glass dependency

Just-in-time depends on the granting system being available.

When it is down, nobody can obtain rights, which during an incident is precisely the wrong outcome.

Break-glass accounts are therefore a prerequisite, not an optional addition.

Design them before removing standing access, or the first outage will create a permanent exception.

Rolling it out

Start with tier zero, smallest population and largest benefit.

Run in parallel first: grants available just-in-time while standing rights remain, so administrators can learn the path without risk.

Measure which is used. If people keep using standing rights, the just-in-time path is too slow and that is fixable information.

Then remove standing rights, by cohort, with a rollback.

Then extend to lower tiers.

What breaks

Automation that assumed standing rights, which needs its own service identity rather than a person's.

Scheduled tasks running as an administrator who no longer has permanent rights.

Long-running sessions that outlive the grant, which needs a decision: terminate or allow completion.

Emergency work out of hours, which needs an approval route that functions at three in the morning.

Find these in the parallel-run period, which is the reason for it.

Setting the default duration

Most deployments guess and the data is available.

Measure actual usage: how long between grant and last action, per grant.

Set the default at a percentile of observed usage, not at a round number.

Make extension trivial, so an underestimate is not a workaround-generator.

Report grants that expired unused, which indicates over-requesting rather than a problem.

Report extensions, which indicates the default is too short.

Revisit quarterly for the first year, then annually.

The automation exception

Scripts and scheduled jobs cannot request access interactively, and this is where just-in-time deployments break.

Identify everything running as a person's privileged account, which the authentication logs reveal.

Migrate each to a dedicated service identity with its own scoped rights.

Do this before removing standing rights, or the removal causes outages attributed to the programme.

Where a job genuinely needs elevation, use a service identity with narrow permanent rights rather than pretending it can be just-in-time.

Record those as documented standing exceptions, with scope and review dates.