Secrets management best practices for dynamic, cloud-native access

At a glance

What this is: This guide argues that modern secrets management must replace static credentials with dynamic, automated, runtime-controlled access patterns.

Why it matters: It matters because IAM, PAM, and NHI programmes now have to govern machine access at application speed, not human review speed, or exposure windows stay open too long.

By the numbers:

• 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.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• 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.

👉 Read Infisical's guide to secrets management best practices

Context

Modern secrets management is the discipline of generating, distributing, rotating, and revoking credentials so applications can authenticate without exposing long-lived secrets. The problem is that many organisations still manage machine credentials as if they were static passwords, even though modern systems exchange secrets continuously across microservices, pipelines, and containers.

That gap is now an identity governance problem as much as a security problem. NHI controls, workload identity, and access lifecycle processes have to operate at runtime, because exposed API keys, certificates, and tokens can outlive the operational moment that created them.

Key questions

Q: How should security teams reduce exposure from long-lived application secrets?

A: Start by identifying where secrets are reused across workloads, then replace the highest-risk ones with dynamic credentials that expire automatically. The goal is to make each credential useful for one workload, one task, or one session only. That reduces blast radius and makes leaked values far less reusable.

Q: When does secrets rotation stop being enough?

A: Rotation stops being enough when the same credential model remains in place and only the clock changes. If secrets are still long-lived between rotations, exposure windows remain open and leaked values can stay valid for days or weeks. Dynamic generation and automated revocation address that structural problem more directly.

Q: What do organisations get wrong about secrets management in CI/CD pipelines?

A: They often assume that putting secrets into a pipeline is safe if the values are encrypted or stored in a vault. The real risk is exposure during build, deploy, and logging steps. Secrets should be injected at runtime, scoped tightly, and removed automatically when the pipeline or environment ends.

Q: How do you know if secrets governance is actually working?

A: Look for fewer static credentials, faster revocation after discovery, and clear ownership for every active secret. If teams still rely on manual steps, cannot explain where credentials live, or keep finding secrets in code and collaboration tools, the programme is controlling storage but not governing identity.

Technical breakdown

Dynamic secrets versus static credential rotation

Static rotation replaces one long-lived secret with another, which still leaves a window where compromise remains useful. Dynamic secrets change the model entirely by generating unique, short-lived credentials on demand, usually scoped to a single request, session, or task. That pattern reduces reuse, limits blast radius, and gives teams a clean audit trail for each credential instance. In practice, the value is not just shorter TTLs. It is eliminating the assumption that a credential should exist before the workload needs it and remain valid after the workload is done.

Practical implication: move high-risk workloads from scheduled rotation to on-demand credential issuance with automatic expiry.

Runtime secret injection and human removal from the loop

When a human sees a secret, it can be copied, logged, phished, or pasted into the wrong place. Runtime injection avoids that by letting applications fetch secrets programmatically or receive them through orchestration systems without exposing the value in code, tickets, or chat. For administrators, session brokering and proxied access reduce direct credential exposure while keeping the operational path intact. This is a control design choice, not just a delivery method. The goal is to keep the secret inside the machine-to-machine trust boundary and out of human sight.

Practical implication: use runtime retrieval and brokering patterns so operators never handle production secret values directly.

Cloud-agnostic authentication and secrets lifecycle automation

Modern applications rarely live in one cloud, so secrets systems need portable authentication and automated lifecycle handling. OIDC, cloud-native workload identity, and policy-driven secret metadata let teams centralise control while supporting AWS, Azure, GCP, on-premise, and edge deployments. Lifecycle automation matters just as much: provisioning, distribution, rotation, and destruction need to be tied to service creation and decommissioning events. Without that, orphaned credentials remain active long after the workload they support has changed or disappeared.

Practical implication: tie secret creation and revocation to workload lifecycle events, not calendar-only rotation schedules.

NHI Mgmt Group analysis

Static secret thinking is the control failure modern application estates expose most clearly. The guide describes an environment where tokens, certificates, and API keys are created and consumed continuously, yet many programmes still treat them like durable passwords. That mindset creates a mismatch between credential lifetime and application velocity. The practical conclusion is that modern secrets governance has to be built around runtime behaviour, not storage alone.

Secret exposure is now a lifecycle problem, not just a leakage problem. Detection matters, but it does not end the risk if valid secrets remain usable for weeks after discovery. The governance gap is persistence after exposure, because a leaked secret with standing value still behaves like an active identity. Practitioners should read that as a lifecycle failure across creation, use, and revocation, not a one-time incident.

