Notifications
Clear all
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.
NHIMG editorial — based on content published by Aembit: Just-in-time access for workloads and the problem with standing privileges
By the numbers:
- GitGuardian found that 64% of secrets confirmed valid in 2022 were still active and exploitable four years later.
- Attackers begin probing exposed AWS credentials in under 17 minutes on average.
Questions worth separating out
Q: How should security teams phase out standing workload credentials?
A: Begin with the highest-risk workloads first, especially databases, external APIs, and CI/CD pipelines that currently depend on long-lived secrets.
Q: Why do standing NHI credentials remain such a high-risk pattern?
A: Because they create a persistent backdoor that can stay valid long after the workload or secret should no longer be trusted.
Q: What breaks when workload access is still governed like human access?
A: Human-style review cycles are too slow for machine speed.
Practitioner guidance
- Inventory high-value standing credentials first Start with database connections, external API integrations, and CI/CD pipelines that currently rely on long-lived secrets.
- Use attestation as the access gate Require cryptographic proof from the workload environment before issuing any token.
- Run policy changes in shadow mode Compare new JIT decisions against your current access model before enforcement.
What's in the full article
Aembit's full analysis covers the operational detail this post intentionally leaves for the source:
- Step-by-step implementation phases for moving from static secrets to JIT across databases, APIs, and CI/CD.
- Practical policy design guidance for attestation, posture checks, and time-based access conditions.
- Token delivery patterns using sidecars, agents, and serverless extensions for existing workloads.
- Monitoring and audit guidance for SIEM correlation, decision logging, and rollout validation.
👉 Read Aembit's analysis of just-in-time workload access and standing privilege →
Just-in-time workload access: are your controls still built for standing keys?
Explore further
06/06/2026 4:15 am
Standing credential trust is the real failure mode, not secret rotation alone. The article shows why machine credentials create a durable attack surface when access survives beyond the task that created it. Once a key becomes an always-on identity proof, every downstream control depends on perfect detection and revocation timing. That is the wrong operating assumption for NHI governance, and practitioners should treat exposure duration as the primary risk variable.
A few things that frame the scale:
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to the State of Secrets Sprawl 2026.
- DeepSeek alone generated 113,000 new exposed API keys in 2025, showing how AI ecosystems can expand credential exposure before guardrails catch up.
A question worth separating out:
Q: Who is accountable when a workload secret remains active after compromise?
A: The accountable teams are the owners of secret issuance, runtime policy, and revocation workflows, because JIT access only works when identity, policy, and delivery are governed together. The control failure is not just exposure, it is allowing access to persist beyond its intended task.
👉 Read our full editorial: Just-in-time workload access exposes the limits of standing privilege
