# Just-in-time access for engineering teams

> Just-in-time access for engineering teams removes standing admin rights without slowing incidents, deployments, or routine production work.

Standing administrator rights are an operating shortcut with an unlimited expiry date. They save a few minutes on the day somebody grants them, then remain available through stolen sessions, compromised laptops, hurried commands, and employees whose jobs have changed. Just-in-time access for engineering teams replaces that open-ended risk with a short, attributable grant for a defined task.

The change should make legitimate production work faster, not turn every database query into a management ceremony. I have seen access projects fail because security treated approval as the control and ignored the requester's path. A good system gets an engineer the smallest useful role in minutes, removes it automatically, records why it existed, and preserves a tested route for the night when the normal control plane is unavailable.

## Standing access is accumulated operational debt

Standing access means a person can use a privileged role without a new decision at the time of use. The role may come from a cloud IAM binding, a directory group, a Kubernetes binding, a database account, an SSH key, or a local administrator group. The mechanism changes, but the exposure is the same: privilege survives longer than the task that justified it.

Teams usually collect this debt one reasonable exception at a time. An engineer needs production access during an incident. A release fails, so somebody adds a broader role. A contractor must inspect a customer problem. Nobody wants to risk revoking access before the next on-call shift, and nobody owns the later cleanup. Six months later, the group called production-admin contains people, automation identities, abandoned experiments, and at least one executive who has never opened a terminal.

That is not just an insider-threat story. A phished identity with permanent read access can quietly collect data. A stolen browser session with permanent write access can change infrastructure before the team understands what happened. A tired engineer can run a correct command against the wrong environment. Short duration reduces the time in which each of those mistakes can happen, while narrow scope limits what the mistake can touch.

Do not confuse just-in-time access with single sign-on or multifactor authentication. Authentication proves who is asking. Authorization decides what that identity may do. JIT changes when and under what conditions privileged authorization becomes active. A strongly authenticated identity with a permanent owner role still has permanent power.

Human access and workload access also need different designs. A developer asking to diagnose production can state a reason, complete fresh authentication, and wait for an approver. A deployment job cannot meaningfully provide human justification. Workloads should use short-lived credentials tied to workload identity and pipeline policy, not pretend to be people inside an approval queue.

## Eligibility, activation, and expiry form the control

A usable JIT model has three distinct states: a person may be eligible for a role, may activate it under policy, and must lose it when the grant expires. Blurring eligibility with privilege recreates standing access under a nicer name.

Eligibility answers a slow-changing question: could this person reasonably need this role as part of the job? The database on-call group may be eligible to request production database operator. Most application engineers may be eligible for production log reader. Very few people should be eligible for organization owner. Managers and system owners can review eligibility on a schedule because it describes job relationships, not an urgent task.

Activation answers the immediate question: should this eligible person get this scope now? The decision can use the requested role, resource, duration, ticket, identity assurance, device state, on-call status, or deployment window. Low-risk access may activate automatically after fresh authentication and a reason. A destructive database role may need approval from the current incident commander or service owner.

Expiry is the part teams underestimate. An approval workflow without reliable revocation is a ticketing system attached to permanent access. The access platform must remove the binding, group membership, certificate validity, or session when time runs out. It should also let the requester relinquish access early. Revocation must work even when the engineer closes a laptop and forgets the request.

NIST Special Publication 800-207 describes zero trust in terms of least-privilege decisions made per request, based on dynamic policy rather than network location. JIT is one concrete way to apply that idea to administrative work. I would qualify the phrase per request, though: forcing a human approval for every command is neither necessary nor workable. The useful request boundary is the task-bound session, such as 30 minutes of read-only database access for one incident.

The event record should make the state transition reconstructable. At minimum, retain requester, eligibility source, role, resource scope, requested and granted duration, reason, policy result, approver if one existed, activation time, expiry or revocation time, and a correlation value for the incident or change. A generic audit entry saying group membership changed cannot answer why the access existed.

## Tooling should follow the enforcement point

Choose the tool that can grant and remove access at the systems you actually operate. Buying a polished approval screen before mapping enforcement points produces a convincing demo and a weak control.

Cloud-native tools work well when most privileged resources live in one provider. Microsoft Entra Privileged Identity Management separates eligible and active assignments for Entra roles, Azure roles, and managed groups. It can require approval, a reason, multifactor authentication, a time limit, and access reviews. Google Cloud Privileged Access Manager uses entitlements that define eligible principals, roles, scope, maximum duration, justification, and optional approvers. Its audit trail records grants and their context. AWS documents temporary privileged access through IAM Identity Center integrations, including partner-managed and self-managed approaches, rather than presenting one identical native workflow for every account design.