Runtime injection is the operational expression of least privilege for non-human identities. The article’s strongest idea is that credentials should be available only when a workload needs them and only in the form that workload can consume. That aligns with OWASP-NHI and Zero Trust thinking because the identity is authenticated at use time, not stocked in advance. The implication is that access governance must move closer to execution.

Ephemeral credential trust debt: short-lived secrets reduce exposure windows, but they also increase the number of moving parts that must authenticate, rotate, and revoke correctly. If automation is incomplete, teams inherit hidden operational debt in the form of stale policies, orphaned access paths, and inconsistent secret state. The conclusion for practitioners is simple: if you adopt dynamism, governance has to become equally dynamic.

Secrets management is converging with workload identity and broader identity lifecycle governance. Once secrets are generated, injected, and revoked automatically, the boundary between secret management, NHI governance, and access lifecycle gets thinner. That is where identity teams should focus their programme design: the same control plane has to understand service creation, policy enforcement, and offboarding. The practitioner takeaway is to govern secret state as part of the identity programme, not as a separate vault problem.

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.
• From our research: 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• The governance lesson is to pair runtime controls with lifecycle control, because exposure that persists after discovery is still active risk.

What this signals

Ephemeral credential trust debt: organisations that adopt dynamic secrets without mature revocation, ownership, and service offboarding processes simply move the problem downstream. The next control failure is usually not credential creation, but stale state that survives environment changes and leaves access open longer than intended.

The practical watchpoint for IAM and NHI teams is integration depth. If secret issuance is tied into workload identity, CI/CD, and decommission workflows, the programme can finally govern machine access at the speed of deployment. If not, secret sprawl will keep outpacing manual review cycles.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, the wider lesson is that secret handling is expanding beyond code repositories and into the orchestration layer. Teams should expect secrets governance to become a platform issue, not just an application-security task.

For practitioners

• Inventory static credentials by workload criticality Classify API keys, certificates, and database passwords by business impact, then target the credentials that sit in production paths, CI/CD systems, and shared services first. Link that inventory to owners and service lifecycle state so orphaned secrets are visible before they become incidents.
• Replace long-lived credentials with dynamic issuance Use on-demand secret generation for databases, SSH, and API access where the workload can authenticate through a trusted identity provider. Keep credentials unique per session or task and enforce automatic expiry so compromise has a short usable window.
• Move secret delivery into runtime controls Fetch secrets programmatically at execution time through SDKs, orchestration, or managed injection rather than storing values in code, logs, or tickets. For administrators, route access through brokering or proxy patterns so the underlying secret is never disclosed.
• Automate revocation at decommission time Trigger cleanup when services, pipelines, or environments are retired so associated secrets are revoked and deleted immediately. Treat offboarding as a security event, not a maintenance task, because dormant credentials are still active identities until removed.

Key takeaways

• Modern secrets management fails when it is treated as static password handling instead of runtime identity governance.
• The evidence points to a persistent exposure problem, not just a discovery problem, because leaked secrets often remain usable long after they are found.
• Practitioners should prioritise dynamic issuance, runtime injection, and automated revocation tied to workload lifecycle events.

Key terms

• Dynamic Secret: A dynamic secret is a credential generated on demand for a specific workload, session, or task instead of being stored long term. It reduces reuse and exposure because the value can expire automatically after use, which is especially important for machine identities that operate continuously.
• Secret Lifecycle: Secret lifecycle is the full sequence of creation, distribution, use, rotation, and destruction for credentials and tokens. In modern identity programmes, lifecycle control matters because a secret that is not revoked when a workload ends remains an active identity even if nobody is using it.
• Runtime Injection: Runtime injection is the practice of delivering secrets to an application at execution time without exposing the underlying value to developers, logs, or configuration files. It keeps credentials inside the machine-to-machine trust boundary and reduces the chance of accidental disclosure.
• Standing Credential: A standing credential is a long-lived secret that remains usable outside the immediate task that needs it. It creates a wider exposure window than just-in-time access because compromise at any point in its life can be reused until the credential is rotated or revoked.

What's in the full article

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

• Step-by-step implementation guidance for dynamic database credentials, API tokens, and SSH certificates.
• Practical examples for injecting secrets into applications, orchestration layers, and CI/CD pipelines without exposing values.
• A phased roadmap for assessment, core implementation, advanced automation, and scaling across environments.
• Developer workflow guidance that shows how teams can reduce friction while tightening secret control.

👉 Infisical's full post covers the implementation roadmap, developer workflow patterns, and measurement approach.

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 responsible for identity security strategy or programme maturity, it is worth exploring.