Just-in-time access for developers still leaves governance gaps

At a glance

What this is: This is a practical guide to just-in-time access for developers, arguing that temporary access reduces idle exposure but only works when governance and revocation are enforced.

Why it matters: It matters because IAM teams must decide how to balance developer productivity with production risk across human, NHI, and lifecycle governance patterns.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.

👉 Read StrongDM's practical guide to just-in-time access for developers

Context

Just-in-time access is a time-bounded privilege model that grants access only when a task needs it and removes it when the task ends. In practice, that idea is attractive because developers sometimes need production data to debug issues, yet standing access increases the blast radius if credentials are misused or left behind.

The governance question is not whether developers should ever touch production, but whether the access model preserves least privilege once the request is approved. For human IAM programmes, JIT changes the shape of access reviews, approval chains, and audit evidence, while for NHI programmes it reinforces the same principle of ephemeral entitlement rather than persistent access.

Key questions

Q: How should security teams implement just-in-time access for developers?

A: Security teams should start with narrow baseline roles, require a clear request and approval path, and expire access automatically after the troubleshooting task ends. The key is to make the temporary grant easy to review and easy to revoke. JIT works best when it reduces standing privilege without turning exception handling into routine access.

Q: Why does just-in-time access reduce risk in production environments?

A: It reduces the time an account can be abused by removing the default of always-on access. That matters in production because leaked credentials, shared jump paths, or unattended sessions create less opportunity for misuse when access exists only for a defined task. The benefit comes from shortening exposure, not from making the underlying workload less sensitive.

Q: What breaks when developers keep persistent production access?

A: Persistent access creates idle privilege, weakens audit confidence, and increases the blast radius if a device or credential is compromised. It also encourages access to become habitual rather than exceptional, which makes reviews less meaningful. In practice, the longer the access persists, the harder it is to defend under least-privilege expectations.

Q: How do you know if JIT access is actually working?

A: Look for short-lived sessions, complete approval records, and reliable revocation evidence. If developers still retain access after the task is complete, or if sessions cannot be tied back to a reason and owner, the model is not functioning as intended. Working JIT should leave a clear and complete audit trail.

Technical breakdown

How just-in-time access changes privilege duration

JIT access shortens the lifetime of an entitlement from persistent to task-scoped. Instead of pre-provisioning broad access, the system grants a narrowly defined role or session for a fixed window, then removes it. That matters because the security value comes from reducing the time in which an account can be abused, not from the request mechanism itself. If the underlying role remains overbroad, JIT only narrows exposure time, not exposure scope. In other words, time control and privilege design have to work together.

Practical implication: define the smallest useful role before you automate the time window.

Self-service provisioning and audit trails in JIT workflows

Self-service access can improve delivery speed, but it also shifts trust from administrators to policy and logging. A JIT workflow needs a clear approval path, a recorded reason, and a session trail that shows who received access, when it started, and when it ended. Without those controls, temporary access becomes difficult to defend in audits and harder to investigate after misuse. The operational issue is not self-service itself, but whether every temporary grant produces evidence strong enough for review and revocation.

Practical implication: require request justification, approval evidence, and complete session logging for every temporary grant.

Why JIT does not replace lifecycle governance

JIT is a provisioning pattern, not a full governance model. It can reduce standing access, but it does not automatically solve joiner-mover-leaver processes, entitlement recertification, or the need to remove dormant privileges across systems. If the underlying account or role remains in place after use, the programme still carries lifecycle debt. That is why JIT works best as part of a broader access governance design rather than as a standalone control layered over legacy privilege sprawl.

Practical implication: pair JIT with recertification and offboarding controls so temporary access does not become permanent residue.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

JIT access is a duration control, not a privilege model. The article correctly focuses on temporary access, but the deeper governance problem is whether a role is already narrow enough before the timer starts. If the underlying entitlement is broad, JIT only shrinks the abuse window and leaves the privilege surface intact. Practitioners should treat JIT as a limiter on exposure time, not as a substitute for entitlement design.

