TL;DR: Akeyless argues that secretless architectures still rely on governed keys, certificates, tokens, and other underlying secrets because machines cannot authenticate without them, and that the real shift is toward dynamic credentials, automation, and Zero Standing Privilege across workloads and machine identities. Static secret minimisation matters, but lifecycle governance remains the control plane that prevents exposure, misuse, and long-lived access.
At a glance
What this is: This is an analysis of why secretless architectures still depend on managed secret lifecycles, and why dynamic credentials do not remove the need for governance over keys, certificates, and tokens.
Why it matters: IAM, NHI, and PAM teams need to treat secretless as an access pattern change, not a control replacement, because lifecycle governance still determines exposure window, rotation discipline, and privileged access risk.
By the numbers:
- There are over 50 machine identities for every human identity today.
👉 Read Akeyless's analysis of why secretless architecture still depends on governed secret lifecycles
Context
Secretless architecture is the idea that systems should avoid direct handling of static credentials where possible, but that does not mean authentication disappears. In machine-to-machine environments, workloads still need keys, certificates, tokens, or equivalent mechanisms to establish trust and authorise access.
The governance gap is that many teams treat secretless design as a substitute for lifecycle control. In practice, the control problem shifts from storing secrets safely to issuing, rotating, revoking, and scoping ephemeral credentials across NHI estates, especially where workloads, microservices, and applications exchange access continuously.
For IAM and NHI programmes, the important distinction is between removing secret handling from developers and removing secrets from the environment. The article’s central claim is that the former is feasible, while the latter is not.
Key questions
Q: How should security teams govern secretless architecture in hybrid environments?
A: They should govern it as an access-lifecycle problem, not a removal problem. Secretless design reduces direct handling of credentials, but workloads still rely on keys, certificates, and tokens underneath. The control objective is to minimise exposure, shorten credential lifetime, and make revocation dependable across every system that issues or consumes machine trust.
Q: Why do dynamic credentials reduce risk without eliminating secret management?
A: Dynamic credentials reduce risk because they are short-lived and task-scoped, which shrinks the window for reuse or theft. They do not eliminate secret management because something still has to issue, validate, rotate, and revoke the trust material. If that lifecycle is weak, the architecture still carries the same governance failures.
Q: Where does secretless architecture fail in practice for machine identities?
A: It fails when teams assume abstraction alone is enough and leave credentials with excessive scope or unclear ownership. Machine identities still need clear lifecycle control, and any credential that persists beyond its intended task becomes a reusable attack path. The failure is usually governance, not protocol design.
Q: What is the difference between secretless architecture and zero standing privilege?
A: Secretless architecture is a design approach that reduces direct secret handling, while zero standing privilege is an access model that prevents persistent privilege from lingering between tasks. A system can be secretless in appearance and still violate zero standing privilege if machine identities retain broad or lasting access.
Technical breakdown
Why secretless systems still depend on underlying secrets
Secretless architecture reduces direct exposure of static credentials, but it does not eliminate the cryptographic material that makes trust possible. Workloads still need tokens, certificates, signing keys, or federation material to prove identity and to validate access decisions. In practice, secretless means abstraction: applications stop managing secrets directly, while a backend control plane handles issuance and lifecycle. That distinction matters because the security burden moves rather than disappears. If the backend lifecycle is weak, the architecture still inherits the same compromise paths, just with a different access pattern.
Practical implication: govern the backend lifecycle of keys, certificates, and tokens as the real control surface.
Dynamic credentials and zero standing privilege for NHIs
Dynamic credentials reduce the value of compromise by making access short-lived and task-scoped. Zero Standing Privilege means no identity should retain persistent access when it is not actively needed, which is especially relevant for service accounts, workloads, and application identities. The key technical shift is that privilege is granted at execution time instead of provisioned for indefinite reuse. That reduces the window for abuse, but only if issuance, scope, and revocation are tightly controlled. Without those controls, ephemeral access becomes temporary standing access rather than genuine reduction in risk.
Practical implication: use just-in-time issuance and short TTLs for NHI access that previously depended on persistent credentials.
Why rotation and abstraction are still mandatory control layers
Automated rotation and secret abstraction solve different parts of the problem. Rotation shortens exposure windows for credentials that must still exist, while abstraction removes those credentials from code, configs, and direct operator handling. Secretless architectures typically need both because some underlying systems still depend on certificates and cryptographic keys. The result is a layered governance model: minimise visible secrets, rotate what remains, and ensure revocation is reliable when identities or applications are retired. If any layer is missing, the environment still accumulates long-lived trust debt.
Practical implication: pair secret abstraction with rotation and revocation controls, not one or the other.
Threat narrative
Attacker objective: The attacker aims to exploit long-lived machine trust to gain persistent access without needing interactive user compromise.
- Entry occurs through exposed API keys, passwords, or certificates that remain valid longer than their intended use window.
- Credential abuse follows when static or poorly rotated secrets are reused across workloads, microservices, or applications.
- Impact emerges as attackers leverage persistent machine access to move through systems or misuse authorised services at scale.
Breaches seen in the wild
- OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
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
Secretless is an abstraction model, not a secret elimination model: The article is right to separate direct secret handling from underlying trust material. Machines still need cryptographic credentials to authenticate and authorise, so the governance problem moves into lifecycle management rather than disappearing. The practical conclusion is that secretless programmes should be judged by whether they reduce direct exposure and enforce revocation discipline, not by whether they claim to remove secrets entirely.
Dynamic credentials change the threat shape but not the control requirement: Ephemeral access narrows exposure windows, but only if issuance, scope, and revocation are reliable. That makes lifecycle governance more important, not less, because short-lived access can still be over-scoped, reused, or left dangling through automation gaps. Teams should measure whether temporary access actually expires on schedule and whether all downstream trust paths are invalidated when it does.
Over 50 machine identities for every human identity signals a governance scale problem: The operational load is no longer about a few protected secrets, but about large estates of credentials, certificates, and machine identities that must be inventoried and controlled continuously. This is why NHI governance becomes a programme discipline, not a point solution problem. Practitioners need lifecycle ownership, clear boundaries, and revocation assurance across the whole machine identity estate.
Zero Standing Privilege is the right target for machine identities, but only when paired with lifecycle enforcement: Persistent access is the real enemy in NHI estates because it expands the blast radius of compromise. The article’s model points toward task-scoped, expiring access as the structural control, but that only works when the organisation can prove issuance, expiry, and offboarding are consistently enforced. Practitioners should treat standing privilege as the condition to eliminate, not just the symptom to reduce.
Secretless architecture surfaces a governance maturity test for hybrid environments: Hybrid and multicloud estates amplify the risk that credentials exist in many formats and control planes at once. That makes abstraction, rotation, and workload identity governance part of the same operating model. The field should stop treating secretless as an architecture label and start treating it as a maturity benchmark for how well an organisation controls machine trust at scale.
From our research library:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
- Read next: Guide to NHI Rotation Challenges
What this signals
Secretless architecture only works when the organisation can still govern the credentials it hides: The practical challenge is not whether a developer sees a password, but whether the underlying machine trust can be issued, rotated, and revoked without drift. That makes credential lifecycle control the real operating model behind abstraction.
Zero Standing Privilege should become the default benchmark for workload access: If a service account or application identity can retain reusable access after the task ends, the environment has not reduced standing privilege at all. Teams should design for expiring access, not merely for hidden access.
Lifecycle control is the missing discipline in many secretless programmes: Even where abstraction is strong, unmanaged offboarding and infrequent rotation leave credential residue behind. According to the Ultimate Guide to NHIs, only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
For practitioners
- Define the underlying trust material Inventory which applications, workloads, and integrations still depend on keys, certificates, tokens, or passwords even when the architecture is described as secretless.
- Move persistent access to expiring access Replace long-lived machine credentials with task-scoped, short-lived credentials and enforce revocation when the workload, role, or integration changes.
- Treat rotation as a governance control Set rotation, renewal, and expiry rules for any secret that cannot yet be abstracted, and verify that automation actually invalidates the old credential.
- Separate human and machine access models Do not copy human IAM patterns directly into workload authentication. Model machine access around service-to-service trust, lifecycle ownership, and non-interactive use cases.
Key takeaways
- Secretless architectures reduce direct credential handling, but they still depend on governed keys, certificates, and tokens underneath.
- The main control shift is from manual secret storage to lifecycle governance over issuance, rotation, scope, and revocation.
- Zero Standing Privilege and short-lived credentials are the practical tools that turn abstraction into lower machine-identity risk.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on reducing exposure of keys, passwords, certificates, and tokens. |
| NHI-07 — Long-Lived Secrets | The article argues that long-lived credentials remain the core risk even in secretless designs. | |
| NHI-05 — Overprivileged NHI | The article links secretless design to zero standing privilege and scope reduction for machine identities. | |
| Recommendation — Scan secret stores and code paths for exposed NHI credentials and remove direct handling where possible. Replace long-lived NHI secrets with short-lived credentials and enforce expiry across machine access paths. Reduce machine identity scope so credentials cannot persist beyond the task they are meant to support. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Secret lifecycle management maps directly to credential issuance, rotation, and revocation controls. |
| Recommendation — Apply IA-5 to automate credential rotation and revoke stale authenticators for workloads and services. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The threat is long-lived machine credentials being reused for access and movement. |
| Recommendation — Map credential exposure paths to TA0006 and TA0008 and prioritise controls that shorten exploitability windows. | ||
| NIST Zero Trust (SP 800-207) | Principle of Least Privilege — Least Privilege | Zero Standing Privilege is a direct zero-trust application for ephemeral machine access. |
| Recommendation — Use least-privilege zero trust principles to ensure machine access is granted only when needed and only for the task. | ||
Key terms
- Secretless architecture: A secretless architecture is a model where applications and workloads authenticate with identity instead of handling reusable credentials directly. The secret may still exist in the system, but it is issued, used, and revoked behind the scenes so the workload never sees it.
- 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.
- Zero Standing Privilege: A control model in which an identity does not keep persistent access unless it is actively needed. For NHIs, this means credentials and permissions are issued for a narrow task and then removed. It reduces the time window and reuse value of stolen access.
- Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- How the article frames Akeyless Universal Identity and its role in abstracting machine trust
- The stepwise path from static secrets to rotating secrets and dynamic credentials
- Why SPIFFE still depends on backend secrets management for certificates and encryption keys
- How the article positions pricing, platform consolidation, and machine identity management in one model
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 August 17, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org