Prioritise runtime delivery when credentials are still being embedded in code or build files, because removing persistence reduces exposure immediately. Rotation still matters, but it does less if the credential is already copied into places the organisation does not control or review effectively.
Why runtime delivery comes before secrets rotation
When credentials are still embedded in code, build files, or repository history, the first problem is persistence, not age. Runtime delivery removes the secret from places that are copied, cached, forked, and reviewed by too many systems and people. Rotation is still necessary, but it has limited value until the secret is no longer broadly replicated.
That is why teams should treat the exposed secret path as the immediate containment problem. A credential that can be found in source control, CI/CD config, image layers, or logs has already escaped the intended control boundary, so delivery and removal of the secret from those surfaces usually beats a rotation-only response.
For practical secrets handling, this is the same reason centralising secrets and moving toward dynamic or secretless access matters. NHIMG’s Secrets Management Guide and Guide to the Secret Sprawl Challenge both reflect the same operational reality: if the secret is already spread across uncontrolled locations, rotation alone cannot restore control.
What changes when the secret already exists in build or source paths
Once a secret is embedded in code or build artefacts, the control problem shifts from credential freshness to exposure reduction. A rotated value may still remain visible in commit history, pipeline logs, copied config files, container layers, or developer clones, which means the old secret and the path that leaked it both remain part of the attack surface.
That is why runtime delivery is usually the higher-priority fix. It changes where the secret lives, who can retrieve it, and how quickly it can be removed or replaced. API Key Management Guide is relevant here because scoping, revocation, and replacement only work well when the key is no longer hardwired into delivery artefacts.
If the same secret also appears in multiple delivery paths, the problem is broader than one compromised value. Guide to NHI Rotation Challenges is useful because it shows why rotation becomes operationally difficult when dependency mapping, distribution, and renewal are not already under control.
How DevOps teams should sequence the fix
The right sequence is to stop new persistence first, then rotate what remains exposed, then harden the delivery model. That means shifting secrets out of code and build files, replacing static injection with runtime retrieval where feasible, and only then completing rotation so the old secret cannot continue to work from hidden copies.
In CI/CD environments, that sequence matters because an exposed token or key can be reused faster than teams can rotate it if the secret still exists in pipeline definitions or cached artefacts. The classic lesson from CI/CD pipeline exploitation case study is that secret removal from delivery paths must happen before teams assume rotation has meaning.
Where teams are managing many keys or tokens, runtime delivery should be paired with a clean lifecycle model. The NHI Lifecycle Management Guide and the Ultimate Guide to NHIs section on static vs dynamic secrets both support the same judgement: remove long-lived persistence before you rely on rotation as a control.
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, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Hardcoded or copied secrets in build paths are direct secret leakage. |
| NHI-07 — Long-Lived Secrets | The question contrasts static embedded credentials with runtime-delivered secrets. | |
| Recommendation — Remove embedded secrets from code and artefacts before relying on rotation. Replace long-lived embedded secrets with runtime-delivered or short-lived credentials. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Sequencing rotation and revocation is an authenticator lifecycle problem. |
| Recommendation — Rotate, revoke, and replace authenticators once uncontrolled copies are removed. | ||
| CIS Controls v8 | 5 — Account Management | Secrets used for access should be inventoried, scoped, and removed when no longer needed. |
| Recommendation — Inventory secret-bearing access paths and remove persistence before changing values. | ||
| OWASP ASVS | V9 — Self-contained Tokens | Embedded credentials and tokens in delivery paths affect token handling and exposure. |
| Recommendation — Keep tokens out of source and delivery artefacts, then enforce renewal and revocation. | ||
Practitioner Guidance
What to prioritise: If the credential is embedded in code, manifests, CI/CD variables, or image content, prioritise moving it out of those locations before you spend effort on broad rotation. That is the fastest way to shrink uncontrolled replication and reduce the chance that an “updated” secret is still sitting in old copies.
What to verify: Confirm where the secret has already propagated, including source history, build logs, artefacts, and shared configuration stores. If you cannot enumerate those locations, rotation may be necessary but it is not yet a complete containment action.
Decision rule: If the secret can authenticate to production and may exist in uncontrolled copies, treat runtime delivery and exposure removal as the first remediation step, then rotate and revoke once the delivery path is cleaned up.
Practitioner takeaway: Rotation changes a value, but runtime delivery changes the exposure model. When the secret is already embedded in places you do not fully control, the safer first move is to remove persistence, then rotate what remains.
Related resources from NHI Mgmt Group
- How do teams decide whether to prioritise secrets rotation or access visibility first?
- Should teams prioritise JIT access or secrets rotation first when defending against worms like Shai Hulud?
- Should teams prioritise token rotation or runtime enforcement first?
- What should teams prioritise first in secrets governance: rotation, auditability, or access scope?
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 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org