Standing access to production databases is the control failure JIT is trying to contain. Persistent developer access creates idle entitlement, weak auditability, and a larger blast radius when credentials leak or laptops are lost. The relevant governance premise is that developers should not retain production access longer than the task requires. Once access becomes task-scoped, recertification and revocation become easier to defend under NIST CSF and zero-trust access principles.

Temporary access only works when the approval record and session record line up. A JIT grant without a reason, a timestamp, and a revocation event leaves a compliance gap even if the access was short-lived. That is why JIT governance is as much about evidence quality as it is about privilege reduction. Security teams should treat the audit trail as part of the control, not as a reporting afterthought.

Developer self-service changes the operating model for IAM and PAM teams. The article points to a world where access can be requested and provisioned on demand, which means policy must move closer to runtime decisions. That does not remove human accountability. It raises the bar for governance precision, because the team now has to distinguish approved temporary access from uncontrolled convenience access.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to NHI Mgmt Group research.
• Access governance weakens quickly when revocation is delayed, so the NHI Lifecycle Management Guide is the natural next resource for teams formalising removal and review processes.

What this signals

Standing privilege is still the structural problem JIT is meant to address. The model only changes security outcomes if temporary access is paired with evidence, revocation, and lifecycle cleanup. Teams that treat JIT as a convenience layer over broad roles will not reduce governance debt; they will only shorten the window in which that debt can be abused.

The next step for practitioners is to connect JIT workflows to access review, offboarding, and monitoring so that temporary access does not become invisible access. The NHI Lifecycle Management Guide is useful here because the same governance pattern applies whether the subject is a person, a service identity, or a short-lived operational exception.

For practitioners

• Tighten the baseline role before enabling JIT Start with read-only or narrowly scoped production roles, then grant temporary elevation only for the specific task. If the standing role is too broad, the temporary window still leaves too much room for misuse.
• Make every temporary grant auditable end to end Capture the request reason, approver, start time, end time, and revocation event for each session. Use those records to support access reviews and to prove the access ended as expected.
• Tie JIT to lifecycle removal, not just session expiry Confirm that accounts and roles are also removed or recertified after they are no longer needed, especially for developers who switch projects frequently. That prevents old privileges from surviving the temporary session model.
• Separate debugging access from ongoing operational access Use JIT for short production troubleshooting, then move developers back to monitoring tools such as logs and observability platforms once the issue is resolved. This keeps direct access from becoming the default troubleshooting path.

Key takeaways

• JIT access reduces exposure time, but it does not fix a broad or poorly designed entitlement model.
• The control is only defensible when approvals, session logs, and revocation evidence are complete.
• Teams should connect JIT to lifecycle cleanup so temporary access does not leave permanent residue.

Key terms

• Just-in-time access: Just-in-time access is a privilege model that grants access only for the duration of a specific task. For identity governance, it narrows exposure time, but it still depends on the quality of the underlying role, approval, and revocation process.
• Standing privilege: Standing privilege is access that remains available without needing a fresh business reason each time it is used. In practice, it increases the attack surface because unused access can still be abused, and it makes entitlement reviews harder to trust.
• Revocation evidence: Revocation evidence is the record that proves access actually ended when the task ended. It usually includes the request, approval, session timestamps, and closure event. Without that evidence, temporary access can be claimed but not reliably verified.
• Lifecycle cleanup: Lifecycle cleanup is the process of removing access that is no longer needed after a role change, project move, or task completion. For temporary access models, it ensures exception handling does not leave behind dormant privileges that later become security debt.

Deepen your knowledge

Just-in-time access and NHI lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building temporary access controls for developers or service identities, it is worth exploring.

This post draws on content published by StrongDM: A Practical Approach to Just-in-Time (JIT) Access for Developers. Read the original.