Use those native controls when their scope matches the estate. They understand their own role model, produce provider audit events, and avoid another privileged control plane. The tradeoff appears when an incident crosses cloud accounts, Kubernetes clusters, databases, internal tools, and SSH hosts. Engineers then face different request paths and security must join several event streams.

Cross-platform privileged access brokers give people one request experience across several targets. Depending on the product, the broker may issue short-lived certificates, add temporary group membership, assume cloud roles, proxy database sessions, or create time-limited bindings. Evaluate the actual connector for each target. A catalog logo does not prove that revocation is timely, scope is narrow, or an existing session ends at expiry.

Identity governance products can also drive temporary group membership and approval. They fit organizations that already manage joiner, mover, and leaver processes in the same system. Watch propagation delay. If a group change moves through a directory, SCIM provisioning, an application cache, and a database mapping, activation may take several minutes and deactivation may take longer. Measure both paths with a stopwatch.

Building a narrow layer is reasonable when the target set is small and the underlying platforms already support short-lived roles or certificates. The layer should evaluate policy and call native APIs; it should not become a new credential vault. Keep the first version deliberately boring: authenticated request, policy decision, idempotent grant, durable expiry job, append-only event, and an operator view. If the team cannot make revocation survive retries and outages, use a maintained product.

Ask vendors and internal builders to demonstrate five failures, not five happy paths: the approver never responds, the target API times out after applying the grant, the expiry worker restarts, the directory propagation lags, and the access platform itself is down during an incident. Their answers reveal more than a feature matrix.

## Scope and duration do more than approval

The safest approval is still dangerous if it grants owner across an organization for eight hours. Role scope and duration usually reduce more risk than adding another person to the decision.

Start with tasks, not existing administrator groups. Write down what engineers actually do: read logs for one service, restart one workload, inspect a replica, run an approved migration, change a feature flag, or recover a locked account. Then map each task to the smallest role the target can enforce. If a platform only offers broad built-in roles, create a custom role where the maintenance cost is justified. Do not create dozens of roles that differ by one obscure permission; nobody will choose correctly under pressure.

Resource scope must be visible in the request. Production-reader is ambiguous if the company has several accounts, clusters, and regions. Show the human name and the machine identifier together, such as Payments production followed by the account and cluster identifiers. Engineers should be able to confirm the target before activating access, and approvers should not need a separate inventory to understand it.

Set default durations from the task. Reading logs often needs 30 or 60 minutes. A planned migration may need the change window plus a small buffer. Incident command may justify a longer grant, but it should still expire. Let requesters ask for less than the maximum, and require a new policy decision for an extension. Silent auto-renewal turns temporary privilege into standing privilege with extra events.

Approval is appropriate when a second person holds useful context. A service owner can judge an unusual production write. An incident commander can confirm that an emergency action belongs to the incident. A line manager often knows neither the system nor the current risk, so manager approval adds delay without improving the decision.

For low-risk roles, replace approval with controls that act immediately: known eligibility, fresh multifactor authentication, a managed device, a valid ticket or incident, limited scope, short duration, and notification to the owning team. Reserve manual review for privileges that can destroy data, alter access policy, expose regulated records, or disable monitoring. This keeps the approval queue small enough that approvers still pay attention.

## The request path must beat the workaround

Engineers will use JIT access when the approved path is faster and more predictable than borrowing credentials, keeping old sessions alive, or asking an administrator in chat. Treat request latency as a product requirement.

Offer the path where work begins. A web interface is useful for discovery and review. A command-line path is better during an incident, provided it uses the same policy and audit service. Chat can notify an approver, but the approval action should preserve strong identity and request details rather than rely on a vague thumbs-up. Ticket integration should attach context without forcing the requester to copy fields between systems.

A request contract prevents the front ends from drifting. The following example is small enough for a command-line client and explicit enough for policy evaluation:

```yaml
requester: eng-1842
role: database-operator
resource: payments-prod-replica
duration_minutes: 30
reason: investigate replica lag
incident: INC-4821
```

The response should tell the engineer what happened and when the state will change:

```text
request_id: jit-7f31
decision: granted
scope: payments-prod-replica
expires_at: 2026-08-09T02:15:00Z
credential: use existing SSO session
```

