Notifications
Clear all
Topic starter
23/06/2026 9:08 pm
TL;DR: JIT access can reduce persistent database exposure for developers by granting temporary access only when needed, but StrongDM’s guidance also shows that self-service provisioning, auditing, and governance determine whether the model truly limits risk. The core issue is not duration alone, but whether access, oversight, and revocation stay aligned with least-privilege intent.
NHIMG editorial — based on content published by StrongDM: A Practical Approach to Just-in-Time (JIT) Access for Developers
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Make every temporary grant auditable end to end Capture the request reason, approver, start time, end time, and revocation event for each session.
- 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.
What's in the full article
StrongDM's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for configuring self-service access to production databases and servers
- Integration details for using chatbot-driven access requests in existing operational workflows
- Practical notes on compliance logging and access revocation timing for temporary grants
- Context on how StrongDM positions JIT inside its broader PAM and database access model
👉 Read StrongDM's practical guide to just-in-time access for developers →
Just-in-time access for developers: are your controls keeping up?
Explore further
25/06/2026 2:17 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Just-in-time access for developers still leaves governance gaps
