Topic starter
06/06/2026 2:31 am
TL;DR: Standing workload credentials create persistent attack paths, and GitGuardian found 64% of secrets confirmed valid in 2022 were still active four years later. Aembit’s analysis frames just-in-time access as a zero-trust response for workloads, but the real issue is that static IAM assumptions do not survive modern machine speed.
Editorial analysis by NHI Mgmt Group, based on content published by Aembit: “Just-in-Time Access for Workloads: Eliminating Standing Privileges”.
By the numbers:
- GitGuardian’s 2026 report found 64% of secrets confirmed valid in 2022 were still active and exploitable four years later.
Key questions
Q: What breaks when workload access still depends on standing keys?
A: Standing keys turn workload identity into a reusable backdoor because they stay valid long after the task that justified them has ended.
Q: Why do static workload credentials create more risk than they appear to?
A: Static workload credentials create durable trust, which means one stolen secret can be reused repeatedly until it is revoked or rotated.
Q: How should teams decide when just-in-time access is better than long-lived secrets?
A: Teams should prioritise just-in-time access when a workload reaches sensitive data, production systems, or third-party services and does not need persistent reuse.
Practitioner guidance
- Map high-risk workloads first Begin with database connections, external API integrations, and CI/CD pipelines that already have production reach.
- Prove workload identity cryptographically Use environment attestation such as cloud instance identity documents or Kubernetes service account tokens before issuing temporary access.
- Issue short-lived tokens at request time Replace locally stored keys with tokens that are scoped to a single task and expire automatically when the job completes.
Bottom line: Standing workload credentials create a durable attack path because they remain valid far longer than the activity they were meant to support.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
06/06/2026 4:15 am
Standing workload privilege is the structural failure, not just a poor secret-hygiene choice. Workload credentials that remain valid after issuance create a governance model built on persistence, while modern machine identity needs access that exists only at the moment of use. This is why JIT matters to NHI programmes: the control boundary has shifted from storage to issuance, and the practitioner implication is that standing privilege must be treated as the exception, not the baseline.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How do security teams know if workload access management is actually working?
A: Workload access management is working when each request is evaluated in context and denied unless the workload, environment, and action all match policy. Warning signs include broad allow rules, static credentials, and access paths that remain valid after the workload’s task should have ended.
👉 Read our full editorial: Just-in-time workload access exposes the limits of standing privilege
This post was modified 1 day ago by NHI Mgmt Group