When should teams replace long-lived CI/CD secrets with short-lived tokens?

When short-lived tokens are the better default for CI/CD access

Replace long-lived CI/CD secrets when the pipeline only needs access for a bounded job, such as a build, deploy, or publish step, and that access can be minted on demand. In those cases, the token should expire as soon as the job ends, so a compromised runner or leaked environment variable does not remain a reusable entry point.

The practical question is not whether a pipeline can authenticate, but whether it needs standing reusable material at all. If the workflow can use ephemeral credentials, that usually aligns better with least privilege and short-lived trust than a static secret that sits in a repository setting, environment variable, or runner context for months.

Short-lived tokens are especially strong for release pipelines, infrastructure changes, and cloud deployment steps because those are high-impact actions with a narrow legitimate window. For that reason, the CI/CD Pipeline Identity Security Guide and Secrets Management Guide both point toward ephemeral access and away from secrets that outlive the job that needs them.

What changes when the credential only lives for the job

A short-lived token changes the blast radius. If a runner image, build log, dependency, or injected script is compromised, the attacker gets a token that is time-bound and usually audience-bound, rather than a secret that can be reused repeatedly across future runs. That matters most when the same pipeline touches production deployment systems, cloud control planes, artifact registries, or signing services.

It also changes how teams think about rotation. Long-lived CI/CD secrets force periodic cleanup and revocation work, while ephemeral tokens shift the control point to issuance policy, trust conditions, and token scope. In practice, that means the security property comes from the token being short-lived and narrowly scoped, not from expiry alone. The RFC 9700: Best Current Practice for OAuth 2.0 Security and RFC 9449: OAuth 2.0 Demonstrating Proof of Possession are useful reference points for reducing replay value and constraining stolen tokens.

There is also an operational boundary to respect. If the job genuinely needs broad, persistent access, short-lived tokens are not a magic fix, because the authorization model may still be too generous. In that case, the better move is to reduce scope first, then issue the token only for the minimum required window and target.

Where long-lived secrets still show up, and why they are the wrong fit

Long-lived CI/CD secrets tend to persist because they are easy to wire into older jobs, third-party integrations, or scripts that were never redesigned for ephemeral auth. They are also common when teams use the same credential across many repositories, environments, or deploy targets. That convenience creates reuse risk: one leak can expose more than one pipeline, and one compromise can remain useful long after the original job has finished.

That is why internal guidance on secret sprawl and static versus dynamic secrets is relevant here. The more a credential is copied, cached, or reused, the harder it becomes to contain exposure, prove ownership, and rotate safely without breaking deployments.

Teams should also be cautious when a “secret” is actually being used as a standing machine credential for a cloud or deployment system. In those cases, API key lifecycle thinking helps, but the better architecture is often to eliminate the standing secret entirely and replace it with a token minted per job or exchange flow.

Risk and Threat Considerations

Long-lived CI/CD secrets create a durable target for attackers because they remain useful after initial theft. If a build runner is compromised, or a secret is exposed in logs, artifacts, or environment variables, the attacker may be able to replay the credential across later jobs or from another system entirely. The risk grows when the same credential can reach production systems, artifact registries, or cloud APIs.

Failure mechanism: A standing secret is copied into build infrastructure, where it can be harvested from configuration, logs, memory, or mis-scoped environment variables, then reused outside the intended job window.

Impact: The compromise can turn one pipeline event into repeated unauthorized access, deployment tampering, secret exfiltration, or supply-chain abuse, especially when the credential has broad or cross-environment reach.

Practitioner Guidance

What to verify: Confirm whether each CI/CD credential is used for a single job, a single target, and a single trust path. If it is being reused across repositories, environments, or deploy stages, treat it as a migration candidate rather than an acceptable default.

Decision rule: If the pipeline can obtain access through a job-scoped, audience-scoped, expiring token, prefer that path. Keep long-lived secrets only where no equivalent short-lived issuance or federation path exists yet, and document the exception with a retirement date.

What good looks like: The pipeline can deploy, publish, or provision without storing reusable secrets in the runner longer than the job itself, and compromise of one run does not automatically grant future access.

Practitioner takeaway: The right cutoff is usually not “can we protect the secret?” but “should this workflow have a reusable secret at all?”, because eliminating standing value is the cleanest way to reduce blast radius.

Related resources from NHI Mgmt Group

• What do security teams get wrong about short-lived OIDC tokens in CI/CD?
• Why do long-lived authentication tokens create more risk in CI/CD systems than short-lived credentials?
• Why do long-lived secrets create more NHI risk than short-lived federated tokens?
• What should security teams do about short-lived CI/CD workloads?