Runtime issuance is the safer default when the pipeline only needs a secret for the duration of a step. Persistent storage should be reserved for the small number of cases that genuinely require it, because every stored credential extends the time window in which misuse or leakage can occur.
Why runtime issuance is the safer default for pipeline secrets
runtime issuance reduces how long a secret exists in a reusable form, which matters because most pipeline exposure is about time and reach, not just storage location. If a job can request a secret only when it needs it, the credential has a shorter attack window, fewer chances to leak into logs or artifacts, and less value if the pipeline or runner is later compromised.
That makes the control decision practical rather than ideological. Long-lived secrets are sometimes unavoidable, but they should be treated as an exception that needs a clear business reason, a bounded lifetime, and explicit ownership. For normal build and deployment steps, ephemeral access is usually easier to justify and easier to retire cleanly.
For teams working through secrets sprawl and rotation design, Secrets Management Guide is a useful baseline for moving from stored credentials toward secretless patterns and dynamic issuance.
What changes in Azure DevOps when the secret is only needed briefly?
When Azure DevOps jobs use runtime issuance, the pipeline shifts from “retrieve and keep” to “request, use, discard.” That changes the operational model in three ways. First, access is tied to a specific execution context, so compromise of one run does not automatically expose a standing credential. Second, rotation becomes less about manual replacement and more about trust policy, token expiry, and identity federation. Third, storage risk drops because the pipeline no longer needs to persist the secret across runs just to remain functional.
The design works best when the secret is truly step-scoped, such as an API call, a deploy action, or a one-time connection to a downstream service. It is weaker when teams use the phrase “temporary” but still cache the credential across stages, agents, or environments. In those cases, the control may look dynamic while behaving like a long-lived secret in practice.
For the underlying credential model, NHI Authentication Guide explains the main runtime authentication patterns, including workload identity federation, mTLS, client credentials, and certificate-based approaches.
For teams comparing static and dynamic secret patterns, Ultimate Guide to NHIs, Static vs Dynamic Secrets is a good conceptual anchor for why ephemeral credentials usually lower exposure.
When long-lived secrets still make sense, and how to contain the risk
Persistent storage is not automatically wrong, but it should be reserved for cases where runtime issuance is genuinely unavailable or operationally disproportionate. Common examples include legacy systems that cannot federate, third-party services that only accept a fixed API key, or short-term transition states while a platform is being modernised. The decision point is whether the pipeline can prove a need for continuity that outlives a single run.
When a long-lived secret is unavoidable, the important question becomes how quickly misuse would be noticed and how far the credential can reach. Scope, environment separation, rotation cadence, and revocation readiness matter more than the storage mechanism itself. A secret with broad privileges and no expiry is a much larger problem than a narrowly scoped credential that is monitored and rotated on a disciplined schedule.
For rotation-specific trade-offs and lifecycle constraints, Guide to NHI Rotation Challenges helps teams think through expiry, dependency mapping, and automated replacement without creating outages.
For the cloud control perspective, CSA Cloud Controls Matrix is a useful external reference for cloud IAM and access governance expectations that shape secret handling in hosted delivery environments.
For pipeline and build-chain abuse patterns, CI/CD pipeline exploitation case study shows how exposed credentials can turn a build path into a control-plane compromise.
Risk and Threat Considerations
Long-lived pipeline secrets expand the blast radius of any single leak, because the same credential may remain usable long after the job that needed it has finished. That creates exposure through logs, cached environment variables, developer workstations, misconfigured runners, and any later compromise of the build system itself.
Failure mechanism: A stored secret survives beyond the execution step, is copied into places it was never meant to reach, or is reused so widely that one exposure becomes repeated access. Attackers often prefer these paths because they can wait, reuse, and move laterally without needing to break the pipeline again.
Impact: A leaked long-lived credential can enable unauthorized deployments, source retrieval, environment pivoting, or downstream service abuse until the secret is found and revoked. The longer the credential remains valid, the harder it is to separate legitimate use from compromise.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CSA Cloud Controls Matrix, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Directly addresses the risk of persistent credentials in pipelines. |
| NHI-02 — Secret Leakage | Pipeline secrets can leak through logs, artifacts, caches, and runner state. | |
| NHI-05 — Overprivileged NHI | Stored pipeline secrets often have broader access than the step needs. | |
| Recommendation — Replace standing secrets with short-lived credentials wherever the workflow allows. Scan pipeline paths that can expose secrets and remove unnecessary secret persistence. Scope each pipeline credential to the minimum permissions required for the task. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Applies to machine-to-machine and workload authentication for runtime-issued credentials. |
| IA-5 — Authenticator Management | Covers creation, storage, rotation, and revocation of secrets and tokens. | |
| Recommendation — Use service-to-service authentication methods that avoid shared standing secrets. Establish strict lifecycle handling for any credential that must remain stored. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud IAM governs how pipeline identities obtain and constrain access to secrets. |
| Recommendation — Bind pipeline access to managed identities and enforce least privilege in cloud controls. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Relevant when runtime issuance uses federated token flows instead of shared secrets. |
| Recommendation — Prefer federated token-based flows over reusable shared credentials for pipelines. | ||
| CIS Controls v8 | CIS-5 — Account Management | Secret lifecycle and access scope depend on disciplined account and credential management. |
| Recommendation — Inventory pipeline accounts and remove any standing credentials that are no longer needed. | ||
Practitioner Guidance
What to prioritise: Treat runtime issuance as the default control and force teams to justify any credential that must persist beyond one job or one environment boundary. If the secret can authenticate to production, give the credential owner a specific expiry, revocation path, and monitoring expectation before it is approved.
What to verify: Check whether the pipeline truly needs a reusable secret or merely needs a short-lived token, federated assertion, or signed exchange for one step. Also verify that the “temporary” secret is not being copied into cache, variable groups, release artifacts, or self-hosted runner state.
Practitioner takeaway: The key decision is not whether a secret is stored in Azure DevOps, but whether the pipeline can avoid creating a credential that outlives the execution context that justified it.
Related resources from NHI Mgmt Group
- How should security teams handle Azure workload identity federation across multiple clouds without relying on long-lived secrets?
- What is the difference between runtime issuance and long-lived secrets for agents?
- What should security teams do about secrets hidden in SharePoint?
- How should teams handle secrets that have no obvious owner?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org