Secretless architecture still depends on governed secret lifecycles

At a glance

What this is: This is an analysis of secretless architecture and its finding that secrets cannot be eliminated, only abstracted into better-governed lifecycles.

Why it matters: It matters because IAM and NHI programmes still have to govern machine credentials, rotation, and privilege boundaries even when applications no longer handle static secrets directly.

By the numbers:

• There are over 50 machine identities for every human identity today, and many still rely on secrets for access and authorization.
• 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.
• Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read Akeyless' analysis of secretless architecture and machine identity governance

Context

Secretless architecture is not the same as secret-free architecture. In practice, it reduces direct handling of API keys, passwords, and certificates by shifting authentication into dynamic credentials, workload identity, and managed token lifecycles.

The governance problem is that the underlying identity estate does not disappear. Machine identities still need issuance, rotation, revocation, and access boundaries, and those controls have to work across workloads, microservices, applications, and human operators.

For IAM and NHI teams, the key question is not whether secrets exist, but where they are exposed and how quickly their useful lifetime can be constrained. That is the real operating model change, and it is typical of modern hybrid environments.

Key questions

Q: How should security teams implement secretless architecture without losing control of machine access?

A: Start by identifying every identity primitive that still exists underneath the abstraction, including certificates, tokens, and workload identities. Then remove standing privilege, shorten credential lifetime, and automate revocation so the hidden trust layer is governed as tightly as the old secret store.

Q: Why do secretless designs still require strong NHI governance?

A: Because secretless removes direct handling, not the need to issue, validate, rotate, and revoke machine credentials. If those lifecycle controls are weak, the organisation has only hidden the secret, not reduced the risk created by its exposure or misuse.

Q: What breaks when teams assume secretless means secret-free?

A: Governance breaks first, because teams stop tracking the underlying trust primitives that workloads still depend on. That leads to blind spots in revocation, privilege scope, and accountability when a workload identity is abused or a token is replayed.

Q: Who is accountable for machine credentials in a secretless model?

A: Accountability sits with the teams that own identity issuance, runtime access policy, and revocation, not with application developers alone. If a workload can mint or inherit access, the owning IAM, platform, and security functions must define the lifecycle and the control boundaries.

Technical breakdown

Static secrets versus dynamic credentials

Static secrets such as API keys, passwords, and certificates create long-lived authentication artifacts that can be copied, logged, embedded in code, or reused after compromise. Dynamic credentials change the model by issuing short-lived access that is bound to a task, session, or workload identity. That reduces exposure but does not remove the need for identity proof, lifecycle control, and revocation. The architecture still depends on a trusted system that can mint, validate, and retire credentials correctly across distributed environments.

Practical implication: treat dynamic credentials as a control improvement, not a reason to relax lifecycle governance.

Zero standing privilege for machine identities

Zero Standing Privilege means no persistent credentials or pre-existing access remain available for later abuse. For machine identities, that usually means generating ephemeral access only when the workload needs it, then expiring it automatically after the task completes. This changes the blast radius of compromise, because stolen credentials have less time and less privilege to be useful. It also shifts the burden onto provisioning, policy enforcement, and revocation timing rather than manual secret storage.

Practical implication: align machine identity design with ephemeral access patterns rather than permanent service credentials.

Why secretless still depends on secrets infrastructure

Secretless systems still rely on cryptographic trust anchors such as keys, certificates, and tokens under the hood. Protocols like SPIFFE and OIDC can hide direct secret handling from applications, but they do not eliminate the identity systems that issue and validate trust. That means secretless is a user and developer experience model as much as a security model. The hidden governance layer becomes more important, not less, because failures in it can cascade across every dependent workload.

Practical implication: secure the issuing and validation layer with the same discipline you once applied to the secret itself.

Threat narrative

Attacker objective: The attacker aims to turn exposed machine credentials into durable access that can be reused across workloads and services.

1. Entry occurs when static credentials are embedded in code, configuration files, logs, or repositories and become reachable to an attacker.
2. Escalation occurs when those credentials remain valid long enough for reuse, letting the attacker impersonate a workload or service account.
3. Impact occurs when the compromised identity is used to access connected systems, extract data, or move laterally across machine-to-machine trust relationships.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secretless does not remove the governance burden, it relocates it. The security problem moves from developer-visible secrets to the issuance, binding, and retirement of machine trust primitives. That matters because the most important control is no longer where the secret sits, but whether the credential lifecycle is consistently governed across every workload that can request access.

