Should organisations prioritise runtime secret retrieval over manual cleanup?

Yes. Runtime retrieval reduces the number of durable secret copies and prevents teams from depending on post-hoc cleanup after exposure has already occurred. Manual cleanup is reactive and incomplete, especially when builders are using multiple tools and machines. The better control is to keep the secret out of the code path from the start.

Why This Matters for Security Teams

runtime secret retrieval changes the security model from “find and clean up later” to “limit exposure before it happens.” That matters because manual cleanup assumes every secret copy is known, reachable, and removable, which is rarely true once credentials have been pasted into code, CI jobs, chat tools, or local shells. NHIs Mgmt Group research on the Guide to the Secret Sprawl Challenge shows how quickly secrets spread beyond intended control points, especially in fast-moving delivery pipelines.

The operational risk is not just leakage. Static secrets create durable access paths that survive the original task, the original user, and often the original machine. That is why guidance from the OWASP Non-Human Identity Top 10 aligns so closely with runtime retrieval: reduce secret lifetime, reduce secret copies, and reduce the window in which compromise matters. In practice, many security teams encounter the breach after the secret has already been reused elsewhere, rather than through intentional exposure testing.

How It Works in Practice

Runtime retrieval means the application, pipeline, or automation agent requests a secret only when it needs it, receives a short-lived value, uses it, and then lets it expire or be revoked. The secret is fetched from a trusted broker or secrets manager at execution time instead of being embedded in source code, copied into tickets, or stored on developer laptops. This is a better fit for modern NHI governance because the control point moves to the moment of use, not the aftermath of cleanup.

Practically, teams usually combine four controls:

• Short TTLs so leaked secrets expire quickly.
• Workload identity so the requester proves what it is, not who last handled it.
• Policy-based issuance so retrieval is allowed only for approved tasks and contexts.
• Automatic revocation so completion, failure, or timeout closes the access path.

This model is consistent with the direction of Ultimate Guide to NHIs — Static vs Dynamic Secrets, which distinguishes durable credentials from ephemeral ones. It also fits broader NHI lifecycle guidance in the same Ultimate Guide to NHIs, where rotation, visibility, and offboarding are treated as continuous controls rather than one-time remediation. For implementation patterns, current guidance suggests aligning secret retrieval with principles in the OWASP Non-Human Identity Top 10 and pairing it with policy enforcement at the request boundary.

The practical payoff is simpler incident response. If a task retrieves a unique secret for one execution, there are fewer places to search and fewer standing privileges to unwind. These controls tend to break down when legacy applications require environment-wide shared credentials because the same secret is reused across multiple services and operators.

Common Variations and Edge Cases

Tighter runtime retrieval often increases integration overhead, requiring organisations to balance stronger containment against developer friction and legacy compatibility. That tradeoff is real, especially where a system cannot fetch credentials on demand without redesigning deployment, caching, or network trust assumptions.

There is also no universal standard for every workload. Batch jobs, air-gapped systems, and older middleware may still rely on locally available secrets, but current guidance suggests treating those as exceptions with compensating controls, not as the default operating model. The same is true for emergency access: break-glass credentials may need longer lifetimes, yet they should be isolated, monitored, and rotated immediately after use.

For teams evaluating supply-chain exposure, NHIMG case studies such as the CI/CD pipeline exploitation case study show why manual cleanup is often too slow once secrets have spread across build logs, artefacts, and third-party tools. Runtime retrieval reduces that blast radius, but it does not eliminate the need for inventory and revocation discipline. The better rule is to prefer ephemeral access by design, then reserve manual cleanup for exceptions and incident response, not as the primary control.

Related resources from NHI Mgmt Group

• When should organisations prioritise Zero Standing Privilege for non-human identities?
• How can organisations reduce secret leakage in ServiceNow at scale?
• How do organisations reduce false positives in secret detection pipelines?
• Should organisations prioritise reducing secret reuse over faster scanning?