Do not return granted before the target confirms the binding. If the target call times out, reconcile by reading the target state with the request ID or an idempotency marker. Retrying a blind create can issue duplicate grants, while treating the timeout as denial can leave privilege active without telling the requester.

Make errors actionable. Not eligible should name the role owner or the documented route to eligibility. Approval pending should identify the approver group and expiry of the request, not expose one person as a permanent bottleneck. Grant propagation should show that the policy approved access but the target has not confirmed it. Those are different failures and need different operators.

Fresh authentication should happen close to activation. Reusing a session authenticated at the start of the day weakens the value of an intentional privilege boundary. For the highest roles, require phishing-resistant authentication when the identity platform and hardware support it. Do not make engineers repeat authentication for every command inside the approved session.

## Rollout starts with evidence, not revocation

A low-friction rollout observes how privileged access is used before removing it. Start by inventorying active assignments and actual administrative events across identity providers, cloud IAM, clusters, databases, source control, CI/CD, monitoring, and endpoint administration.

The assignment list alone is misleading. Some permanent roles have not been used in a year, while an obscure group may authorize a daily production task. Join the entitlement data to sign-in and target audit events where possible. Separate human accounts from service identities immediately. Also flag shared accounts, local users outside central identity, long-lived keys, and paths that bypass the system you plan to introduce.

Classify tasks by impact and frequency. A frequent read-only task is the best first candidate because the team can exercise the workflow often and the consequence of a policy mistake is limited. A rare organization-owner action is a poor pilot: nobody builds muscle memory, and a defect appears during the worst possible moment.

Run an observation period in which the JIT system calculates decisions but does not remove current access. Compare requested roles and durations with what engineers actually use. Find requests that lack a matching entitlement, approval routes with no available approver, and target systems where expiry cannot be verified. This is also the time to test events, dashboards, and alerts.

Then move one team and a small set of roles to enforced temporary access. Keep current permanent grants for a short, declared overlap while you verify request latency, activation success, expiry, and on-call coverage. Give the overlap an end date and an owner. An indefinite safety period is how permanent access survives every access program.

Expand by task family, not by an arbitrary department calendar. Logs and monitoring may move first, then controlled operational actions, then sensitive data and identity administration. Remove each standing role only after the temporary route works from the engineer's normal device, the backup approver route works, and the break-glass procedure has passed a live exercise.

Communicate the exact change. Engineers need to know which role will disappear, what replaces it, how long activation normally takes, who responds after hours, and what to do if the access service fails. A slogan about zero trust will not help somebody handling a production outage.

## Break-glass access is a separate control

Emergency access exists for failure of the normal JIT path, not as a faster option when an approver is slow. Keep it separate, hard to use accidentally, and tested often enough that the first test is not a real outage.

A practical design uses a very small number of emergency identities or credentials stored outside the normal identity dependency. If the primary identity provider is unavailable, an emergency account inside that same provider may offer no recovery. The exact mechanism depends on the target, but it must cover the failures in your threat and dependency model.

Protect emergency access with strong custody, immediate notification, and a mandatory after-action review. Retrieval should create an event in a separate channel where possible. Rotate or replace the secret after use, review every action performed with it, and close the route that made normal access unavailable. The account may need permanent privilege because it exists for control-plane failure, but nobody should use it for ordinary work.

Microsoft's Entra PIM deployment guidance recommends keeping no permanently active assignments for ordinary privileged roles while maintaining two cloud-only emergency Global Administrator accounts. The useful part of that advice is the separation of everyday eligibility from exceptional recovery. Do not copy the number or topology blindly into another environment; design emergency access around independent failure domains.

Test four situations: the identity provider is down, the JIT broker is down, the target API accepts grants but the request service cannot see the response, and every normal approver is unreachable. During each exercise, record time to usable access, who received the notification, what evidence the target produced, and whether the team could revoke the grant afterward.

Never let break-glass become a shared root password pasted into a password manager folder that half the company can open. That is standing admin access with weak attribution. If the emergency path cannot identify the custodian and time of retrieval, compensate with physical or organizational dual control and fix the design.

## A 2 a.m. failure exposes the weak seams

Consider an on-call engineer responding to rising payment failures. The engineer has permanent log access but needs a database operation to clear a stuck queue. The new JIT policy requires approval from the database team lead, and the request interface shows only pending. The lead is asleep, the backup rotation was never added, and the break-glass document assumes the identity platform is down rather than the approval route.

