Secrets management and JIT access are reshaping identity controls

At a glance

What this is: This is an independent analysis of why modern secrets management is moving toward ephemeral, policy-based access and what that changes for identity governance.

Why it matters: It matters because IAM, PAM, NHI, and cloud teams have to govern the same credential patterns across people, workloads, and pipeline automation without relying on standing access.

By the numbers:

• Only 44% of organisations are currently using a dedicated secrets management system.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read SSH Communications Security's analysis of secrets management and JIT access

Context

Secrets are not just stored values, they are the credentials that let humans, workloads, scripts, and services prove who they are to a system. The governance problem is that these credentials are often created faster than they are discovered, classified, and retired, especially in cloud and DevOps environments where access is distributed across multiple teams.

In that environment, static credentials become an identity control problem, not just a vaulting problem. When secrets are embedded in code, shared across pipelines, or left standing after a task ends, the result is invisible privilege that can outlive the business need it was meant to support.

Key questions

Q: How should security teams reduce the risk of standing secrets in cloud and DevOps environments?

A: Start by inventorying where secrets are issued, stored, copied, and reused across pipelines, workloads, and admin access. Then replace the highest-risk standing credentials with short-lived issuance, bind access to policy and task scope, and make revocation part of the same workflow so exposure does not outlive the business need.

Q: Why do static secrets increase lateral movement risk?

A: Static secrets remain valid after they are exposed, which means one leak can be reused across multiple systems if the credential is accepted broadly. That is especially dangerous when the secret is linked to privileged accounts or cloud services, because the attacker can pivot without needing a second compromise.

Q: What breaks when secrets are vaulted but downstream privileges stay standing?

A: The vault protects storage, but it does not remove the access paths that a valid secret unlocks. If entitlements remain broad, a compromised credential can still reach sensitive systems, move laterally, or be reused by an attacker until the privilege layer is corrected.

Q: Which controls should be evaluated together for secrets governance?

A: Secrets management, PAM, and CIEM need to be evaluated as one control set because issuance, privilege, and revocation are linked. A secret that is issued safely can still create major exposure if the identity behind it is over-permissioned or if revocation does not happen quickly enough.

Technical breakdown

Static secrets versus ephemeral certificates

Static secrets such as passwords, API keys, and long-lived tokens stay valid until someone changes them, which makes them easy to reuse after exposure. Ephemeral certificates and task-scoped tokens change that model by limiting validity to a session or a narrowly defined action. The architectural difference matters because the attacker value of a leaked secret drops sharply when the secret expires automatically and cannot be reused across workflows.

Practical implication: replace any standing secret that can be issued on demand with a short-lived credential model tied to task scope.

JIT secret provisioning in DevOps and hybrid environments

Just-in-time secret provisioning issues credentials only when a workflow, user, or workload actually needs them. In practice, that means the secret is bound to policy, time, and context instead of being pre-positioned for future use. This is especially important in CI/CD pipelines and hybrid estates, where the same credential may otherwise be copied into automation, service layers, and admin access paths, widening the blast radius when it leaks.

Practical implication: enforce policy-driven issuance for pipelines and remote administration so credentials are never available outside an approved task window.

Secrets governance with PAM and CIEM

Secrets management does not end at storage, because entitlement and privilege determine whether a secret can reach sensitive systems once it is issued. PAM reduces the damage from elevated access, while CIEM exposes where identities are over-permissioned across cloud services. When these controls are separated, organisations can vault secrets but still leave the downstream privileges intact, which preserves lateral-movement paths after compromise.

Practical implication: review secrets alongside entitlements so issuance, privilege, and revocation are governed as one control plane.

Threat narrative

Attacker objective: The attacker wants reusable authentication material that turns a single exposure into broad, persistent access across cloud and enterprise systems.

1. Entry begins when attackers obtain an unmanaged secret from code, a pipeline, or another exposed location, giving them valid authentication material without breaking the underlying system.
2. Escalation follows when that secret is reused to access broader services, especially where standing privilege or weak scoping lets one credential open multiple paths.
3. Impact occurs when the compromised secret is used to move laterally, access sensitive systems, or maintain undetected access long after the original leak is discovered.

Breaches seen in the wild

• Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

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

NHI Mgmt Group analysis

Static secret governance is now an identity risk problem, not a storage problem. Secrets only become defensible when their validity window, privilege scope, and revocation path are governed together. A vault alone does not remove the exposure created by credentials that remain valid long after the task that created them has ended. The implication is that security teams should treat secret lifetime as part of identity design, not as an afterthought.

