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