The engineer messages several administrators. One activates a broad production role for the engineer through a cloud console, outside the JIT service, and promises to remove it later. The incident resolves. The administrator goes back to sleep, the role remains active, and the JIT audit trail shows a denied or abandoned request rather than the access that changed production.

Every element looked defensible during design: sensitive writes required approval, a senior owner controlled the role, and emergency credentials existed. The system failed because the approval policy did not model after-hours ownership, the target allowed an unmanaged grant path, and reconciliation watched JIT grants rather than all active privilege.

Fix the workflow, not the engineer. Route incident requests to the current on-call role instead of a named person. Allow a pre-defined narrow queue-operator role for a short period when a valid high-severity incident exists, with immediate notification and later review. Detect direct privileged bindings at the target and either import them into the access record or alert on them. Make the break-glass instructions cover approval failure as well as identity failure.

This is why a launch metric such as number of JIT requests says little. A busy request queue may mean good adoption, or it may mean the role design forces unnecessary elevation. A clean dashboard may mean low risk, or it may mean engineers found a path the dashboard cannot see.

## Measure remaining privilege and task delay

Measure whether privilege remains active without current work and whether legitimate work waits on the control. Those two views keep security and engineering honest.

For exposure, track active privileged assignments by human identity, how long they remain active, grants beyond their requested end, unused eligibility, direct grants outside the managed path, emergency access events, and active sessions that survive revocation. Report the count and age of exceptions rather than hiding them in a compliance note. Every exception needs an owner and review date.

For usability, measure request-to-decision time, decision-to-target-confirmation time, failed activations by reason, expiry success, early relinquishment, after-hours approval coverage, and tasks abandoned or rerouted through support. Use medians and tail values because a reasonable average can hide the one incident that waited an hour. Break the data down by role and target; one slow directory integration can distort the whole program.

Review samples of reasons, but do not reward long prose. Investigate replica lag tied to incident INC-4821 is better than a paragraph copied from a policy. Structured task, resource, and incident fields produce better evidence than forcing engineers to perform seriousness in a text box.

Reconcile from the enforcement point. On a schedule, enumerate privileged bindings and sessions at each target, then compare them with active grants in the JIT system. This catches manual console changes, failed expiry, connector bugs, and legacy credentials. A JIT database that agrees with itself proves only that its own records are consistent.

The review should change policy. If nearly every request for a low-risk reader role gets approved immediately, remove manual approval and strengthen eligibility and notification. If people repeatedly request owner to perform one action, create a narrower role. If durations cluster at the maximum, inspect whether tasks truly need that time or the interface makes smaller choices inconvenient.

Access is ready to scale when engineers can explain the normal and emergency paths without searching a long document, on-call approvers receive usable context, target reconciliation finds no unexplained privilege, and expiry works during partial outages. Until then, expanding the program only distributes the same gaps across more systems.

## Keep service identities out of the human queue

Machine access needs short lifetime and narrow scope, but a human JIT approval flow is the wrong mechanism for routine automation. A pipeline waiting for somebody to approve every deployment creates pressure for permanent bypass credentials.

Use workload identity federation or the platform's native workload identity so the job exchanges verifiable runtime identity for short-lived credentials. Bind permissions to repository, environment, branch or protected deployment context where the platform supports those claims. A deployment role should exist only for the job and target environment that need it. Store no renewable personal credential in CI variables.

Approval can still exist at the change boundary. A protected environment may require a person to approve a production deployment, after which the pipeline receives its own short-lived role. The approver authorizes the change, not a developer's reusable administrative session. This distinction preserves attribution and prevents automation from inheriting a person's broad rights.

AI coding agents make this boundary more urgent. An agent operating in a repository should not inherit the engineer's standing cloud session merely because both run on the same workstation. Give the agent an isolated identity and explicit tools, then issue task-bound credentials only for the action the policy allows. Keep production writes behind deterministic controls that the agent cannot rewrite from the same execution context.

Inventory non-human identities during the same rollout, but migrate them on a separate track. Find long-lived cloud keys, database passwords, deploy tokens, SSH keys, and shared bot accounts. For each one, identify the workload, target, permissions, issuance path, rotation path, and owner. Unknown ownership is a reason to contain and observe an identity before deletion, not a reason to grant it permanent exemption.

Removing standing admin rights is complete only when the target systems, not the policy document, show that privilege appears for a task and disappears afterward. Make the temporary path quick, reconcile every enforcement point, and rehearse failure. Engineers will accept one deliberate activation. They will work around a control that cannot help them when production is burning.