Topic starter
25/09/2026 5:31 pm
TL;DR: Static secrets remain embedded across code, pipelines, and shared accounts, and Akeyless argues the practical fix is an incremental move from centralisation to rotation, dynamic credentials, and workload identity. The real security problem is that access still persists between rotations, so governance has to shift from credential value management to issuance-time control.
NHIMG editorial: based on content published by Akeyless: Eliminate 1,000+ Static Secrets with Identity-Based Access
Questions worth separating out
Q: How should security teams phase out static secrets without breaking applications?
A: Start by centralising existing secrets, then rotate the highest-risk credentials, and only then replace them with dynamic credentials or workload identity where target systems support it.
Q: Why do static secrets remain risky even when rotation is enabled?
A: Rotation reduces the lifetime of a credential, but it does not eliminate the window in which the secret can be copied, cached, or reused.
Q: What breaks when applications keep shared service-account credentials?
A: Shared credentials collapse accountability and expand blast radius.
Practitioner guidance
- Inventory every persistent secret path Map secrets in code, pipelines, configuration, shared accounts, and bootstrap flows so you know which credentials are truly standing and which are already short-lived.
- Prioritise high-blast-radius credentials first Start with database passwords, cloud administrative keys, and shared service accounts because those credentials create the widest reuse and the hardest recovery paths.
- Centralise then classify remaining static secrets Bring unreplaced credentials under policy, logging, and lifecycle ownership before attempting full removal so you can separate legacy dependencies from solvable sprawl.
What's in the full article
Akeyless's full webinar covers the operational detail this post intentionally leaves for the source:
- Live walkthrough of the phase-by-phase migration from hardcoded credentials to secretless access
- Demonstration of rotating a credential and refreshing the consuming workload without redesigning every application
- Kubernetes service-account authentication example showing how workload identity replaces a stored bootstrap secret
- Discussion of how AI agents change the trust model when credentials are exposed inside the runtime context
👉 Read Akeyless's webinar on eliminating static secrets with identity-based access →
Static secrets and workload identity: where do controls fall short?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/09/2026 5:31 pm
Static secrets persist because most organisations still design for credential value rather than identity continuity. The article shows a common pattern: secrets are first centralised, then rotated, and only later removed where applications can support it. That sequence is sensible because many systems still require passwords or API keys, but it also proves that standing access is the baseline condition, not the exception. Practitioners should treat this as an identity lifecycle problem, not a vault-only problem.
A few things that frame the scale:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
- 30.9% of organisations store long-term credentials directly in code, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: When should teams move from rotation to workload identity and secretless access?
A: Move when the target platform can authenticate the workload directly and the application no longer needs to hold a credential just to start or call a service. That is the point where workload identity becomes the better control because it removes the secret from the application path entirely.
👉 Read our full editorial: Static secrets persist because identity controls lag workload needs
