Notifications
Clear all
Topic starter
06/06/2026 2:09 am
TL;DR: Static secrets, shared tokens and credential sprawl create persistent cloud-native attack paths, while dynamic authorization shifts trust to runtime identity proof, context-aware policy and ephemeral tokens, according to Aembit. That changes the governance problem from rotation and storage to verifying workload authenticity at access time and removing secret zero assumptions.
NHIMG editorial — based on content published by Aembit: Static secrets, rotated secrets and dynamic authorization
Questions worth separating out
Q: What breaks when static secrets are used in cloud-native environments?
A: Static secrets break down when the same credential is reused across many services, repositories and pipelines.
Q: Why do service accounts and API keys create more risk than runtime-issued tokens?
A: Service accounts and API keys often persist long enough to be copied, reused and forgotten.
Q: How do security teams know whether dynamic authorization is working?
A: Look for fewer persistent credentials, shorter token lifetimes, and audit records that show workload identity, resource, policy outcome and context for each request.
Practitioner guidance
- Inventory persistent credentials by workload path Map where API keys, database passwords and shared tokens exist across repos, CI/CD systems, config files and service meshes.
- Establish verified workload identity sources Use cloud instance identity, Kubernetes service account tokens or signed metadata as the starting point for authentication.
- Introduce ephemeral tokens for scoped operations Issue short-lived credentials only after policy approval and bind them to a specific resource, namespace or task.
What's in the full article
Aembit's full article covers the operational detail this post intentionally leaves for the source:
- Deployment patterns for Kubernetes, serverless and VM-based workloads, including where sidecars, agents and gateways fit.
- Concrete policy design examples for read-only starts, namespace scoping and resource-specific permissions.
- Troubleshooting guidance for token issuance failures, including clock skew, metadata service reachability and policy-engine latency.
- Operational rollout advice for staging, logging and emergency access procedures when dynamic authorization is introduced.
👉 Read Aembit's analysis of static secrets and dynamic authorization →
Static secrets vs dynamic authorization: what IAM teams need to know?
Explore further
06/06/2026 3:40 am
Static secret governance fails when trust is treated as a stored object instead of a runtime decision. The cloud-native model assumes possession-based authentication can remain stable across repositories, pipelines and microservices. That assumption breaks when credentials are duplicated faster than they are reviewed, because governance becomes a record-keeping exercise instead of a control point. The implication is that identity programmes must stop treating secret storage as the centre of trust.
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.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
A question worth separating out:
Q: How should organisations reduce reliance on secret zero?
A: They should replace bootstrap credentials with cryptographic proof from the runtime environment, then use policy to broker ephemeral access. If a system still needs a stored secret to fetch another secret, the trust chain remains recursive and fragile. The goal is to remove the starting credential entirely, not just protect it better.
👉 Read our full editorial: Dynamic authorization is replacing static secrets in cloud-native IAM
