Notifications
Clear all
Topic starter
14/08/2026 6:34 pm
TL;DR: JIT access often looks healthy on dashboards while privileged work still moves through break-glass accounts, shared admin credentials, and informal bypasses, according to Twine Security. The real control failure is not emergency access itself but the missing return path and approval theatre that leave standing privilege intact.
NHIMG editorial — based on content published by Twine Security: Your JIT Access Program Is Probably a Break-Glass Program
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams stop just-in-time access from becoming break-glass by default?
A: Start by measuring real privileged action paths, not just approved requests.
Q: Why do JIT programs still leave organisations exposed to standing privilege?
A: Because many programmes govern the request but not the removal.
Q: What do security teams get wrong about approval workflows for privileged access?
A: They often confuse approval volume with control quality.
Practitioner guidance
- Measure privileged actions outside the JIT path Count every privileged operation performed through break-glass accounts, shared admin logins, preserved standing access, and informal human delegation.
- Engineer revocation as a separate workflow Define explicit expiry conditions, automated deprovisioning triggers, and verification steps for every temporary grant.
- Rebuild approval logic around live operational context Use incident state, on-call rotation, service ownership, and blast radius as inputs to access decisions.
What's in the full article
Twine Security's full blog covers the operational detail this post intentionally leaves for the source:
- The article's full incident narrative showing how the 02:47 access request moved through the bypass path rather than the JIT workflow.
- The practical breakdown of context signals that matter in access decisions, including on-call status, incident state, and service ownership.
- The author's view on AI-enabled access decisions and why agentic context evaluation changes the governance model.
- The metrics section describing how to measure JIT effectiveness by privileged action path, break-glass usage, and revocation timing.
👉 Read Twine Security's analysis of why JIT access turns into break-glass →
JIT access and break-glass creep: is your control path real?
Explore further
14/08/2026 6:42 pm
JIT access often fails because the organisation has built a grant process without a governable removal process. That is not a tooling problem alone. It is a lifecycle assumption failure: temporary access was treated as temporary by intent, not by enforcement. The implication is that access governance must be evaluated as a complete grant-to-revocation chain, not as an approval queue.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
A question worth separating out:
Q: Who is accountable when a non-human decision system helps grant privileged access?
A: A human remains accountable for the policy, the exceptions, and the outcomes. If a system helps decide who gets access, the organisation still needs a named owner who can explain the basis for the decision and prove that the decision logic is reproducible, reviewable, and limited by policy.
👉 Read our full editorial: Jit access fails when break-glass becomes the real control
