Notifications
Clear all
Topic starter
12/06/2026 9:27 pm
TL;DR: Developer speed and security are colliding in high-velocity environments because re-authentication, tool switching, and manual access steps push engineers toward workarounds such as credential sharing and insecure key storage, according to JumpCloud. The real issue is not convenience versus control, but whether identity governance can embed least-privilege access into native development workflows without creating bypass paths.
NHIMG editorial — based on content published by JumpCloud: How do you secure your organization without slowing down your developers?
Questions worth separating out
Q: How should security teams reduce developer access friction without weakening control?
A: Start by removing the steps that cause engineers to bypass policy, such as repeated re-authentication and tool switching.
Q: Why do developers often bypass security controls in high-velocity environments?
A: They bypass controls when the approved process slows delivery more than the task itself.
Q: What breaks when just-in-time access is not embedded in developer tools?
A: JIT loses its value when engineers must leave their CLI, SSH session, or IDE to request it.
Practitioner guidance
- Map access friction to bypass behaviour Identify where developers re-authenticate most often, switch tools unnecessarily, or copy credentials into local storage.
- Embed access requests inside native tools Expose authorisation in CLI and IDE paths so engineers can request and receive access without leaving their working context.
- Replace standing developer access with JIT controls Use just-in-time access for elevated project, cloud, and repository permissions so privileges expire when the task ends.
What's in the full article
JumpCloud's full blog post covers the operational detail this post intentionally leaves for the source:
- Examples of how API-based access management fits into developer terminals and command-line workflows
- Practical detail on just-in-time access and automated provisioning in day-to-day engineering environments
- The vendor's explanation of how native tool integration is positioned for secure developer access
- Implementation framing around reducing re-authentication and tool-switching friction in production workflows
👉 Read JumpCloud's analysis of frictionless developer access and JIT controls →
Developer workflows and access friction: where IAM breaks down?
Explore further
12/06/2026 11:33 pm
Developer friction is an identity governance failure, not a usability side issue. When security forces repeated re-authentication, tool switching, and manual approval loops, engineers predictably route around policy to keep delivery moving. That behaviour creates blind spots that are operationally normal and security-relevant at the same time. Practitioners should treat access friction as a control-evasion signal, not just a productivity complaint.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, which means access design is already becoming a lifecycle problem rather than a point-in-time approval problem.
A question worth separating out:
Q: How do teams know whether developer identity controls are actually working?
A: Look for evidence that engineers complete normal work without creating side paths around policy. If you see frequent credential sharing, local secret storage, or repeated manual access exceptions, the control is not operating where work happens. Effective governance is visible in lower workaround rates, cleaner revocation, and fewer unmanaged credentials in circulation.
👉 Read our full editorial: Frictionless developer access is now an identity governance issue