Ephemeral access changes the economics of compromise, but only if revocation is real. Short-lived credentials reduce reuse value, yet leaked secrets that remain valid for days or weeks still create material exposure. The operational question is not whether a credential was issued securely, but whether it can be rendered useless fast enough to stop lateral movement. Practitioners should therefore measure exposure persistence, not just secret count.

Secret sprawl is the named concept this category needs. It describes the condition where secrets exist across code, pipelines, tickets, and cloud services faster than governance can centralise them. That sprawl breaks the assumption that secret ownership is knowable at the point of issuance, which is why review-based controls often arrive too late. The implication is that identity programmes need to govern discovery, scope, and retirement as one lifecycle.

JIT provisioning only works when the surrounding control plane is equally dynamic. A short-lived credential inside a long-lived entitlement model still leaves excessive reach once the secret is accepted by target systems. That is why PAM, CIEM, and secrets management have to be aligned across human and machine identities. The implication is that access policy must move at the same speed as credential issuance.

Human and machine access now fail for the same reason when standing credentials persist. The governance pattern is shared even when the actor differs: once a credential can be copied, reused, or silently inherited, accountability weakens across both workforce and workload access. That makes secrets management a cross-domain control, not a niche infrastructure function. Practitioners should align secret governance with the broader identity lifecycle.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• 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.
• Track the exposure path in Guide to the Secret Sprawl Challenge so discovery, scoping, and revocation are treated as one operational loop.

What this signals

Secret sprawl is becoming a governance signal, not just an operational nuisance. When credentials spread across code, chat, ticketing, and infrastructure tools, the control problem shifts from inventory to lifecycle enforcement. Teams that rely on periodic reviews will keep finding that the secret has already moved on before the review cycle starts.

The next maturity step is to measure exposure persistence across the full secret lifecycle, from creation to revocation. That means tying secrets management to PAM, CIEM, and identity lifecycle processes so a credential cannot survive longer than the access case that justified it.

For practitioners, the immediate signal is whether your programme can tell the difference between a secret that is stored safely and a secret that is still actionable. If it cannot, then your security model is describing the vault, not the risk.

For practitioners

• Inventory every standing secret path Map where passwords, API keys, certificates, and tokens live across code, CI/CD, vaults, and cloud services, then assign an owner to each secret class. Use that inventory to identify any credential that remains valid after the task or session has ended.
• Convert long-lived credentials to task-scoped issuance Prioritise the secrets that unlock privileged systems or automation first, then replace them with ephemeral certificates or short-lived tokens that expire automatically when the job completes. This reduces the reusable value of a leaked credential.
• Tie secrets governance to PAM and CIEM Review whether each issued secret can reach more systems than the task requires, and remove downstream entitlements that make one credential useful across multiple cloud services. The control objective is to shrink the blast radius after compromise.
• Measure revocation speed, not just rotation volume Track how long a leaked secret remains usable after discovery, then compare that time against your highest-risk systems. A fast rotation programme still fails if revocation lags and valid secrets continue to authenticate.

Key takeaways

• Secrets management is an identity governance issue because leaked credentials only become safe when their lifetime, scope, and revocation are controlled together.
• Exposure remains dangerous after discovery if the credential is still valid, which makes automated revocation more important than detection alone.
• Practitioners should govern secrets, PAM, and CIEM as one control plane so a single leaked secret cannot become broad, persistent access.

Key terms

• Standing Credential: A standing credential is a secret that remains valid until someone manually changes or revokes it. In practice, that creates reusable access that can survive beyond the original task, making it a high-value target in cloud, DevOps, and privileged access environments.
• Ephemeral Certificate: An ephemeral certificate is a short-lived credential issued for a specific session or task and automatically expires when that purpose ends. For autonomous or automated workflows, the short lifetime is only useful if the certificate cannot be reused or silently extended.
• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials across code, tools, pipelines, tickets, and cloud services. The problem is not just volume, but loss of ownership, visibility, and retirement discipline, which makes leaked secrets hard to find and even harder to invalidate.
• Cloud Infrastructure Entitlement Management: Cloud Infrastructure Entitlement Management is the practice of discovering and right-sizing permissions across cloud identities and services. For secrets governance, it shows whether a valid credential can actually reach more systems than the task requires, which is where lateral movement risk is created.

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 NHI governance in your organisation, it is worth exploring.

This post draws on content published by SSH Communications Security: secrets management, JIT provisioning, and CIEM integration in the PrivX portfolio. Read the original.