Dynamic credentials reduce exposure windows, but they do not solve privilege design. A short-lived token still becomes dangerous if it can reach too many systems, too quickly, or with too much inherited authority. The relevant discipline is least privilege across machine identities, not just shorter token duration.

Secret sprawl is now an infrastructure design problem, not just a code hygiene problem. Secrets appear in pipelines, logs, collaboration tools, and cloud services because identity is now distributed across runtime systems. That makes lifecycle control, detection, and offboarding part of the same operational problem, and practitioners should treat secretless architecture as a governance architecture.

Zero Standing Privilege is the right destination for high-risk machine access, but only if the organisation can operationalise it at runtime. Standing access is still the default failure mode in many environments because service accounts and workload identities are designed for convenience first. The practitioner conclusion is that secretless only delivers if standing privilege is removed from the underlying machine identity model.

Identity blast radius: the real unit of risk in secretless systems is how far one credential can travel before it expires or is revoked. That concept becomes more useful than the older question of whether a secret exists at all. For IAM, PAM, and NHI teams, the practical focus is how much damage a single compromised credential can still do inside a trusted machine-to-machine path.

From our research:

• 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.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, which is why exposure management must be paired with revocation.
• Guide to the Secret Sprawl Challenge helps practitioners move from detection to lifecycle control and revocation discipline.

What this signals

Secretless adoption will keep expanding the attack surface for governance teams if they treat abstraction as remediation. The better model is to measure whether workload identities, certificate lifecycles, and ephemeral credentials are actually reducing privilege persistence. If they are not, the programme has only moved the problem deeper into the stack.

Identity blast radius is the right forward-looking metric for machine access programmes. Instead of asking whether a secret exists, measure how far a compromised credential can travel before expiry or revocation. That framing aligns IAM, PAM, and cloud security teams around containment rather than inventory.

The next maturity step is cross-domain governance that links secret detection, workload identity, and runtime access review into a single control plane. When those functions stay separate, secretless architecture becomes a branding term rather than an operating model.

For practitioners

• Map every secretless trust path back to its underlying identity primitive Document which workloads rely on certificates, tokens, or workload identities and identify who or what issues them, validates them, and revokes them. Use that map to find hidden persistence points in pipelines, sidecars, and orchestration layers.
• Eliminate standing machine privilege where sessions can be made ephemeral Convert always-on service access to task-scoped issuance, then enforce expiry at the end of the job or session. Prioritise systems with broad lateral access, especially shared infrastructure accounts and high-value API integrations.
• Treat secret detection and revocation as a coupled control Detection alone does not reduce exposure if a leaked credential remains valid. Build automated revocation and replacement flows so exposed secrets are invalidated before attackers can reuse them.
• Extend NHI governance into pipelines and collaboration tools Search beyond source code for credentials in Slack, Jira, Confluence, build logs, and ticketing data. Those locations often escape traditional secret scanners and can create more critical exposure than code-based leaks.
• Use SPIFFE and OIDC to reduce direct secret handling, not to bypass governance If workloads rely on SPIFFE or OIDC-based trust, validate the certificate, token, and key lifecycle underneath those abstractions. The control objective is still governed identity, only the interface has changed.

Key takeaways

• Secretless architecture reduces direct secret handling, but it does not remove the need to govern the underlying machine identities that still issue and consume trust.
• The scale of secret exposure remains large, with tens of millions of hardcoded secrets still appearing in public code and many leaked credentials remaining valid after discovery.
• Practitioners should focus on identity lifecycle, ephemeral access, and automated revocation, because those controls determine whether secretless is a real security change or only an abstraction layer.

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.
• 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.
• 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.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

Akeyless' full blog covers the operational detail this post intentionally leaves for the source:

• The practical breakdown of static secrets, rotating secrets, and Zero Standing Privilege as implementation patterns.
• The vendor's explanation of how SPIFFE, OIDC, and Universal Identity fit into a secretless architecture.
• The pricing and platform-model details that are only relevant once an organisation is evaluating a specific deployment path.
• The product-level architecture choices for managing certificates, encryption keys, and dynamic credentials at scale.

👉 Akeyless' full post covers the path from static secrets to dynamic identity and Zero Standing Privilege.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 or NHI governance programme, it is worth exploring.