Single-use secret delivery is a pattern where a credential is exposed only once and then destroyed or expires immediately after use. It reduces copying, forwarding, and retention risk, but it still depends on strong recipient verification and a trustworthy control plane.
Expanded Definition
Single-use secret delivery is a short-lived credential distribution pattern used for an NHI, service account, or agent so the secret can be retrieved once, then revoked, expired, or cryptographically invalidated. Compared with static secret, it narrows the window for copying and replay, which is why it is often discussed alongside OWASP Non-Human Identity Top 10 guidance on secret handling and lifecycle control.
Definitions vary across vendors on whether “single-use” means one retrieval, one authentication, or one successful downstream action, so the control should be specified operationally rather than assumed. In mature NHI programs, it is typically paired with recipient attestation, audit logging, and rapid revocation paths, because a one-time token still fails if it is issued to the wrong workload or delivered through an untrusted channel.
The most common misapplication is treating single-use delivery as a substitute for identity verification, which occurs when teams focus on expiry mechanics while ignoring who or what actually received the secret.
Examples and Use Cases
Implementing single-use secret delivery rigorously often introduces delivery-friction and orchestration overhead, requiring organisations to weigh shorter exposure windows against extra validation, retry handling, and incident recovery complexity.
- A CI/CD job fetches a one-time deployment token from a vault, uses it for a single release step, and then invalidates it immediately to reduce persistence in build logs and runner memory. This pattern is especially relevant in cases like the CI/CD pipeline exploitation case study.
- An AI agent receives a one-time API key to call a downstream service during a bounded task, with the key tied to a specific workload identity and time limit rather than a reusable human handoff.
- A support engineer sends a one-time recovery secret to a verified automation endpoint instead of email, avoiding the retention and forwarding risk documented in Guide to the Secret Sprawl Challenge.
- A secrets manager issues a single-use credential for bootstrap access, then rotates the target account so the bootstrap secret cannot be reused after provisioning.
- For federated environments, organisations compare the pattern with guidance in OWASP Non-Human Identity Top 10 to ensure delivery controls do not bypass broader NHI governance.
Why It Matters in NHI Security
Single-use delivery reduces the damage caused when secrets leak through chat, ticketing, build output, or misconfigured storage, but it does not solve the underlying problem of excessive privilege or poor remediation. NHI Mgmt Group research shows that 91.6% of secrets remain valid five days after notification, which highlights how often organisations fail to remove access quickly enough after exposure.
That matters because secret sprawl is usually a systems issue, not a token-format issue. If delivery is single-use but the receiving workload is over-permissioned, mirrored in logs, or reachable by third parties, the exposure window is smaller but the blast radius remains large. Incidents described in the Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack show how quickly secrets can be harvested once delivery or storage is compromised.
Organisations typically encounter the consequences only after a token is replayed, a pipeline is poisoned, or a secret is found in a public artifact, at which point single-use delivery becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret lifecycle and delivery risks for non-human identities. |
| NIST CSF 2.0 | PR.AC-1 | Access is granted only to verified entities and limited use contexts. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification before and during access. |
Treat each secret request as a fresh trust decision and validate context before issuance.
