TL;DR: Akeyless shows that static secrets still persist across code, pipelines, shared accounts, and AI workloads because most organisations cannot jump straight to secretless authentication. The practical shift is from centralising and rotating long-lived credentials toward dynamic credentials and workload identity, because static access still leaves a breach window open between changes.
At a glance
What this is: Akeyless outlines why static secrets remain embedded in applications and pipelines, and why the path forward is incremental rather than immediate secret removal.
Why it matters: IAM and NHI teams need to treat secret sprawl, rotation, and workload identity as a staged governance problem, not a single tooling decision.
👉 Read Akeyless's analysis of static secrets, rotation, and workload identity
Context
Static secrets are credentials that stay valid until someone rotates or revokes them, which makes them easy to embed but hard to govern at scale. In workload environments, that creates a control gap because the credential often outlives the task, deployment, or application that needs it.
The article argues that most organisations cannot replace every static secret at once because application dependencies, legacy systems, and mixed deployment patterns still require passwords, API keys, or tokens. That means identity governance has to move in phases: gain visibility first, then shorten credential lifetime, then remove stored secrets where workload identity is supported.
Key questions
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. The key is to preserve service continuity while progressively shortening credential lifetime and reducing the number of places a secret must exist.
Q: Why do rotated secrets still leave access risk in cloud environments?
A: Rotated secrets can reduce exposure of the credential value, but they do not necessarily remove authorization in the target system. If the destination account still has always-on permissions, the real risk remains standing access rather than the password itself.
Q: What breaks when applications keep using embedded API keys and passwords?
A: The main failure is persistence. Embedded credentials survive in code, pipelines, and shared systems long enough to be copied, reused, or abused, often across more than one application. Once one of those credentials leaks, the same secret can open multiple paths before defenders can revoke it.
Q: When should organisations move from rotation to workload identity?
A: Move to workload identity when the target platform can authenticate the workload directly and the application no longer needs to carry its own bootstrap secret. If the system still needs a stored secret to log in, rotation is still useful. If it can trust the workload’s platform identity, secretless access is the better endpoint.
Technical breakdown
Why static secrets create a standing-access problem
Static secrets do not expire on use, so they create a standing-access model even when the workload only needs brief access. The security issue is not just storage, but persistence: the same password, API key, or token can be reused across code, pipelines, shared accounts, and multiple applications. That creates a broad blast radius because compromise of one secret often exposes more than one system or environment. For NHI governance, the control question is how much access remains live between changes, not whether the secret is centrally stored.
Practical implication: Treat every static secret as standing access until rotation, revocation, or replacement proves otherwise.
How rotation changes the risk without removing the identity
Automated rotation reduces the time a credential value stays usable, but it does not remove the underlying identity or entitlement. In practice, this means the secret changes while the application, account, or service permissions may remain the same. That is still an improvement because it narrows the exposure window and improves auditability, but it does not deliver secretless access. The article’s phased approach reflects a common reality in NHI programmes: rotation is often the bridge control, not the end state. Its value comes from limiting persistence while teams work toward dynamic issuance.
Practical implication: Use rotation to shrink exposure windows, then track which identities still retain standing privileges after each rotation cycle.
Why workload identity matters more than storing another bootstrap secret
Workload identity shifts authentication from possession of a stored secret to proof of platform identity, such as a Kubernetes service account or cloud-issued identity. That matters because the application no longer needs a durable credential sitting in code or memory just to reach the secret manager or target system. The article also shows why this is especially relevant for AI agents: they may choose actions at runtime, so credential possession and authorisation need to be separated more carefully than with predefined workloads. Identity can establish who is acting, but runtime policy still decides what should happen.
Practical implication: Move compatible workloads to platform identity so authentication no longer depends on a reusable secret embedded in the application path.
Threat narrative
Attacker objective: The objective is to turn one persistent credential into broad access across workloads before defenders rotate or revoke it.
- Entry occurs when a long-lived secret is embedded in code, pipelines, or shared accounts and then copied across workloads, increasing exposure points.
- Credential access follows because the same static value can be reused or stolen from places where the application and operators already trust it.
- Escalation happens when standing privileges attached to that secret remain valid long enough for an attacker or abusive actor to expand reach.
- Impact is amplified because one exposed credential can unlock multiple applications, databases, or environments before rotation closes the window.
Breaches seen in the wild
- CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.
- Leaked GitHub App private keys 2026: 474 leaked GitHub App private keys still worked, some leaked in 2020, including keys reaching 300 orgs and CDC repos. No misuse confirmed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Static secret persistence is a lifecycle problem, not a storage problem. The article correctly frames the issue as a phased transition because most organisations cannot remove every credential source at once. Centralisation helps with visibility, but governance only changes when teams control lifetime, scope, and issuance path. The practitioner conclusion is that the control objective is not secret hoarding reduction alone, but access persistence reduction.
Static credential centralisation without rotation only concentrates blast radius. Moving secrets into a manager improves auditability, but the article makes clear that standing access still exists if the secret remains valid for long periods. That means the real risk shifts from scattered exposure to governed persistence. The practitioner conclusion is that lifecycle controls matter more than vault location.
Workload identity changes the trust model because possession is no longer the authorisation primitive. Once a workload can authenticate through its platform identity, the organisation is no longer relying on an embedded reusable secret to establish trust. That aligns with NHI governance because the identity becomes the thing being governed, not just the credential value. The practitioner conclusion is that secretless authentication should be the target state where target systems and platforms support it.
Secretless access for AI agents introduces a separate governance requirement: runtime intent. The article’s AI agent discussion is important because an agent can select actions dynamically, which means a valid credential alone does not prove safe use. That is where identity and authorisation split apart in a way many NHI programmes have not modelled. The practitioner conclusion is that agent access needs policy at the point of action, not only at the point of credential issuance.
Ephemeral credential trust debt describes the gap between improved rotation and true secretless access. Organisations often improve their posture by shortening secret lifetime, but they still carry inherited risk until the application stops depending on a stored credential entirely. That debt shows up in mixed estates where static, rotated, and dynamic access patterns coexist. The practitioner conclusion is that the transition plan must explicitly track which systems still depend on each trust mode.
From our research library:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
- 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report.
- Read next: Ultimate Guide to NHIs — Static vs Dynamic Secrets
What this signals
Ephemeral credential trust debt: teams often think rotation has solved the problem when it has only reduced the lifetime of the same underlying entitlement. That debt persists until the application stops needing a stored secret at all, which is why workload identity has become the real end state for mature NHI programmes.
Static secrets create avoidable persistence in AI and workload estates. The article’s core lesson is that storing long-lived credentials in code, pipelines, or shared accounts leaves a control gap that centralisation alone cannot close. According to the Ultimate Guide to NHIs, 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
For practitioners
- Centralise exposed static secrets first Inventory credentials embedded in code, pipelines, configuration files, and shared accounts, then bring them under policy and audit before attempting replacement.
- Shorten the lifetime of long-lived credentials Automate rotation for database passwords, API keys, and cloud access keys that cannot yet be removed, especially where multiple applications reuse the same secret.
- Replace bootstrap secrets with workload identity Use Kubernetes, cloud, or other trusted platform identities to authenticate workloads so applications do not store another reusable secret just to obtain access.
- Separate agent identity from runtime action For AI agents, keep credentials outside the agent context and apply policy to the action being attempted, not only to the secret the agent can access.
- Phase out shared credentials in high-risk systems Prioritise shared database credentials, administrative keys, and service accounts that create the largest blast radius when exposed or reused across multiple systems.
Key takeaways
- Static secrets remain a governance problem because they preserve access longer than the workloads that use them.
- The article’s phased model shows that centralisation and rotation help, but they do not eliminate the underlying trust assumption of persistent credentials.
- Workload identity and secretless authentication matter because they move control from credential storage to identity-based issuance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Static secrets persist because lifecycle change is slower than workload need. |
| NHI-07 — Long-Lived Secrets | The article centres on credentials that remain valid far longer than their intended use. | |
| Recommendation — Map stale credentials to NHI-01 and revoke secrets that outlive the workload or application they support. Prioritise long-lived credentials for rotation or replacement with short-lived issuance. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle control is the direct governance mechanism for rotating and replacing secrets. |
| Recommendation — Apply IA-5 to enforce rotation, revocation, and replacement of workload authenticators. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Exposed or reused static secrets are a direct credential-access path for attackers. |
| Recommendation — Hunt for leaked static credentials as credential-access indicators and revoke them quickly. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article shows that entitlement persistence matters even after credential rotation. |
| Recommendation — Review entitlements alongside credential rotation so access does not survive in another form. | ||
Key terms
- Static Secret: A secret, such as an API key or password, that does not change automatically over time. Static secrets require manual or scheduled rotation and represent a higher security risk than dynamic secrets or managed identities.
- Dynamic credentials: Dynamic credentials are secrets issued on demand and allowed to expire automatically after a defined use window. They reduce exposure by limiting how long a credential can be reused, but they only work when applications and access policies can support short-lived authentication without manual exceptions.
- Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
- Secretless Authentication: Secretless authentication is a pattern that keeps long-lived credentials out of application code and runtime memory wherever possible. Instead of exposing secrets directly to workloads, the access path mediates credential delivery at connection time, reducing the chance that stolen configuration or code reveals reusable access.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step migration phases from scattered static secrets to secretless authentication
- Demonstration details showing how rotated secrets, dynamic secrets, and workload identity behave in practice
- Practical examples of Kubernetes service-account authentication and secret brokering
- The webinar discussion of AI agent access, intent, and why secret placement matters
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on September 25, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org